I miss writing code. I'm not going back.

Before Claude Code, a feature took me weeks. Most of that time went into thinking and typing code.

I'd work through the problem, write the HLD and LLD, and hunt for gotchas before writing a single line. Then I'd take it to my peers and we'd pick it apart together. Only after that came the good part. Headphones on, music up, hours of implementation. Should this function run before the lifecycle starts or after? Did I detach my listeners when it stops? Small questions, but they were mine to answer.

Shipping was a team sport too. We split PRs so a human could actually read them. Big features went behind a flag in phases, and I'd build phase two while phase one was in review.

That workflow is gone.

How I work now

I ask an AI to plan the feature and interview me about it. The interview matters more than it sounds. It's where wrong assumptions get caught before they turn into code. Then it writes the HLD and LLD. We go back and forth for hours, and then I send the implementation request.

While the agents work, I read what they write. For real features I follow the code as it comes in. For low-effort tasks, like a copy change or a small config tweak, I let the agents run and do something else. I fix bugs, pick up other work, and sometimes watch a video.

Then the PR goes out, and nobody reads it. Especially the big ones. Someone comments LGTM and it ships to a small percentage of users.

I don't blame the reviewers. The cognitive load has gone way up. Agents can produce a 10,000 line PR in an afternoon, and nobody can hold that in their head. Splitting it doesn't fix it. Ten PRs of 1,000 lines is still 10,000 lines to read, and they arrive faster than anyone can review them. One study of 1.5 million PRs found that changes of a few hundred lines got approved about three times faster and had 40% fewer defects. That advice assumed humans were writing the code.

GitHub put native stacked PRs into public preview this year to deal with exactly this. I wonder how many teams actually use them, and whether they help when the problem isn't the size of each PR but the total amount of code.

So the real review happens in production. Even with 100% TDD and full E2E coverage, I can't guarantee a solid release. That's okay. It's the new world. I watch session replays, backend logs, APM and the error tracker. If something breaks, I have the AI pull the error through the tracker's MCP server, fix it, ship it, and turn the rollout up.

The long discussions with peers are mostly gone too. I talk to the model more than I talk to my team. The only time I really talk to them is before a kickoff, during status updates, and at a testing session once everything is done.

With models like Opus 5.5 and Sol-6.1, even more of this is one-shottable. I one-shot the first version, then go through each phase myself to raise the quality before moving to the next.

Fighting slop

That second pass is another place my time goes now. I think about quality all the time, and keeping it takes slow, detail-oriented work.

It's also the easiest thing to lose with AI. I've seen a crazy amount of slop from people who stopped caring. Dashboards full of essays instead of data. A justification attached to every small decision. PRs where a five-line change comes with paragraphs of comments explaining why it was done.

It gets worse in codebases that never had good practices. The model picks up the bad habits from the pre-AI code around it and then defends them.

So I read what it writes. All of it, for anything that matters. Nobody else is reviewing my PRs anymore, so I'm the last line of defense. That's why the planning interview matters so much to me. The fewer assumptions the model makes on its own, the less slop I have to clean up later.

What I got in return

So yes, the joy of coding is gone. Here's what I got for it.

I started my career as a frontend engineer. Today I run a service that handles millions of requests. I debug on-call issues in systems I've never touched and optimize database queries. I couldn't have done any of that alone, not this soon.

I'm learning so fast that my brain needs longer breaks and more time away from the screen just to keep up.

People say there are more high-impact bugs now, and they're right. But look at why. Teams everywhere are shipping faster than ever. The bug rate per change may not be much worse (sorry, didn't check the stats, this is how I feel which could be wrong). There are just far more changes going out, so more bugs reach production.

That changed where my time goes. I used to try to write bug-free code. Now a lot of my time goes into asking what could break. Which edge case, which user, which downstream service. Writing the code is cheap. Imagining how it fails is the real work.

The new bottleneck

I keep wondering how far I can push this. They say human desire has no limit, but I keep reaching the end of mine. I finish a problem, sit back, and wait for the next one to show up. Then I solve it with AI.

Sometimes I fill that gap with silly projects, like vibe coding a dashboard to control the smart devices in my house. But once it's built, I'm back to the same question: what do I want to solve next?

That's where more of my time goes now. Writing the code has become easier. Staying hungry for problems hasn't.