The Definition of Done Needs to Account for How the Code Was Built
The definition of done is one of the more underrated concepts in agile practice. A shared, explicit, team-level agreement on what it means for a story to be complete is the mechanism that prevents the slow accumulation of almost-done work that eventually freezes a sprint. Without it, done means different things to different people, and the gap is always paid for later.
AI-assisted development introduces a new category of questions that most teams’ definitions of done do not yet address. Whether code was generated, reviewed, or written by a human matters for what the verification process should look like — not because generated code is inherently lower quality, but because the failure modes are different and the review process needs to account for them.
A definition of done built for AI-assisted development should address several things explicitly. Prompt or specification review: was the input to the generation step itself reviewed for completeness and accuracy before generation began? Independent test validation: were the tests written from requirements rather than derived from generated implementation? Architectural conformance: does the generated code respect the module boundaries and interface contracts that have been established? Documentation: is the generation context — what was prompted, what assumptions were made — recorded as part of the artifact?
None of these additions are bureaucratic overhead. They are the specific checks that catch the specific failure modes that AI-assisted generation introduces. A team that skips them is not moving faster — it is deferring the cost to production.
The definition of done has always been a forcing function for quality. In an AI-assisted environment, it is also a forcing function for process honesty: an acknowledgment that faster generation does not mean automatic correctness, and that the discipline required to ship reliable software has not decreased. It has shifted upstream.