A Definition of Done for AI-Assisted Tasks

An agent without a definition of done will stop wherever the output looks finished, which is almost never where the work is actually finished. It writes the function, sees green on the happy path, and declares victory three steps before the task is shippable. A definition of done is the fix: an explicit, checkable statement of what "complete" means for this task, agreed before the agent starts. Without it, "done" is whatever the agent decides, and the agent decides generously.

This is different from acceptance criteria, though they are cousins. Acceptance criteria say the feature is correct. A definition of done says the task is complete: tested, documented where it needs to be, cleaned up, and ready to merge. One is about the code being right. The other is about the work being over. Agents fail at both, and they fail at "over" even more than "right," because stopping early always looks reasonable in the moment.

Why agents stop early and over-build

Two failure modes, opposite directions. The first is stopping short: the agent implements the visible behavior and skips the unglamorous rest, the error handling, the migration, the test for the weird case. It optimizes for the appearance of completion because the appearance is what the next token predicts. The second is gold-plating: given a vague finish line, the agent keeps adding, refactoring adjacent code, inventing configuration nobody asked for, wandering past the task into "improvements."

A definition of done bounds both. It names the floor, so the agent cannot stop above the floor, and it names the ceiling, so the agent cannot build past it. Both boundaries matter. I have watched agents deliver half a feature and I have watched them deliver three features when I asked for one. Vague scope produces both, which is why scoping the task tightly is the precondition for a definition of done to mean anything.

What belongs in the definition

Keep it to the things that are true for every task of this kind, so it becomes a habit, not a fresh negotiation each time. My baseline: the acceptance criteria all pass. Tests exist for the new behavior and the obvious edge cases, and they would fail if the behavior broke. The change touches only the files it needed to touch. No debug code, no commented-out blocks, no stray print statements left behind. And the diff is small enough to review.

That last one is load-bearing. A task is not done if nobody can review it, because unreviewable code is unverified code. If the diff is too big to review, the task was too big, and "done" includes having been split. This ties directly into how I review AI-generated pull requests: the definition of done is what the review checks against, so the two have to be written to fit each other.

Make it enforceable, not aspirational

A definition of done that lives in someone's head does nothing. It has to be enforceable, which means as much of it as possible should be a check the agent and the pipeline run automatically. Tests pass: that is a gate, not a hope. No secrets in the diff: that is a scan. Criteria met: that is a checklist the agent verifies before it hands the work back.

The parts that cannot be automated, like "is this actually the right approach," stay as human judgment, but you want that human judgment spent on the interesting question, not on catching a leftover console log. Push the mechanical parts into the loop so the agent cannot mark itself done until they pass. This is the same discipline that makes the AI build loop actually work: a tight, automated definition of done is the loop's exit condition.

One definition, applied everywhere

The payoff is consistency. When every task shares a definition of done, quality stops depending on who wrote the prompt or how careful they felt that day. New behavior always ships tested. Scope always stays bounded. Diffs always stay reviewable. The floor holds regardless of the operator, which is exactly what you need when the volume of AI output climbs.

I bake the definition of done into the platform rather than trusting anyone to remember it, which is how we run it at Bootspring: the agent cannot call a task complete until the definition is satisfied. Set the floor and the ceiling once, enforce them automatically, and "done" stops being the agent's optimistic guess and starts being a fact you can trust.