A lawyer told me his job was safe, and gave a better reason than most people give.
He catches AI mistakes constantly, he said, but that is not the point. The point is where his work lives. Roughly 20% of it happens in courtrooms and in private negotiation — rooms that produce no transcript anyone will ever train on. The rest, the drafting and the research, is already in the corpus. His conclusion: "AI at best can rise to the level of what a law student knows after graduating."
Your 20% is protected because it never gets written down. My work is 100% digital — all the code, all the solutions, everything is basically the training data. Maybe my whole job is that 80%.
That is the uncomfortable version of the question. Not "will AI replace developers", which is exhausted, but: if none of my work is protected by scarcity, what is left that is actually mine?
The obvious answer — orchestration, verification, taste, being the interface between the human and the machine — is also the answer everyone gives, which is a good reason to distrust it. So I spent a stretch of work watching for it specifically. Not asking whether steering matters. Asking what it catches that nothing else does.
A large share of the "only a human can" list is not human work at all. It is verification work, and a second model does it well — often better than the first one did, because it has no stake in the first answer being right.
I don't have to be in the room for this part, and mostly I'm not. Over one two-day stretch my agents caught each other repeatedly: a reviewer refuted a diagnosis another agent had already written up, an executor stopped dead on a brief whose premise was wrong and explained why, a fresh pass turned up ten defects in code a previous pass had promised to check and quietly skipped — including one that charges a user a fee and then denies the request.
Not one of those needed me. My contribution was structural, not intellectual: a setup where a second opinion is cheap, and rules that make refusal legal — an agent that hits a false premise is allowed to stop rather than build on it.
That is real, and it is not nothing. But it is also automatable, and anyone reading this can copy it in an afternoon. If this were the whole answer, the lawyer would be right about me.
Case one. A feature had been built, verified, and shipped. Six independent verification passes came back green. Every one of them confirmed the code did what the spec said, and none of them was sloppy — the spec wasn't wrong either.
Then I used the product, and the feature was silent. A single line on the client discarded the value the server had just computed, so the whole thing ran end to end and produced nothing a person could hear.
The lesson isn't "human testing matters", which everyone already agrees with and nobody schedules. It's narrower and less comfortable: every one of those passes was asking whether the code matched the description. Not one was asking whether the result reached a human ear, because that isn't a test — it's use. A system that verifies itself perfectly will still converge on the description, and the description is exactly the artifact that can be complete, correct, and beside the point.
Case two. My agents handed me a list of nine defects queued for fixing. I removed three of them on sight — not because the analysis was wrong, but because the behaviour was intended. A toast notification covering the navigation bar is a defect if you assume it shouldn't; it's a design decision if I decided it should. No verification pass can separate those two, because the difference isn't in the code. It's in what somebody wanted, and I'm the one who wanted it.
Case three. The plan on my desk was to build a new empty-state component for a slot that was stuck showing an infinite loading animation. I stopped it: the component already had a paused state, because I had asked for one when the design system was built. The fix went from a new component to a single boolean.
There is a pattern, and it is not "humans are wiser". In all three cases the machine had every fact and still could not get there, because the missing input was not a fact. It was intent — and intent lives in the person who formed it, not in the artifact.
A verifier can prove a system does what it says. It cannot tell you whether what it says is what you meant. That gap does not close with a better model, because it isn't a knowledge gap.
Any version of this argument that only lists wins is an advertisement, so here is the stretch where I lost — and the interesting part is exactly where I lost it.
I'm a frontend developer. The work in question was backend: a caching layer I can read but could not have designed, in a language I don't write daily. And that is precisely where I loosened up. Not on how much work I handed over — on how much judgement. In my own domain I argue with the machine constantly, because I can feel when an answer is shaped wrong. Outside it I have no such feel, so I let conclusions through.