Definition of Done for AI Code: Evidence Instead of Promises

A Definition of Done is the list of conditions under which a task counts as finished. AI-assisted development needs one extra condition that used to go without saying: that somebody has actually understood the code. And it needs evidence instead of promises: "tested" is not a completion, the output of the test run is.

Why does AI-assisted development need a different Definition of Done?

Because the bottleneck has shifted. Writing used to be the expensive step and checking the cheap one. Today it is the other way around: code appears in minutes, understanding it still takes just as long as before.

A Definition of Done that does not reflect this shift declares work finished while its most expensive part is still outstanding. The Stack Overflow Developer Survey 2025 shows where that part then lands: 45 percent of respondents lose significant time debugging AI code, and 66 percent name "almost right, but not quite" as their biggest frustration.

What does a Definition of Done for AI code look like?

Nine points, split by who checks them. The split is the actual trick: whatever a machine can decide must never cost a human any time.

Machine checkable: belongs in the pipeline

• The test run is green, with no skipped tests.
• Coverage of the changed lines is not below the project value.
• No new static analysis findings above the defined severity.
• No new dependencies with known critical vulnerabilities; licenses checked.
• No credentials or secrets in the source code.

Human only: belongs in review

• A named person can explain the change without asking the AI.
• The diff contains only what belongs to the task, no unplanned side effects.
• Permissions and error cases have been considered, not just the happy path.
• Nothing in the project already does the same thing.

The last point is the most specific addition for AI code. A model duplicates whatever it does not know about, and the duplication rate has been rising accordingly for years. No tool asks this question on its own.

How do I make "done" backed by evidence instead of claimed?

By making the evidence, not the promise, part of the completion report. This is a small change with a large effect, because it rules out an entire class of misunderstandings.

• Instead of "tests pass": the last lines of the test output with the count and the result.
• Instead of "I checked it": the command and its output.
• Instead of "it is deployed": the status code of the URL that was actually called.

The reason is not distrust. The reason is that between "I ran it" and "it is green" sits a step that gets skipped in the heat of the moment, and evidence makes that skip impossible without anyone having to police it.

How do I introduce a new Definition of Done without it getting ignored?

By starting with the machine part and adding the human part only afterward. A list that demands nine points on day one turns into a formality by day three.

• First, the five automatic points go into the pipeline. They cost nobody any time and create no discussion, a machine that fails the build is not experienced as condescension.
• Then two human points, not four. Recommended as a starting point: "someone can explain the change" and "the diff contains only what belongs to the task". Both can be judged in seconds and catch most of the problems.
• Add the remaining two once the first seven have settled in. Permissions and duplication checks demand more attention and only pay off once the rest is no longer up for discussion.
• Keep the list visible. As a template in the pull request, not as a page in the wiki. Whatever is not part of the workflow does not exist within the workflow.

One note on expectations: the first few weeks will feel slower. That is not a sign the list is too strict, it is the work that used to happen later now happening in its rightful place.

What explicitly does not belong in the Definition of Done?

Anything that cannot be checked, or does not apply to every task.

• "Code is clean". Not phrased in a checkable way. What is actually meant lives in static analysis and in review.
• "Documentation updated". Only if it genuinely applies to every task, otherwise the point gets dutifully ticked off on every other task and loses its meaning.
• Points nobody checks. A criterion that has been met every time for a year without anyone verifying it is decoration.

Frequently asked questions about the Definition of Done

How is a Definition of Done different from a quality gate?

The gate is the machine enforced part, the Definition of Done is the full agreement including the human points. Ideally the gate enforces exactly the five points above, see What Is a Quality Gate.

Does the same definition apply to prototypes?

No, and that needs to be stated explicitly. A prototype has its own, shorter definition. The mistake happens where a prototype later counts as done without a fresh check, see From Prototype to Production.

How many points can a Definition of Done have?

As many as are genuinely checked on every task. Nine is at the upper limit, and it only works because five of them run automatically.

Who decides whether the definition has been met?

For the machine part, the pipeline. For the human part, the person doing the review, not the person who submitted the change.

The difference between "it is done" and evidence decides whether a Definition of Done actually holds. Code Guardian closes out every change with an audit whose findings are backed by the command that produced them: verified instead of asserted.

Sources

• Stack Overflow Developer Survey 2025, "AI" section (45 percent debugging time loss, 66 percent "almost right").
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research.

As of: July 27, 2026. General professional guidance.