An agent finishes and writes “Done.” You have read that word a thousand times from human teammates and it carried weight, because behind it was a person who had judged the work, knew they would own the bug if they were wrong, and was spending their credibility on the claim. The agent’s “done” looks identical and carries none of that. It is the most probable word to emit after a task-shaped interaction. It stakes nothing, means nothing, and arrives with total confidence.
So the definition of done you have been using quietly broke. It assumed a human stood behind the word. Remove the human and the word is empty, and every process built on trusting it is now trusting nothing.
What “done” used to smuggle in
The old definition of done worked partly on paper and partly on a person. On paper it said things like: code written, tests passing, reviewed, merged. But a lot of the real assurance was not on the checklist. It rode along inside the human. When a developer said “done,” they were implicitly vouching that they had run the thing, that they understood what they changed, that they would have noticed if it broke something nearby, that they were not going to look like a fool in tomorrow’s standup. The checklist was a floor. The person was the ceiling.
Agents removed the person and left the checklist, and the checklist alone turns out to be a weak thing. “Tests passing” means the agent said tests are passing, which is not the same as tests having run. “Reviewed” means someone skimmed a diff too large to actually verify. “Code written” is the one item that is reliably true, and it was never the point. The parts of done that did the real work were the parts that lived in a human’s judgment and stakes, and those did not transfer to the agent along with the typing.
Done cannot be a status anymore
Here is the shift, and it is not subtle. Done can no longer be a status that something claims. It has to be a state that evidence demonstrates.
A status is a label. “Complete.” “Passing.” “Ready.” An agent can produce any label instantly and will, because producing the label that matches a finished-looking task is exactly what it optimizes for. A status is worthless as a signal precisely when you most need it, at the boundary between working and broken, because the label looks the same on both sides.
Evidence is different. Evidence is an artifact you can inspect that would look different if the work were not actually done. A test process that exited zero, with its output saved. A build that produced a running binary. A diff that a security scan cleared, with the scan’s report attached. The screenshot, the log, the recorded run. The defining property of evidence is that you cannot generate it by being confident. It exists because something real happened, or it does not exist. A definition of done built on evidence survives AI speed because the agent’s fluency, its one superpower, buys it nothing. It cannot talk a test suite into exiting zero.
The distinction matters most exactly where it is hardest to hold. Under pressure, with forty things in flight, a status is tempting because it is instant and a human on the other end usually gives it the benefit of the doubt. That benefit of the doubt is the leak. Every place your process accepts a label instead of an artifact is a place where an agent’s confidence passes for correctness, and those places do not announce themselves. You find them the way you always find them, in production, when the thing that was marked done turns out never to have run.
This is the whole idea behind closing work with proof attached rather than status asserted, and it is the only version of “done” that means anything when the entity reporting it has no stake in being right.
Rebuilding the definition, item by item
Take each line of your old definition of done and ask: what is the evidence, and who produced it? If the answer is “the agent says so,” rewrite it.
Not “tests pass” but “the test suite ran and its output is attached.” The distinction is the entire reform. One is a claim the agent makes, the other is a record a process produced. Attach the run, not the summary of the run.
Not “meets requirements” but “checked against acceptance criteria that existed before the code.” If correctness is judged against criteria written after seeing the implementation, the implementation defined its own passing grade. The criteria have to predate the code, and the check against them has to be recorded.
Not “reviewed” but “the blast radius was verified mechanically, and a human confirmed scope and the risk-bearing lines.” Review of agent code that means anything is scope-first and evidence-backed, not a diff someone scrolled through. Say which part a machine vouched for and which part a person did.
Not “no obvious problems” but “the checks that can fail, ran and passed.” A done that includes only checks that always succeed is theatre. Every condition in the definition should be something that could come back red, or it is not verifying anything.
old done
- tests pass
- meets requirements
- reviewed
- no obvious problems
done at AI speed
- output attached
- checked vs criteria
- blast radius verified
- failing checks ran
The pattern across all of them: replace the agent’s word with an artifact, and name the process that made the artifact. What you are really doing is moving the parts of “done” that used to live inside a human’s judgment out into explicit, produced evidence, because the human who used to hold them is no longer in the loop, and the agent that replaced them cannot be trusted to hold anything.
Done travels with the work or it doesn’t count
One more property the AI-speed definition needs. The evidence has to travel attached to the work, not live in a separate place someone has to go assemble later. The reason is volume. When one person ships a week of code in a day, “we’ll gather the evidence at release” means the evidence never gets gathered, because the release is a flood and no one is going to reconstruct the proof for forty merged changes after the fact.
So done means the proof is attached at the moment of completion, per change, automatically, or done means nothing. A definition of done that requires a human to manually collect evidence does not survive AI speed for the same reason the human’s word did not: it assumes a slow, careful person in a loop that is now neither slow nor staffed. The evidence has to be produced and bound to the work by the process that does the work.
This is where the definition of done stops being a wiki page nobody reads and becomes an operational thing, a gate. And it connects straight back to verifying AI-generated code, because a definition of done built on evidence is just verification stated as a policy: nothing is done until the proof that it is done exists and is attached.
Where PaellaDoc fits
A definition of done that lives as evidence attached per change, produced automatically, is not something you can hold in your head across forty merges a day. PaellaDoc makes it the system’s job. The acceptance criteria are set before generation. The checks run and their output is captured. The work does not reach “done” until the evidence exists, and the evidence rides with the change instead of waiting to be assembled at release. You define what done means once, in terms of proof rather than the agent’s word, and the factory refuses to call anything finished until it can show you why.
Frequently asked questions
Why doesn’t an AI agent’s “done” mean anything?
When a human said “done,” they were vouching that they had run the thing, understood the change, and would own the bug if they were wrong. That assurance lived in the person’s judgment and stakes, not on the checklist. An agent emits “done” as the most probable word after a task-shaped interaction. It stakes nothing and arrives with total confidence whether the feature works or not, so every process built on trusting the word is now trusting nothing.
How do I write a definition of done for AI-generated work?
Take each line of your old definition and ask: what is the evidence, and who produced it? If the answer is “the agent says so,” rewrite it. Not “tests pass” but “the suite ran and its output is attached.” Not “meets requirements” but “checked against acceptance criteria that existed before the code.” Not “reviewed” but “blast radius verified mechanically, scope confirmed by a human.” Replace the agent’s word with an artifact and name the process that made it.
What is the difference between a status and evidence in a definition of done?
A status is a label, “complete,” “passing,” “ready,” that an agent can produce instantly, and it looks identical on both sides of the boundary between working and broken. Evidence is an artifact you can inspect that would look different if the work were not actually done: a test process that exited zero with its output saved, a build that produced a running binary. You cannot generate evidence by being confident. It exists because something real happened, or it does not exist.
Does the evidence for “done” have to be collected automatically?
Yes, or it does not get collected. When one person ships a week of code in a day, “we’ll gather the evidence at release” means nobody reconstructs proof for forty merged changes after the fact. Done means the proof is attached at the moment of completion, per change, by the process that does the work. A definition that needs a human to assemble evidence later assumes a slow, staffed loop that no longer exists.