If you stop writing code entirely, you will stop enjoying programming, and you will also stop understanding the thing you supposedly own.
That’s my verdict after watching a year of people either evangelize or catastrophize about LLM-assisted development. The interesting part isn’t whether the tools work. They do, well enough. The interesting part is what happens to the human on the other end of them, and the honest answer is that it depends almost entirely on how much typing you’re willing to keep doing.
The wasteland problem
Simon Willison put it about as plainly as anyone has: if you want to keep owning your codebase, you need to keep writing some code. Let it all be generated and it turns into an LLM wasteland that only your coding agents can thrive on.
That phrase should worry you more than any job-loss headline. A codebase you can’t reason about isn’t an asset, it’s a dependency on whatever model happens to be available next quarter. You didn’t build a system. You rented one, and you’re paying in comprehension.
The enjoyment angle and the ownership angle turn out to be the same angle. Programming is fun because you build a mental model of a machine and then bend it to your will. Outsource the model-building and you’re left with the least satisfying part of the job: reading someone else’s code and hoping it’s right. Forever. That’s not engineering, that’s permanent code review duty with no promotion path.
The 2x number nobody wants to hear
The most useful data point I’ve seen recently comes from a developer describing coding with LLMs as 2x, not 10x. They kept steady progress on a 70k+ LOC GUI side project using Codex and Sol without the endless whack-a-mole of bugs. Squash a bug, review architecture, move on.
Notice the shape of that workflow. It’s not “describe app, receive app.” It’s a loop where a human keeps stepping back to look at architecture between fixes. The speedup is real and it’s meaningful, but it comes from removing friction, not from removing the programmer.
Two times faster is a genuinely great outcome. It’s also deeply unsexy, which is why you won’t see it on a billboard. Anyone selling you an order of magnitude is selling you a demo, and demos don’t have 70,000 lines of accumulated decisions to respect.
Pair programmer, not oracle
Addy Osmani’s framing after a year of refining his own process is the right one: treat the LLM as a powerful pair programmer that requires clear direction, context and oversight rather than autonomous judgment.
The word doing the work in that sentence is judgment. Models are strong at producing plausible code and weak at knowing whether that code should exist. Those are different skills, and only one of them has been automated. Using LLMs for programming is not a push-button process, no matter how many product pages imply otherwise.
Worth sitting with the counterexample too. At Anthropic, engineers adopted Claude Code so heavily that roughly 90% of the code for Claude Code is now written by Claude Code itself. That’s a striking number, and I’d gently point out the obvious: those are engineers with unusually deep knowledge of the tool, working on the tool, with the ability to evaluate every line. It’s a demonstration of ceiling, not a template for your Tuesday.
What actually keeps this fun
The practical advice for 2026 is boring and correct. Keep writing code. Use LLMs as assistants rather than replacements. Take the high-level tasks yourself and hand off the grunt work. Maintain critical thinking and oversight.
Concretely, that means a few habits worth defending:
- Write the parts you find interesting by hand. Not because a model couldn’t, but because that’s the part you showed up for.
- Let the agent handle boilerplate, glue, migrations, test scaffolding, the stuff you’ve written a hundred times and learn nothing new from.
- Read every diff before it lands. If you can’t explain why a change works, it hasn’t been reviewed, it’s been approved.
- Step back to architecture on a regular cadence. That loop of bug, review, move on is the whole trick.
The quiet upside
There’s a genuinely nice thing happening alongside all the noise. Willison also noted something I’ve heard echoed a lot: the number of people coding again after having mostly stopped. People who drifted into management, or into other careers, or just ran out of energy for setup and config, are building things again because the tedious parts got cheaper.
That’s the best case for these tools and it has nothing to do with productivity metrics. Lowering the activation energy for making software means more people get to experience the part that’s actually fun.
Which is exactly why handing over the whole job would be such a waste. The tools removed the barrier to enjoying programming. Don’t use them to remove the programming.
🕒 Published: