Definition of Done for AI Builders: The Quality Bar Every Agent Build Must Clear

Your agent will tell you it is done. It will say so confidently, with a green checkmark, a passing demo, and a tidy summary of what it built. And it will be wrong often enough that "the agent said done" has quietly become the most expensive phrase in AI building. The problem is not that the agent lies. The problem is that nobody told it what done means, so it picked its own definition, and its definition is "the happy path runs."

For most of software history, that gap was covered by a team. A developer finished a feature, but "finished" was understood to include tests, a review, and a deploy, because the team shared an unwritten standard. Now the developer is an agent that has no unwritten standards and no shared anything. It has whatever you wrote down, and it fills the rest with the shortest path to something that looks complete. So here is the hypothesis this post rests on: the more of your building an agent does, the less you can rely on a shared sense of "done," and the more you need that standard written down as one explicit, every-feature bar. That bar has a name. It is your definition of done.

#What a definition of done actually is

The term comes from agile, and the agile definition is worth keeping because it is clean. A definition of done is a shared set of conditions a piece of work must satisfy before anyone calls it complete. Scrum.org puts it as a formal description of the state of the work when it meets the quality required for the product. The key word is "shared." It is not per-feature. It is the standing bar that applies to every feature, the checklist that is true whether you are shipping a login screen or a billing page.

That makes it different from the thing it gets confused with. Acceptance criteria answer "is this the right thing," feature by feature. The definition of done answers "is it built to standard," every time. A login feature's acceptance criteria might say a wrong password shows an error. Your definition of done says, for that feature and all the others, that the tests pass, the change was verified against its criteria, and it works in a real environment, not just a demo. One is specific to the feature. The other is the bar underneath all of them. You need both, and we go deep on the per-feature half in how to write acceptance criteria an AI agent can verify. This post is about the standing bar.

Strip away the agile vocabulary and the idea is older than software. A definition of done is just the answer to a question every builder has always had to answer: when do I get to stop. The answer used to live in people's heads. It cannot anymore.

#Why AI builders need one more than anyone

Here is the part that surprises people. Definition of done is treated as a process nicety, a thing mature teams have and small teams skip. For AI building, it is the opposite. The smaller and faster your operation, the more you need it, because the agent is moving faster than your ability to catch what it skipped.

Consider the line from the apimatic team's writeup on moving from vibe coding to agentic engineering with Claude Code:

"It should work correctly" is not a criterion.

That is the whole problem in five words. To you, "it should work correctly" is obviously the bar. To an agent, it is noise, because nothing in it is checkable. The agent cannot run "correctly." It can run a test, hit an endpoint, render a page. When your standard is a feeling and the agent only understands facts, the agent ships the version that matches the facts it can see and silently drops everything else. A definition of done is how you translate your felt standard into facts the agent, and you, can actually check.

The stakes scale with autonomy, which is exactly why this gets worse as the models get better. Addy Osmani, talking about the loop-driven way agents now work, made the point cleanly when The Register pushed back on the whole idea:

The loop changes the work, it does not delete you from it. The agent runs more of the loop unattended every month. The work that does not disappear is deciding what the loop is allowed to call finished. A definition of done is that decision, written once, applied to every run.

#What goes in it (and what does not)

A good definition of done for AI building is short, concrete, and the same for every feature. It is not the feature spec. It is the floor. Here is the difference between a standard an agent can clear and a wish it cannot.

The wish: "The feature should be done, tested, and ready for users."

The standard: "Every acceptance criterion is verified with evidence. Automated tests for the new behavior pass. The change runs in a real preview environment, not just locally. Inputs that should fail (empty, wrong, malformed) are handled, not just the happy path. Nothing that worked before is broken."

The first one feels complete and checks nothing. The second one is five facts, each of which is either true or false for any feature you build. An agent can be pointed at the second list. You can read down it at the merge button. Neither of you has to interpret a mood.

Notice what is not on it. There is no business logic, no "the report should show monthly revenue," no feature detail at all. That belongs in the acceptance criteria for that one feature. The definition of done is deliberately generic, because its job is to be the one bar that holds no matter what you are building. The moment it starts describing a specific feature, it has stopped being a definition of done and become a spec.

Here is how the two layers sit together across a build.

Loading diagram...

Acceptance criteria gate the front of the build: are we building the right thing. The definition of done gates the back: is what got built allowed to be called finished. An agent that passes the first and fails the second has built the right feature badly, which is the single most common way AI work looks done and isn't.

#The trap, and the honest limit

The failure mode to name out loud is the demo. An agent produces something that runs in front of you, and a running demo is the most persuasive evidence there is and the least reliable. The demo is the happy path the agent was always going to nail. Your definition of done exists to ask the questions the demo never does: what happens with bad input, what broke upstream, is there a single shred of evidence beyond "it looked fine when we clicked it." Approving because the demo worked is approving the eighty percent and inheriting the missing twenty.

And the honest limit, because pretending otherwise would be its own kind of hype. A definition of done is a floor, not a ceiling. It catches the predictable, repeatable gaps, the missing tests, the unhandled error, the broken neighbor. It will not catch a subtle security flaw or a design decision that is technically "done" and strategically wrong. For a personal project, a strong definition of done plus behavioral review is genuinely enough to ship with confidence. For anything touching real user data or money, you still want a deeper technical pass on top. The bar raises your floor a lot. It does not replace judgment about which floor you need.

#How to make the bar enforce itself

A definition of done that lives in your head, or in a doc nobody opens, is the same as not having one. The whole value is that it gets checked, every feature, without you remembering to. That is the gap between knowing the standard and having it hold.

This is where BrainGrid fits, and it sits on both sides of the build. When you describe a feature, the Planning Agent turns it into a requirement with explicit acceptance criteria, so the per-feature "right thing" is written down before any code exists. When the Builder Agent builds it, in BrainGrid Cloud with a live preview or in your own repo with Claude Code, Cursor, or Codex, verification checks the result against every one of those criteria and reports the evidence, so "verified against its criteria" stops being a hope you have to police and becomes a step that runs on every feature. That is the standing bar made automatic: the same check, every build, with proof attached. It is the Verify step of the loop, Plan, Build, Verify, Repeat, and it is what turns "the agent said done" into "here is the evidence it is done."

So here is the verdict on the hypothesis. The faster your agent moves, the less a shared sense of done can be assumed and the more it has to be written, because the one thing an autonomous builder cannot supply is its own standard for stopping. Write the bar once. Make every feature clear it. The code got cheap and fast. The decision about what counts as finished is still yours, and it is more load-bearing than it has ever been.

#FAQ

#What is the definition of done in code?

In code, the definition of done is the standing set of conditions a change must meet before it can be merged or shipped, applied to every feature rather than written fresh each time. Typical conditions are: automated tests for the new behavior pass, the change was verified against its acceptance criteria, it runs in a real environment and not just locally, error and edge cases are handled, and nothing that previously worked is broken. It is deliberately generic. The feature-specific requirements live in the acceptance criteria; the definition of done is the quality floor that holds regardless of which feature you built.

#What is the difference between definition of done and acceptance criteria?

Acceptance criteria are specific to one feature and answer "did we build the right thing": a wrong password shows an error, the report totals monthly revenue, and so on. The definition of done is generic and answers "is it built to standard": tests pass, criteria were verified, it deploys, edge cases are handled. Acceptance criteria change with every feature. The definition of done stays the same across all of them. You need both, because a feature can satisfy its acceptance criteria (right thing) and still fail the definition of done (built badly, no tests, breaks something else).

#What is DoR and DoD in agile?

DoR is the Definition of Ready and DoD is the Definition of Done. The Definition of Ready is the bar a piece of work must clear before anyone starts building it, usually meaning it is clear, scoped, and has acceptance criteria. The Definition of Done is the bar it must clear before anyone calls it complete. For AI builders the pair maps neatly onto the loop: readiness is whether the plan is good enough to hand to the agent, and done is whether what the agent produced is good enough to ship. Both exist to stop guessing, one at the start, one at the end.

#What does "done" mean in software?

In software, "done" means a change meets every condition the team agreed defines completeness, not just that it appears to work. That usually includes the feature behaving as specified, automated tests passing, the change reviewed or verified, and it deploying to a real environment without breaking existing behavior. The reason teams write this down as a definition of done is that "done" otherwise means something slightly different to everyone, and an AI agent has no shared sense of it at all. Without an explicit standard, "done" collapses into "the demo ran," which is the weakest possible bar.

#Do small teams or solo builders really need a definition of done?

Yes, and arguably more than large teams do. A big team has reviewers, QA, and shared habits that catch skipped steps even when nothing is written down. A solo builder shipping through an agent has none of that backstop, and the agent moves faster than any one person can manually inspect. A short, explicit definition of done is the fastest way to get a quality floor without a team: five or six conditions, the same for every feature, that the agent is held to and you can read at the merge button. It takes minutes to write and prevents the most common and most expensive AI failure, shipping something that looked done and wasn't.

BrainGrid plans every feature into acceptance criteria and verifies each change against them with evidence, so "done" stops being the agent's opinion and becomes a bar you can prove. Try it at braingrid.ai.