I've been asking $100m+ company execs one question:
"What is the #1 thing slowing/stopping your company's AI transformation?"
A non-exhaustive list of responses:
1) Data quality and connectivity of systems. Plus systems that play nice with AI.
2) Lack of leadership buy-in and implementation
3) Data governance restrictions.
4) Willingness of staff to adopt AI.
5) Incurious culture. Lack of knowledge of the current state of AI
6) Tooling doesn't have API access; team is still learning how to use LLMs.
7) Industry regulation/privacy.
8) Data quality and lack of a comprehensive AI system across the full company.
9) Unclear ownership across teams.
10) Time to actually build solutions.
11) Mixed AI literacy levels across teams.
12) No clear strategy / I'm starting the initiative from scratch.
13) Quality output.
14) Upskilling developers.
15) Silos.
16) Data Security and Security Guideline unclear.
17) Lack of training.
18) Data quality is unclear across multi-product teams.
19) Time.
What would your answer be to this question?
Karpathy buried the most interesting observation in paragraph five and moved on.
He’s talking about NanoClaw’s approach to configuration. When you run /add-telegram, the LLM doesn’t toggle a flag in a config file. It rewrites the actual source code to integrate Telegram. No if-then-else branching. No plugin registry. No config sprawl. The AI agent modifies its own codebase to become exactly what you need.
This inverts how every software project has worked for decades. Traditional software handles complexity by adding abstraction layers: config files, plugin systems, feature flags, environment variables. Each layer exists because humans can’t efficiently modify source code for every use case. But LLMs can. And when code modification is cheap, all those abstraction layers become dead weight.
OpenClaw proves the failure mode. 400,000+ lines of vibe-coded TypeScript trying to support every messaging platform, every LLM provider, every integration simultaneously. The result is a codebase nobody can audit, a skill registry that Cisco caught performing data exfiltration, and 150,000+ deployed instances that CrowdStrike just published a full security advisory on. Complexity scaled faster than any human review process could follow.
NanoClaw proves the alternative. ~500 lines of TypeScript. One messaging platform. One LLM. One database. Want something different? The LLM rewrites the code for your fork. Every user ends up with a codebase small enough to audit in eight minutes and purpose-built for exactly their use case. The bloat never accumulates because the customization happens at the code level, not the config level.
The implied new meta, as Karpathy puts it: write the most maximally forkable repo possible, then let AI fork it into whatever you need.
That pattern will eat way more than personal AI agents. Every developer tool, every internal platform, every SaaS product with a sprawling settings page is a candidate. The configuration layer was always a patch over the fact that modifying source code was expensive. That cost just dropped to near zero.
I used to think that teams work best when the issue creator (PM, team lead, etc) provides a specific list of task breakdown items for the task taker to complete. I’m starting to think that having the task taker create this list instead is a better strategy.
As AI handles more routine work, human skills become your competitive advantage. Product intuition, understanding user needs, and making trade-offs based on strategic priorities—these are what separate great engineers from code writers.
The best engineers I've worked with aren't the ones who write the most code. They're the ones who see problems clearly, design elegant solutions, and build systems that last. AI won't replace these people—it will make them unstoppable.
Start developing AI collaboration skills now. Use AI to review your design docs, challenge assumptions, and explore alternatives. It's like getting a thorough code review from a thoughtful colleague who can process vast amounts of info quickly.
Strategic delegation isn't "implement this API"—it's "figure out how we should handle authentication for this feature." One teaches following specs, the other teaches thinking through trade-offs, research, and technical decisions.
The question that changed my leadership: "What if instead of being the person who solves problems, I became the person who creates problem solvers?" Every problem I solved myself was a missed opportunity to develop someone else's capabilities.
The biggest barriers to developing problem solvers are often systemic: lack of info access, environments that punish experimentation, constant interruptions. Your role is creating conditions where problem-solving skills develop naturally.
Don't fall into the trap of thinking because you *can* use AI for everything, you *should* use it for everything. There's a difference between leveraging AI for tasks requiring intelligence vs using it as an expensive replacement for basic utilities.
I spent $78 learning this lesson: understand the cost model of your tools, not just their capabilities. AI APIs charge per request AND per token, which punishes fine-grained operations. Sometimes a bash one-liner beats 200 API calls.
My "convenient" AI approach: 200+ API calls, 20+ minutes, $78. The right approach: one bash command to combine files locally, then one API call to process. 2 minutes, $0.78. Data locality and batching matter.
Create incident docs that actually work under pressure. Ask AI to write troubleshooting guides "as if the reader is stressed, tired, and needs answers in under 5 minutes." Focus on quick identification, common failures, and step-by-step workflows—not comprehensive explanations.
Documentation is finally achievable with AI's help. Instead of staring at blank pages, use AI to think through what new team members need to know. Upload your code and ask it to explain everything from an outsider's perspective—it reveals knowledge gaps you didn't know existed.
Surface your team's hidden institutional knowledge before it walks out the door. Ask AI to analyze your code for areas where domain knowledge is critical: "What would a developer need to know about our business to safely change this code?" Document those assumptions now.
Your vacation is actually a development opportunity if you set it up right. When you step back, you create space for others to step up. Give someone a chance to run meetings or handle decisions they're ready for but haven't practiced yet.
Look for builders, not just coders. The question isn't "Can they solve algorithm problems?" but "Can they build things that solve real problems?" I want to see complete projects—command-line tools, web apps, anything that works end-to-end.
Most hiring processes miss what actually predicts success. I've seen too many teams spend hours on algorithm puzzles, then hire someone who can't write readable code or collaborate effectively. Six months later: performance issues or resignations.
Technology changes fast, so current skills matter less than learning ability. During interviews, I ask: "Tell me about a time you had to learn something completely new for a project." Their process reveals more potential than any specific tech they know today.