I use coding agents every day, and there is one sentence I trust less every week: "done."
Not because the models are deliberately lying. The problem is dumber than that. The agent that just wrote the code is often the same agent we ask to tell us whether the code is good. We turn the author into quality control, then act surprised when the report strongly resembles its own version of events.
Tom Rochette calls this the "acceptance gap": producing a solution and deciding that the solution deserves acceptance are different jobs.
That distinction gets useful as soon as you delegate more than a twenty-line function.
"It works" needs an outside witness
When a human hands a bug to an agent, the lazy workflow goes something like this: here is the problem, fix it, run the tests, tell me when you are finished.
The agent edits the repository, runs a few commands and comes back with a beautifully tidy report. Tests green. Files changed. A reassuring sentence about compatibility. Everything is in place, including the confidence nobody actually verified.
The problem is not the summary. It is the lack of an independent acceptance signal.
Rochette leans on an old engineering distinction: verification asks whether we built what was specified correctly; validation asks whether the specification described the right thing in the first place.
An agent can participate very effectively in the first. Tests, static analysis, scenarios, mutation testing, specialized critics: we can surround a change with evidence.
The second remains much more human. Is this what I wanted? Is it acceptable in this product? Is that strange behavior a bug or a decision? No npm test command knows your private intention. Annoying, really. Computers have had decades of marketing promising they would eventually read our minds.
A prompt is not evidence yet
The part I care about goes a little beyond "write better tests."
For a bug, we should prepare the way we will verify the result before, or at least alongside, the fix.
A test can fail before the patch and pass after it. A migration can return before-and-after counts plus an integrity check. An infrastructure command can report the final observed state. A research agent can return the exact sources supporting each important claim.
For verifiable work, the deliverable is not only "the thing." It is the thing plus the material needed to contradict it.
Features are different, and Rochette draws that line too. You can test that a button functions. You cannot fully pre-write a test for "this button is in the right place, has the right visual weight, and now I want to ship it." Part of the requirement only becomes visible once you see and use the result.
There, the useful infrastructure is not a mountain of acceptance criteria. It is a short loop: generate, try, react, repeat. Final judgment stays human because the measured signal is the reaction itself.
This sounds obvious once written down. Agent workflows make it surprisingly easy to mix the two. We ask for tests to settle a taste problem, then manually inspect a bug that a deterministic check could have settled in one second. Very advanced time management.
The more autonomous the agent, the less I care about its story
There is a slightly counterintuitive consequence.
When an agent performs three simple actions in front of me, its explanation may be enough to follow what happened. When it spends twenty minutes in a repository, calls other agents, runs fifteen commands and edits twelve files, the summary becomes less interesting at exactly the moment it becomes more polished.
I do not only want the story of what it thinks it did. I want artifacts that let me disagree with it.
The diff. Tests. Command output. Screenshot. Source link. Remaining limitations. Something that exists outside the sentence "I checked it."
Rochette pushes the same idea fairly far in code review: shift part of trust away from reading every line and toward a system of explicit verification. That deserves objections of its own. A test can be bad. A specification can be wrong. A whole battery of checks can automate your blind spot with admirable industrial efficiency.
That mostly strengthens the starting point: evidence is useful only when it is not merely the author's own narration of success.
Human work moves up one floor
The more I use agents, the less it feels like my job is to explain how they should code.
It is becoming more about deciding what kind of ending I expect.
For a bug, I want independent evidence. For a feature, I want to see and try the result quickly enough to form my own judgment. Those are different loops. Asking both to return the same generic "completion report" is already a small design mistake.
This is less spectacular than an agent swallowing a GitHub issue and spitting out a PR. It is also harder to automate because it requires knowing the product, the risks and what is actually being delegated.
For a typo in documentation, a green build is probably enough. For a migration that can delete data, I suddenly become much more imaginative about the evidence I require. For an interface, I often prefer ten seconds of preview over three paragraphs explaining that the experience is now "intuitive."
Useful autonomy may not begin when an agent can do more things alone. It may begin when its return gives me the right way to decide: verify when the work is verifiable, try it when the work depends on taste.