About 90% of the code for Claude Code is now written by Claude Code itself, according to Addy Osmani writing about Anthropic’s engineering practice. That is a startling number, and if you are a programmer who still likes programming, it probably lands somewhere between thrilling and slightly nauseating.
I write for people who don’t code professionally, so let me translate what that statistic does and does not mean. It does not mean nobody is programming at Anthropic. It means the typing has moved. The deciding has not.
The honest multiplier is 2x, not 10x
One developer’s write-up that stuck with me was titled, plainly, “2x, not 10x: coding with LLMs in 2026.” Their evidence wasn’t a benchmark. It was a 70,000-line graphical side project they’ve kept making steady progress on using coding tools like Codex and Sol, without what they describe as the endless whack-a-mole of bugs. Squash a bug, review the architecture, move on.
Notice the rhythm in that sentence. Fix, review, proceed. Three steps, and only one of them is the part an AI agent does well. That’s the whole story of AI-assisted programming right now, compressed into a single workflow.
A 2x improvement is genuinely good. It is also not the infinite-productivity fantasy the marketing implies, and I think the gap between those two numbers is exactly where the enjoyment lives. At 2x, you are still the one steering. At 10x, you’d be a spectator.
Why people who quit coding are coding again
Here’s the part of this trend I find genuinely lovely. Simon Willison noted in early January that one thing he likes about our strange new LLM-assisted world is the sheer number of people he knows who are coding again, having mostly stopped as their careers moved on.
Think about what that implies. A lot of people didn’t stop programming because they stopped enjoying it. They stopped because the enjoyable part got buried under the tedious part: boilerplate, configuration, remembering which flag does what, the forty-minute detour to fix an environment before you write a single interesting line.
Those people came back not because AI made programming easier to be good at, but because it made programming faster to get started on. Two different things. The second one turns out to matter more for joy than we assumed.
The wasteland problem
There’s a warning in this same discussion that I think non-technical readers should understand, because it applies well beyond code.
The argument goes like this: if you want to keep owning your codebase, you need to keep writing some of the code yourself. Let all of it be generated, and it turns into a wasteland that only your coding agents can navigate. You end up with a system you technically own and cannot actually read.
I’d generalize that. Any body of work you fully delegate becomes a body of work you can no longer evaluate. That’s true of a codebase, a financial model, a legal document, a research summary. The moment you lose the ability to read your own thing, you have promoted the tool to decision-maker and demoted yourself to approver of decisions you can’t assess.
What good practice actually looks like
Osmani’s framing is the most useful one I’ve read: treat the language model as a strong pair programmer that needs clear direction, context, and oversight, not as something with autonomous judgment. He’s explicit that using these tools for programming is not a push-button process, even after a year of refining his own approach.
Practically, the pattern people report working in 2026 comes down to a few habits:
- Keep writing code yourself, not all of it, but enough that you stay fluent in your own project
- Aim the model at grunt work and keep the high-level decisions for yourself
- Read what comes back, review architecture deliberately rather than only when something breaks
- Give clear direction and context up front instead of expecting the tool to infer intent
- Maintain critical thinking and oversight as a standing practice, not an emergency measure
None of that is exotic. It’s roughly how you’d work with a fast, capable, slightly overconfident junior colleague.
The skill that’s quietly appreciating
Jaana Dogan, a principal engineer at Google, has been part of the public conversation about where this goes in 2026, and the prediction-making has been lively across the industry. I’m not going to guess at outcomes nobody can verify yet.
What I’ll say instead is that the scarce skill is shifting from production to evaluation. Knowing whether the output is right, whether the architecture holds, whether the shortcut will cost you in six months. That judgment is the part these tools don’t supply, and it happens to be the part most programmers enjoyed in the first place.
Ninety percent of the typing can go to the machine. The taste can’t.
đź•’ Published: