How AI Changed the Way I Actually Code

I want to skip the marketing version of this story. You know the one: AI writes all your code now, engineers are obsolete, productivity is up 10x. That's not my experience. The real version is more interesting and a lot more useful.

AI didn't replace my work. It moved it. Here's how my actual day changed.

What it's genuinely great at

A few things stopped being chores almost overnight:

• The blank page. Starting is the hardest part of any task. Now I describe what I want and get a rough first draft to react to. Reacting is so much easier than originating.
• The boring middle. Boilerplate, glue code, the fifth nearly-identical CRUD endpoint, converting this shape into that shape. The stuff that was never hard — just tedious.
• Unfamiliar territory. Dropping into a new language or library used to mean an hour of tab-juggling. Now I can ask, get a working example, and learn by editing it.
• Rubber-ducking that talks back. "Here's my approach, what am I missing?" is a genuinely good use of a model, even when I ignore half the answer.

What it's quietly bad at

This is the part the demos skip, and it's the part that matters most.

The model is confidently average. It will hand you the most common solution on the internet, delivered with total certainty — even when your situation is the uncommon one. It doesn't know your codebase's history, the weird constraint from that one customer, or the reason you deliberately didn't do the obvious thing.

AI is brilliant at producing plausible code. It has no idea whether that code is correct for you. That judgment is still entirely your job.

The failure mode that bites me isn't the obvious bug — I catch those. It's the subtly-wrong code that looks completely reasonable, passes a glance, and quietly does the wrong thing at the edges. Reviewing AI output well is a real skill, and it's the opposite of the relaxed "looks good" review you'd give a trusted colleague.

The skill that suddenly matters more

Here's the shift, and it's the whole point of this post.

When the cost of writing code drops to nearly zero, the bottleneck moves to everything around the writing:

1. Knowing what to build. A clear specification produces good output. A vague one produces confident garbage. The model is a mirror for the clarity of your own thinking.
2. Reading code fast and critically. I read far more code than I used to, and I read it more skeptically. Reviewing is now a primary skill, not a side task.
3. Taste. Deciding what good looks like — simple over clever, this abstraction not that one, when to stop. The machine has no taste. You have to bring it.

None of those are new skills. They're the senior skills — the ones that always separated good engineers from fast typists. AI just made them the whole game.

How I actually work now

My loop, honestly, looks like this:

1. Think hard about what "done" means, and write it down.
2. Let the AI produce a first pass.
3. Read it like I'm trying to break it, not bless it.
4. Rewrite the parts where my judgment disagrees.
5. Make sure there's a test or a type that proves it works.

Step 1 and step 3 are where the value is. The middle — the actual typing — is the part I happily delegate.

What I tell people who are nervous about it

If you're early in your career and worried the machine writes better code than you: it doesn't write better code, it writes faster code. The thing that makes you valuable isn't typing speed. It's knowing what's worth building, spotting what's subtly wrong, and having the taste to keep things simple.

Those are the muscles to train now. Let the machine handle the boilerplate. Spend your energy on the judgment — that's the part that was always the job, and now it's the whole job.

That trade feels like a good one to me.