Your Definition of Done Was Built for Human-Speed Coding.
With AI in the picture is your DoD still strong enough?
As Agile practitioners, we’ve spent years helping teams refine their Definition of Done. We helped our teams build checklists to ensure that when a developer says a feature is “done,” it truly meets our quality standards.
But things have changed.
Your current DoD was likely built for human-speed coding.
With the adoption of AI-assisted development tools like GitHub Copilot, ChatGPT, and Claude, developers are generating code faster. Typing code is no longer the bottleneck. The bottleneck is validation.
If your team’s DoD hasn’t evolved to account for AI-accelerated workflows, your safety net has holes.
Here is how you can help your teams rethink their Definition of Done for AI.
Got an urgent question?
Get a quick answer by joining the subscriber chat below.
Updating the Definition of Done for AI-Assisted Development
Start with this line:
Code has been reviewed.
Ask the team what “reviewed” means.
Perhaps AI produced 800 lines, and someone read through them before approving the pull request. That is a review in the shallow sense. But did the reviewer understand the logic? Did they question the assumptions? Could they explain why the approach was safe?
Ask your team:
“What should a reviewer understand before approving a change?”
They may decide to replace the old DoD line with:
The change has been reviewed, and its significant logic, assumptions, risks, and architectural impact are understood.
Do not argue over every word. What matters is the agreement behind the words.
It does not matter whether a developer wrote the code or generated it. The team owns it. If the team cannot explain it, the work is NOT Done.
Quality checks
When AI speeds up coding, work may begin accumulating somewhere else. You might notice more changes waiting for review, testing, integration, or security checks.
When that happens, the team may say, “Review is slowing us down.”
Do not be too quick to agree.
The team may simply be creating code faster than it can validate it. Making the review weaker will clear the queue. It will not make the product better.
Suppose the Definition of Done says:
The pull request has been approved.
Ask:
“Was the change understood, or was it only approved?”
The team might change the line to:
The change is small enough to review effectively, and significant review feedback has been resolved.
Then look at the work. If several changes are waiting for review, the team does not need another change. It needs to finish the ones it has.
Encourage people to review, test, pair, and help each other. Ask them to break large changes into smaller ones. AI can produce a large pull request in minutes. A person still has to understand it one decision at a time.
The tool became faster. Human attention did not.
Preventing faster defect creation
AI works quickly with the information it receives. It also works quickly with the information it does not receive.
Say the requirement is:
Allow customers to cancel an order before it ships.
AI creates a solution that allows cancellation whenever the order has not shipped. It looks correct.
Then someone remembers that an order cannot be cancelled once packing begins.
By then, the code, tests, messages, and documentation may all support the wrong rule. One untested assumption has become a complete feature.
If the Definition of Done says:
Acceptance criteria have been met.
Ask the team:
“Could we meet these criteria and still miss an important business rule?”
If the answer is yes, consider changing the line to:
The Increment has been validated against the acceptance criteria, relevant business rules, boundaries, and agreed failure scenarios.
You do not need to discuss every situation that could ever occur. Talk about the ones that could change the solution.
Can the order be cancelled after packing starts? What happens after payment is taken? What happens if the warehouse system cannot respond?
A short conversation before coding can prevent a long correction afterward.