It’s 11:40 on a Tuesday night. You’ve got a terminal open, an agent chewing through a refactor, and a diff that’s now 600 lines long. You scroll it. You approve it. You don’t read it. The tests pass, the feature works, and you close the laptop feeling… nothing. Not the small click of satisfaction you used to get. Just a vague sense that you supervised something.
I review AI tooling for a living, which means I spend most of my week in exactly that chair. And the thing I keep noticing isn’t that the tools are bad. They’re genuinely good. It’s that the default way we use them quietly strips out the part of programming most of us actually liked.
The wasteland problem is real
There’s a line making the rounds that I think is the most practical piece of advice in this whole conversation: if you want to keep owning your codebase, you need to keep writing some of the code. Let it all be generated and it turns into an LLM wasteland that only your coding agents can thrive on.
That’s not a sentimental argument. It’s an ownership argument. A codebase you didn’t write is a codebase you can’t debug at 3am when the agent is confidently wrong and the stack trace points somewhere you’ve never been. The “fun” and the “competence” here are the same muscle. Skip the reps and both atrophy together.
I’ve watched this happen in my own side projects. The ones where I let the agent drive end to end are the ones I dread opening. The ones where I hand-wrote the core data model and delegated the boilerplate are the ones I still enjoy.
2x is the honest number
One write-up I keep coming back to is titled, plainly, “2x, not 10x.” The author describes keeping steady progress on a 70k+ line GUI side project using Codex and Sol, without the endless whack-a-mole of bugs. Squash a bug, review architecture, move on. Repeat.
That rhythm is the whole point. Not a firehose of generated features, but a sustainable loop where you stay oriented. 2x is a great multiplier. It’s also a number that leaves room for you to still be a participant rather than a reviewer of machine output you never understood.
The 10x claims usually come from people measuring lines produced, not systems understood. Those are different metrics, and only one of them predicts whether you can ship a fix next quarter.
What the heavy users actually say
Addy Osmani has been documenting his AI-assisted workflow going into 2026, and the framing he lands on is worth borrowing: treat the LLM as a powerful pair programmer that needs clear direction, context, and oversight, not autonomous judgment. He also notes that at Anthropic, engineers adopted Claude Code so heavily that today roughly 90% of the code for Claude Code is written by Claude Code itself.
Those two facts sit next to each other for a reason. Extremely high AI authorship is achievable. But even in that environment, using LLMs for programming isn’t a push-button process. Someone is still steering, still setting context, still deciding what good looks like.
That’s the job now. It’s a real job, and it can be satisfying, but only if you’re deliberate about where you insert yourself.
A practical split that’s worked for me
The standard advice for keeping the joy alive in 2026 is to keep writing code and use LLMs as assistants rather than replacements: you take the high-level work, the model takes the grunt work, and you maintain critical thinking and oversight throughout. Here’s how I translate that into daily practice:
- Hand-write the parts you’ll have to reason about later. Core domain logic, state machines, anything with tricky invariants. If you’d need to explain it in a design review, write it yourself.
- Delegate the tedium without guilt. Test scaffolding, migrations, config plumbing, adapter layers. This is where the multiplier is real and the cost is near zero.
- Read every diff you approve. Not skim. Read. If a diff is too big to read, it’s too big to approve, which means your prompt was too big.
- Keep one project that’s entirely yours. No agents. It’s your gym.
The part nobody expected
An early January note captured something I’ve seen firsthand: one of the genuinely nice side effects of this weird new era is the number of people who are coding again after mostly stopping. Careers pulled them into management, or the friction of setup and boilerplate got too high, and now the barrier is low enough that they’re building things for fun again.
So the pessimism isn’t warranted. The tools brought people back. What they can’t do is decide how much of the work you want to keep for yourself. That’s a choice, it needs making on purpose, and it’s the difference between a craft you still like and a queue you approve.
🕒 Published: