Writing
Two kinds of correction
A model will catch what a thing actually does. It will never tell you to move to services. Those are different failures, and only one of them announces itself.
The argument about AI and expertise is stuck on the wrong question. Will it replace you. How much can you trust it. Both are unanswerable in the abstract, and neither is what you actually deal with on a Tuesday evening with something half-built in front of you.
The better question is narrower: what kind of mistake can each side catch?
Because there are two kinds, they fail differently, and only one of them announces itself.
What the machine is genuinely better at
Mechanism. What a thing actually does, as opposed to what everyone assumes it does.
Which of these DNS records will silently break your mail. Whether a redirect hides the destination or broadcasts it to every visitor. What order operations have to happen in so you don't take a live site down between two correct steps. Whether that firewall rule is in the chain the traffic actually traverses.
These are checkable, and being checkable is exactly why the machine wins. It will hold more of the mechanism in view than you can, it will not get bored on the ninth check, and it does not have the thing that experience quietly installs in all of us - the confidence that you already know how this works, because you have done it a hundred times.
You have done it a hundred times. The hundred-and-first has a mail record pointing at the same address as the apex, and a bulk edit is about to move your email to a machine with no mail server on it.
What it will never tell you
It will never tell you to move to services.
Ask for a capability and you get one. It works. It is coherent, it is fast, and it is quietly monolithic, because every shortcut along the way was locally reasonable and nothing ever failed. Boundaries and layers and contracts all cost more today and pay back in a year, and "in a year" is never in the request.
So the model optimises what is in front of it, brilliantly, and the structural decision never surfaces - not because it is stupid, but because nothing about the immediate task requires it.
I have written before about the danger being a magnificent tunnel through the wrong yard. This is the same wall. The difference is that here nobody even asks whether it is load-bearing, because the tunnelling is going so well.
And architectural corrections are the hardest to get credit for, because when they work nothing happens. Repeatedly. You only ever see the version where the decision was not made.
The honest part
It would be a tidy story if that were the whole shape of it: machine handles mechanism, human handles judgement, everyone stays in their lane.
It is not that tidy.
The machine also catches contradictions in your own reasoning that you have read past four times. It notices the thing you decided last week and quietly stopped applying. That is not mechanism, and it is genuinely useful.
And it gets things confidently, fluently wrong - in a register absolutely indistinguishable from being right. No hesitation, no hedge, none of the human tells you have spent a career learning to read. It will tell you a door is locked when it is open, in the same voice it uses for everything else.
Which is why the one thing that never delegates is verification. Not the work. Verification. If the only evidence that something worked is that something said it worked, you have not checked anything - you have been told a story with excellent production values.
What actually works
The useful split is not human versus machine. It is:
- Bounded and checkable - delegate it, then check it
- Judgement, diagnosis, or anything where being wrong is expensive and quiet - keep it
- Verification - never delegate, in either direction
That last one holds both ways. My corrections cluster where information only exists outside the code: what it costs when someone takes your work, whether anyone is actually reading, what a name will do to you legally if you succeed. The machine cannot derive any of that. Its corrections cluster on mechanism, where I am overconfident precisely because I have been right so often before.
Neither of us is checking our own work. That is the whole arrangement.
Twenty-five years taught me to read a room - the hesitation in a confident voice that says we might be hitting a wall here. That signal is gone now; the machine does not leak stress. So you replace intuition with evidence, deliberately, and you keep asking about the wall.
Nothing else has changed as much as people think. Software was always a team sport because the full skillset rarely lives in one seat. It still doesn't. The seat just got stranger.
Review
Published, and not yet reviewed by a human. This note updates when it has been.