Why “the agent said it’s done” is the weakest sentence in software, and what should replace it.

Something quietly broke in the last year, and almost no one is naming it.

Writing software stopped being the hard part. Agents now produce working code faster than any of us can read it: a feature in five minutes, a rewrite in an afternoon, a whole system over a weekend. The people doing this aren’t cranks. They’re some of the best engineers alive, and they’ll tell you, honestly, that they’ve stopped reading most of the output. There’s too much of it, and it’s usually right.

So here is the question no one wants to sit with: when the agent says it’s done, how do you actually know?

Three answers, one shape

Right now, the industry has three answers, and all three are the same answer wearing different clothes.

“The tests pass.” The agent wrote the tests. A test written by the same process that wrote the code encodes the same misunderstanding that produced the code. Green means consistent with its own assumptions, not correct.

“CI is green.” Same problem, larger. Green is the absence of a caught error, not the presence of a proven requirement. It tells you the build didn’t fall over. It tells you nothing about whether the thing you asked for is the thing you got. CI passing has never been evidence of capability; it is evidence that nothing contradicted itself.

“Another agent reviewed it.” This is the sophisticated answer, and it deserves a real reply, because the best practitioners genuinely rely on it: one model writes, a second model checks. It is better than nothing. A different model has different blind spots. But it is still two producers grading each other with no external truth to grade against, and no artifact anyone else can re-check. Two confident models can agree, warmly, that a spec neither of them understood was met. When this workflow works, it works because a human expert holds the final gate and their taste catches what the models miss. That is not verification. That is a master craftsman tasting his own cooking, and it stops working the moment you remove the master.

All three answers share one fatal shape: the thing that made the work is vouching for the work. That is self-certification. And self-certification is not verification. Not because the tools are immature, but for a reason no amount of scale will fix.

Why the producer can never be the witness

A producer cannot independently verify its own output. If it could see the flaw, it wouldn’t have shipped it. The blind spot that created the mistake is the same blind spot standing guard over it. This is not a bug in today’s models that tomorrow’s models will patch. It is the structure of the situation. You cannot be your own neutral witness.

For twenty years we papered over this with people. A senior engineer read the diff, felt the shape of it, and staked their judgment on it. That worked, but it was never verification either. It was a trusted human absorbing the risk.

And that human is now the scarcest, most quietly failing part of the whole system. The more the agent does, the less its overseer actually sees. The volume outruns anyone’s attention. And the very skills oversight depends on (judgment, situational awareness, domain instinct) erode in exactly the people who use these tools most. “Keep a human in the loop” sounds like a safeguard. Increasingly, it is a comforting phrase attached to a person who can no longer meaningfully check the work.

So both escape hatches are shut. The machine can’t grade itself. The human can’t reliably watch. And into that gap, the industry is pouring more autonomy: continuous agents that run for hours, unattended, producing mountains of output no one will ever read, each run ending in the same three words: it’s done.

A better producer does not close this gap. It widens it. Every leap in how much an agent can build unwatched is a leap in how much unverified work piles up behind a first-party claim. The faster the factory runs, the more it matters that something at the end of the line is stamping inspected, and means it.

That something cannot be another opinion. It has to be a fact.

What verification actually looks like

The shape of the answer is older than software. In every domain where trust has to travel between strangers, whether a financial audit, a lab result, or a supply chain, you don’t ask the producer whether the work is good. You produce a receipt: an independent verdict, checked against a stated requirement, sealed so it cannot be quietly altered, and portable so that anyone (a colleague, an auditor, a customer, a regulator) can re-run the check and get the same answer without trusting the person who made it.

That is the difference, and it is the whole game:

A claim asks you to trust the builder. A receipt lets you check the work.

“The agent said it’s done” is a claim. A receipt is a verdict: this artifact was checked against exactly this requirement, by an oracle that did not produce it, here is the sealed result, and you can re-verify it yourself. One is a feeling. The other is a fact you can hand to someone else.

This is the part the current moment gets exactly backwards. We are racing to make agents that produce more, faster, with less human involvement, and treating verification as a detail to bolt on later. It is not a detail. In a world where anyone can generate ten thousand lines before lunch, the scarce thing is no longer the code. It is the proof.

What we’re doing about it

I’m not claiming this is solved. It isn’t. Not by us, not by anyone. Independently re-checkable delivery is hard, it is unglamorous, and most of it is ahead of us rather than behind.

But I can tell you the discipline we hold ourselves to while building it. At Eightbells, we are building a coding agent whose entire design starts from the receipt and works backwards: every claim the system makes about its own work must come from an oracle that did not produce that work, pass through a gate that fails closed, and land in a signed, immutable record bound to the exact artifact it describes, down to the byte. No green checkmark counts as evidence. No self-report counts as proof. If the receipt can’t be rendered, the delivery doesn’t count. That includes our own releases, which must pass through this same machinery before they ship.

So Eightbells is not a verifier bolted onto someone else’s factory, and it is not another faster factory; there are plenty of those, and they are getting extraordinary. It is the whole line built around the certificate at the end of it: an agent that does the work and hands you a sealed, independently re-checkable receipt that the work meets the requirement, so you can stop reading the output and start trusting the proof.

Let me stake the position plainly, before this category names itself:

The unit of trust in agent-built software should be a receipt anyone can re-check, not a claim you are asked to believe. Not “green.” Not “the tests pass.” Not “another model looked at it.” Not “it’s done.” A sealed, portable, independently re-verifiable verdict that a requirement was actually met.

Because the agents are going to keep getting better at telling you it’s done.

The question is whether you’ll ever have a reason to believe them.


Cristian Ducu is building Eightbells: a cloud coding agent designed around verified delivery. It has not launched yet.