Your Definition of Done Still Assumes a Human Wrote the Code

Why agentic delivery forces a rewrite of the one acceptance standard most teams never touched, and the five-clause artifact you can lift into your org this week.

Here is the pattern that keeps surfacing in delivery orgs that adopted agentic coding a quarter or two ago. AI-assisted output volume is up. The team merges more, faster, and the activity dashboard says adoption is working. Then someone looks at escaped defects, review load, and rework, and none of those numbers moved. The dashboard proves the tools are used. It proves nothing about whether the output is correct.

Quick answer. An ai definition of done is the acceptance standard rewritten for a world where an agent carried most of the implementation. When a non-human writes the code, "Done" can no longer mean "merged." It has to mean that five kinds of evidence are attached to the change and inspectable: spec compliance, test evidence, review evidence, security and governance evidence, and memory updates. The team that does not rewrite this standard is measuring adoption while its actual output quality drifts unobserved. The artifact in section three is the standard itself, ready to lift.

Most teams already have a definition of done. It is the recognizable agile artifact: a formal description of the state a change has reached when it meets the quality measures the team agreed on, so that "finished" means the same thing to a product manager and a developer. That definition did real work for a decade, and nothing about it was wrong. What changed is not the team's discipline. What changed is who supplies the part of "done" that the checklist never wrote down.

When implementation moved to an agent, the unwritten half of "done" disappeared

A classical definition of done could stay short because a human carried everything it left implicit. A senior engineer brought goal clarity the ticket never spelled out, architecture judgment about how the change should fit the system, a memory of which parts of the codebase tend to break, and the instinct that a number on a screen feels wrong before anyone can say why. None of that was written into the Definition of Done. It did not need to be. The person implementing the work was the same person holding the context, so the context traveled with them for free.

An agent does not carry that context on its own, only what it is given or can retrieve. It will produce a plausible implementation of whatever it was asked to do, whether or not the request matched the actual intent, whether or not the change respects an architecture constraint nobody stated, whether or not the result is the kind of thing an experienced engineer would have flagged on sight. The agent cannot reliably know intent that was never specified, because nothing in its input contains it, and it will fill the gap with a plausible guess instead. The moment implementation moves from the human who held the context to an agent that does not, the unwritten half of "done" stops existing unless someone makes it explicit.

This is the shift the agile-ceremony framing misses. The articles ranking for the definition-of-done topic treat the DoD as a process artifact and AI as a productivity tool, so they never ask the question that matters now: not how fast you reach done, but what done has to certify when a non-human did the work. Done is still the state of the change against the quality measures, but the part of that state a human used to supply by being present now has to be carried as inspectable evidence. A change is not finished because it merged and the build is green. A change is finished when the quality the human used to vouch for in person has been turned into an artifact the team can inspect.

That reframe is the whole article. Everything below specifies what that evidence is.

The five clauses an AI-ready Definition of Done has to certify

An ai definition of done carries five evidence clauses. Each one names a thing a human used to supply by being in the room, and turns it into an artifact the change has to carry. None of these clauses is new in spirit. What is new is that they can no longer be left implicit, because the implicit version assumed a person who is no longer the one doing the work. Read each clause as a pair: the standard, and the specific evidence that makes the clause done.

Spec compliance: the change traces to a versioned spec, not the ticket title

Done means the change implements a versioned spec, and the spec, not the ticket title, defines correct behavior. A ticket title is a label. It says "add export to CSV" and assumes the reader fills in every decision the title omits: which columns, what encoding, how to handle the empty case, what the file is named. A human implementer filled those in from context. An agent fills them in from a guess, and the guess is invisible until it ships wrong.

The spec is where those decisions live. It states what correct behavior is, including the cases it explicitly calls in-scope. The spec compliance clause is done when two things are present in the change: a reference to the version of the spec the work implements, and a check, human or automated, that the implementation does what the spec says across the in-scope cases. The evidence is not "the developer read the ticket." The evidence is the spec reference and the pass against it. When the spec and the implementation disagree, the spec wins by default, and if the disagreement exposed a defect in the spec, the spec gets corrected rather than overridden quietly, because the spec is the artifact that survives the next agent run and the ticket title is not.

Test evidence: a green run against the eval set that defines correct output

Done means the change passes the test suite or eval set that defines correct output, and any new behavior the change introduced added a case to that set. For ordinary code this is the test suite. For AI-product behavior this is the eval set, the curated collection of inputs and expected outputs that specifies what the product is supposed to do. The eval set is not a quality-assurance afterthought. It is the operative part of the behavior's specification, because whoever decides which cases go in the set is deciding what the product is required to handle. Curating the eval set is a product decision wearing a testing costume.

The test evidence clause is done when the change carries a green run against the current set plus the new or changed cases the work introduced. The evidence is the run and the diff to the set, not a developer's assertion that they tested it. The important half of this clause is the second half. A change that adds behavior without adding a case to the set has expanded what the product does without expanding what the product is checked against, which means the next change can silently break the new behavior and nothing will catch it. Agent-assisted output makes this failure mode faster, because it produces new behavior faster than a human remembers to write the cases for it.

Review evidence: a human reviewed against the spec and the risk, and it is recorded

Done means a human reviewed the change against the spec and the risk it carries, not just the diff, and the review is recorded. This clause changed the most under agentic delivery, because agent-generated volume raises review load faster than any other part of the system. When a developer wrote the code, the review was a second pair of eyes on a colleague's reasoning. When an agent wrote the code, the review may be the first substantive human reasoning on the implementation itself, even when a human wrote the prompt or the spec. The author is not accountable the way a human author was, so the reviewer carries more of the correctness than before, not less.

That means the clause cannot just say "a review happened." It has to specify what gets reviewed, at what depth, by whom. A low-risk change to a display string gets a different review than a change to an authorization check or a payment path. The high-risk paths need adversarial review, where the reviewer's job is to find the case the change breaks, not to confirm the change looks reasonable. The review evidence clause is done when the change carries a review record that names the reviewer, states the depth applied, and notes what was checked. The evidence is the record, because a review that left no record is, for the next person who has to trust this change, a review that did not happen.

Security and governance evidence: the checks ran as part of the work, not as a late gate

Done means the relevant security and governance checks ran as part of the change, not as a release gate bolted on at the end. The bolt-on version is a familiar failure mode: governance arrives as a late gate, the change is already built and the deadline is close, and the gate becomes a rubber stamp because stopping the work now is too expensive. Continuous is the alternative. The check runs with the change, so a failure is cheap to fix while the work is still fresh.

What the check is depends on what the change touches. For internal AI usage, the relevant checks are data-flow and approved-tool: does this change send data somewhere it should not, and does it use a tool the org has actually cleared. For AI product behavior, the relevant checks are abuse-case and prompt-injection coverage. OWASP lists prompt injection as the top entry in its 2025 Top 10 for Large Language Model Applications, and the mechanism is worth stating precisely: any input that becomes part of a model's context window is an instruction surface, which means a support transcript, a retrieved document, or an inbound email can carry an instruction the model may treat as authoritative unless the input is validated, segregated, or gated. The security and governance evidence clause is done when the change carries the output of the relevant check, attached to the work and run continuously rather than at a release boundary. The evidence is the check output, because a governance standard that produces no inspectable evidence is a standard nobody can audit.

Memory updates: the durable context the next agent run will read was updated

Done means the durable context the next agent run will read was updated. This is the clause with no precedent in the human-implementer version, because a human carried their own memory and updated it for free by remembering. An agent has no memory between runs. Everything it knows about how this system works, what the standards are, which decisions were already made, comes from durable artifacts it reads when they are loaded or referenced during the run: the spec, the eval set, the standards file, the decision log, and the project memory file a tool like Claude Code reads at the start of a run when it is configured and in scope. If the work changed something those artifacts describe and the artifacts were not updated, the next run reads a description of a system that no longer exists.

The cost of skipping this clause is delayed, which is why it is easy to miss in the moment. The change ships, the dashboard counts it, and the gap only surfaces a week later when the next agent run rebuilds an assumption the team already decided against, or re-solves a problem the decision log would have answered, or violates a standard that was tightened but never written down. AI-assisted work that does not update the memory the system runs on is work the team will redo. The memory updates clause is done when the change carries the updated durable artifact, in the same change or linked to it: the changed spec, the new eval cases, the standards entry, the decision-log line. The evidence is the diff to the durable artifact, because the system does not run on what the team remembers. It runs on what the team wrote down.

The artifact: a one-screen Definition of Done you can lift this week

Here is the standard as a single screen. This is the section a delivery lead forwards to their team and takes to their CTO. Each clause states what must be true and the inspectable evidence a reviewer checks it against, so the standard is checkable rather than aspirational, provided the evidence is real and current rather than a filled-in field. Lift it, change the role names and tool names to match your org, and use it as the definition of done checklist template for any change an agent helped implement.

Three properties make this artifact usable rather than decorative. First, every clause names evidence, not intent, so a reviewer can tell whether a clause is satisfied by looking, not by asking. Second, the evidence lives in the change, so the standard is checkable at the point the work is accepted, by whatever gates acceptance in your workflow, rather than recalled at a retrospective. Third, the clauses are the same whether a human or an agent did the implementation, which means a team does not run two standards. It runs one standard that no longer assumes a human supplied the unwritten half.

The ai code review checklist sits inside this artifact, not beside it. Review evidence is one of the five clauses, and security and governance evidence covers the adversarial and abuse-case checks that a review of agent-generated code has to add. A team looking for a code-review checklist for AI-assisted work has been looking at one clause of a five-clause standard. The other four are what keep the review honest.

Where it plugs in: the cross-stage acceptance contract

The Definition of Done is not a free-floating checklist. It is the place every stage of delivery leaves its evidence. That becomes clear the moment you put it next to the stages that feed it. In the AI-enabled SDLC, the delivery lifecycle splits into eight explicit stages once agents enter it, and each stage produces a per-stage artifact: goal definition produces the goal, the spec stage produces the spec, architecture produces the architecture sketch a human owns, implementation produces the change, QA owns the eval harness, review becomes adversarial, many repeatable quality gates become configuration rather than ceremony, and the measurement loop reads what actually shipped.

The ai definition of done is the cross-stage acceptance contract those eight stages roll up into. Spec compliance reads the artifact the spec stage produced. Test evidence reads the eval harness QA owns. Review evidence reads the adversarial review. Security and governance evidence reads the quality-gate configuration. Memory updates write back to the spec and the standards the next cycle's stages will read. The Done standard is component four of a delivery operating model, the review and control standards, and it is the single component where every other component leaves its trace. Roles and responsibilities, decision rights, workflows, system access, incentives, and operating cadence all touch the Done standard, because the Done standard is where the question "is this acceptable" gets answered, and every other component shaped the answer.

This is why the Definition of Done is the cheapest high-leverage place to change first. You do not have to redesign the whole operating model to start. You rewrite the one component that every other component already writes to, and the act of rewriting it surfaces which other components were never specified. A team that cannot say what its test-evidence clause requires discovers that nobody owns the eval set. A team that cannot fill in review evidence discovers it never decided what high-risk means. The Done standard is a diagnostic as much as a control, because the clauses it cannot fill in name the parts of the operating model that were never built.

There is a related point worth stating plainly, because it determines who can actually enforce the test-evidence clause. The eval set is the operative part of an AI product's behavior specification, which means whoever curates the failure cases is making product decisions, regardless of what the requirements document says. The test-evidence clause is therefore also an ownership statement: it is satisfiable only if someone is accountable for the eval set, and if you cannot name that person, the clause is decorative. The Done standard reads the eval set; it does not create the ownership the eval set requires.

Reading the artifact as evidence that the operating model actually moved

There is a measurement angle here that is easy to miss, and it answers the board question every leader running an AI rollout eventually gets asked: is AI actually changing how we deliver, or just changing our token spend. The honest answer does not come from the adoption dashboard, because the dashboard counts usage and usage is not change. The honest answer comes from looking at the artifacts the work leaves behind. Changed work leaves changed evidence. A team that genuinely rewrote its acceptance standard produces changes that carry spec references, eval diffs, review records, governance output, and memory updates. A team that adopted the tools but never changed the standard produces the same merged commits it always did, faster, with the same evidence gaps.

The Definition of Done is one of the artifacts that shows this. It is inspectable in a way a usage metric is not. You can pick up a sample of recent changes and ask, clause by clause, whether the evidence is present and real. If it is, the operating model moved, because the acceptance standard moved and the work conformed to it. If the slots are filled with stale spec links and empty eval runs, a template moved and the operating model did not. If the changes still look like merged-equals-done with more volume, then tool adoption rose and the operating model did not. This is the lens the Shift Harness Artifact Test applies to AI transformation: it reads whether an operating model changed by examining the artifacts a team produces, rather than the activity metrics it reports. The Definition of Done is one of the six artifact classes the artifact test reads, and it is the one most directly under a delivery lead's control, which is why it is the first one to rewrite.

The distinction matters because the two questions have different answers and different remedies. Delivery and productivity metrics like the ones DORA and SPACE popularized tell you how fast and how smoothly work moves through the system, and they are useful for that. They do not tell you whether the control standard changed, because a team can move merged commits through the pipeline faster than ever while the thing being merged carries less evidence than before. The artifact test is the complement, not the replacement: those metrics read the speed of the pipe, the artifacts read whether what flows through it certifies what it used to.

What changes in your org when you rewrite this one standard

A team that rewrites its Definition of Done has changed one component of its operating model, the review and control standard, in the one place every other component leaves its evidence. That is a smaller change than a reorganization and a larger change than a tool rollout, and it sits in the gap most AI transformations fall into: too far past buying the tools to be satisfying, not far enough into restructuring to feel safe. The rewrite is the cheapest entry point into operating-model change because it requires no new headcount, no new tools, and no permission beyond the authority to say what acceptable means, while forcing every adjacent decision the team had been deferring.

So the action is concrete and it belongs to a named role. The delivery lead or architecture lead takes the five-clause artifact above, fills in the role names and tools that match the org, and tests it against the last ten changes the team shipped. For each change, walk the five clauses and ask whether the evidence is present: is there a spec reference, a green eval run with new cases, a review record with named depth, a governance check output, a memory diff. The clauses that come back empty are not failures of the artifact. They are the map of where the operating model has not changed yet, ranked by how often they came back empty. Start with the clause that was empty most often, because that is the place the work is drifting fastest from the standard the team thinks it holds. The artifact does not just set the standard. It tells you which part of your delivery system to build next.

Frequently Asked Questions