Two facts, sitting uncomfortably next to each other. At Anthropic, roughly 90% of the code for Claude Code is now written by Claude Code itself. And the advice circulating among experienced engineers going into 2026 is that if you want to keep owning your codebase, you need to keep writing some of it yourself.
Both of those can be true. That’s what makes this moment strange to work in. The machines are demonstrably capable of carrying enormous amounts of the load, and yet the people who have been doing this the longest keep landing on the same recommendation: don’t stop typing.
Why the wasteland warning lands
The phrase that stuck with me from the current discussion is the idea of a codebase turning into an LLM wasteland that only your coding agents can thrive on. It’s a good image because it’s not a moral argument. It’s an operational one.
If every file in your project was generated, reviewed lightly, and merged, you end up with a system you can only interact with through a model. You can’t reason about it directly. You can’t make a surgical fix at 2am when something breaks in production. Your debugging strategy becomes asking an agent to guess, then hoping. That’s a real cost, and it shows up later, which is exactly why people keep walking into it.
For those of us building bots and agent systems, the irony is thick. We are the ones shipping the tools that make this possible. Which means we should be the most careful about what we let them do unsupervised inside our own repos.
2x, not 10x
One of the more honest data points floating around is a developer reporting steady progress on a 70k+ line GUI side project using Codex and Sol, describing the gain as 2x rather than 10x. The workflow they describe is almost boring: squash a bug, review architecture, move on. Repeat.
That rhythm matters more than the multiplier. The endless whack-a-mole of bugs is what kills side projects, and it’s also what kills the fun. A 2x that you can sustain for months beats a 10x sprint that leaves you with a pile of code you’re afraid to open.
I’d rather have a project I still understand at line 70,000 than one I abandoned at line 12,000 because I lost the thread.
What I actually keep for myself
The framing I’ve settled into is close to what Addy Osmani describes: treat the model as a powerful pair programmer that needs clear direction, context, and oversight, not autonomous judgment. Pair programmers are great. Pair programmers who make architectural decisions while you’re at lunch are not.
In practice, for bot work specifically, I hold onto:
- Architecture and boundaries. Which services exist, what talks to what, where state lives, how the agent loop is structured. If I hand this off, I’ve handed off the whole project.
- Prompt and tool design. The contract between my code and the model is the product. I write that myself.
- The tricky 5%. Concurrency, retry logic, anything touching money or user data. Not because models can’t write it, but because I need to be able to defend it.
- The parts I enjoy. Unapologetically. If there’s a gnarly parsing problem I want to solve by hand, I solve it by hand. Efficiency is not the only objective function here.
And what I happily delegate: test scaffolding, boilerplate clients, config plumbing, migrations, docstrings, the fifteenth CRUD endpoint. Grunt work is grunt work.
The part nobody expected
There’s a detail in this whole shift that I find genuinely cheering. One observation making the rounds is about how many people are coding again who had mostly stopped as their careers moved them away from it. Managers, principals, founders, people who hadn’t shipped anything in years.
That’s a real gain, and it’s the opposite of the doom framing. Lowering the activation energy for starting a project means more projects get started. Jaana Dogan, Principal Engineer at Google, shared her 2026 predictions with Oxide and Friends; the fact that engineers at that level are actively working through what this means tells you the question is open, not settled.
Keeping the joy part functional
Enjoying programming in 2026 is not a nostalgia exercise. It’s a practical skill, and it comes down to a few choices you make repeatedly.
Stay the one making decisions. Read the code that gets generated, properly, not as a formality. Pick a project where you care about the internals and defend your involvement in them. Use the models for the parts that were never fun anyway.
The failure mode isn’t that AI takes your job. It’s that you slowly stop being the person who understands the thing you built. That’s avoidable, and avoiding it happens to be the same thing as having a good time.
đź•’ Published: