The short version
- AI changed who writes the code. Planning and implementation now happen with AI. Reviewing is still my job.
- Accepting AI code without reading it is vibe coding. It runs, it looks right, and nobody has checked it.
- How fast you can review correctly is the new measure of a programmer. Code review is the skill worth training.
How programming used to work
For most of my career, programming meant one person holding the whole problem. You read the requirement, worked out the logic, picked the algorithm, decided how the pieces would talk to each other, and then typed every line of it. The thinking and the typing were the same job, done by the same person, usually at the same time.
Skill was easy to see in that model. A good programmer wrote correct code faster and needed fewer tries to get there. How much you could produce was how you were judged.
That model is gone from my own work, and I don't think it's coming back.
The AI workflow: plan, implement, review
A feature on one of my plugins goes like this now:
- Planning with AI. I describe the problem, the constraints, and what already exists. We go back and forth on the approach: which hook, which data shape, what could break for installs that already exist. The plan comes out of that conversation. It isn't something I write alone and then hand over.
- Implementation by AI. The code gets written, most of it not by me. Files, functions, tests, the migration if there is one.
- Review by me. I read all of it and decide what ships.
The first two steps got dramatically faster. The third one didn't, and it shouldn't. It's where the job moved to.
A few weeks ago I wrote that programmers should learn to think, not just code. This is the practical side of that. Thinking about systems is how you plan well. Reviewing is how you prove the plan actually got built.
Accepting AI code isn't reviewing it: that's vibe coding
There's a version of this workflow that skips step three. The AI writes it, it runs, the page loads, the test is green. Merge.
That's vibe coding. It isn't a moral failing. It's a description. You're shipping code on the strength of how it feels, because nobody actually read it. For a throwaway script, fine. For a plugin running on someone else's live site, with a visitor's data going through it, it's a bet you're making with other people's stuff.
The trouble is that AI-written code is very good at looking right. It's formatted well, the names make sense, the comments sound confident. The mistakes aren't typos. They're plausible decisions that happen to be wrong, and plausible wrong code gets past a skim every time.
In WordPress work, these are the ones I keep catching:
- A REST route registered with
'permission_callback' => '__return_true'on an endpoint that writes data. It works in testing because you're logged in as admin anyway. - A
$wpdb->query()with a variable dropped straight into the SQL string instead of going through$wpdb->prepare(). - Output echoed without escaping, or input saved without sanitizing, because the happy path never sent anything strange.
- A nonce that gets created and never checked.
- A migration that runs on every page load instead of once, because nothing records that it already ran.
Every one of those runs. Every one passes a quick manual test. None of them announce themselves. You only find them if you're reading on purpose.
Review speed is the new measure
In the old model you could see a programmer's skill in what they wrote. Now you can see it in how fast they can review correctly.
Both words matter. Fast and wrong is worse than useless, because it gives confidence to code that hasn't earned it. Slow and right still works, but you lose most of what AI gave you, and the queue of unreviewed changes piles up.
What makes someone fast and right is the same thing that used to make someone a good writer of code: they already know what correct looks like. An experienced reviewer doesn't read a permission check and wonder whether it matters. They know where the authorization should be and notice when it's missing. They don't trace every loop from scratch. They recognize the shape and look straight at the edge case the shape usually gets wrong.
So all the fundamentals still count: logic, data structures, how the platform behaves, security basics. They just get used in a different place. You used to spend them typing. Now you spend them reading.
Reading for what's missing
The hardest part of reviewing AI code isn't spotting a bad line. It's noticing the line that isn't there.
AI does what you asked, and usually does it thoroughly. What it misses is whatever you didn't think to ask about: what happens on an install that already has old data, what happens when two requests land at once, what happens when the user isn't who the code assumes they are, what happens to the thing this change quietly depends on.
So I read against the plan, not only against the diff. Did it handle the case we said mattered? Did it touch anything the plan never mentioned? Is there a code path we talked about that just isn't in there? The diff only shows you what got written. The plan tells you what should have been.
How to get better at code review
If review is the main skill, it deserves practice, the same way writing code used to get practice. What I actually do:
- Predict before reading. Before opening the diff, I guess roughly how I'd have built it. Where the real code differs, either it knows something I missed or it's wrong. Both are worth knowing.
- Keep a list of what AI gets wrong. The list above started as notes. The same mistakes come back, so a written list makes the next review faster.
- Read other people's code. Open-source plugins, pull requests, core itself. Reading code you didn't commission, with no plan in your head, is the hard version of the exercise.
- Still write some things by hand. Not for speed. So I keep an instinct for what correct feels like. You can't recognize the right shape if you've forgotten how to make it.
The name on the commit
I said in that earlier post that even code review will probably need less human involvement over time. I still think that's where this is heading. But it isn't where we are now, and right now the review is where responsibility sits. The AI doesn't answer the support ticket. The AI isn't the one a client calls when a form stops sending. My name is on the commit, so my reading is what signs it off.
Writing code got cheap. Knowing whether code is right didn't, and that's the skill I'm working on now.