Managing AI Risks in your Definition of Done

Дата публикации: 27-07-2026 13:50:13

It passed every check.The automated tests were green. The code review was done. The acceptance criteria were met. The feature was deployed to staging and behaved exactly as described in the ticket. By every measure the team had, this work was done.Then it hit production. Within 48 hours, the infosec team flagged two critical security vulnerabilities. A third-party library had been quietly included in the AI-generated code, one with a known Common Vulnerability and Exposure (CVE) and a licensing conflict that Legal was very unhappy about. And when the team sat down to understand what had actually shipped, nobody could fully explain how two of the modules worked. The code was clean. It was efficient. It was completely opaque to the people responsible for maintaining it.The old Definition of Done hadn't failed. It had just never been designed to catch this.Here's the thing: most teams' Definitions of Done were written in a world where a human wrote every line of code. That assumption is now broken. And if you haven't updated your DoD since AI tools entered your workflow, you have a gap; you just might not have hit it yet. The DoD Is Your Quality Contract With the FutureThe Scrum Guide is clear: the Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. It creates transparency. It's the line between "done" and "done-ish."That hasn't changed. What's changed is what quality actually requires when AI is doing a significant portion of the work.AI generates output fast. That's the whole point. But speed without the right quality gates doesn't give you a faster product; it gives you faster accumulation of hidden problems. Technical debt. Capability debt. Security risk. Code that works today but that nobody on the team truly understands, owns, or can safely change tomorrow.The Definition of Done is your primary defense against this. Not the only defense, but the one that matters most, because it's the gate every Increment has to pass through before it can be called done.What an AI-Aware Definition of Done Actually Looks LikeI get asked this question a lot, including at this year's Online Scrum Master Summit. So here's a concrete example. Not a theoretical framework. This is an actual DoD for a software product team that's using AI tools in its delivery workflow.I've structured it in two sections: the standard quality criteria that haven't changed, and the AI-specific quality gates that need to be added. Both sections matter. The AI gates don't replace the standard criteria; they extend them.Part 1: Standard Quality Criteria (Unchanged)These are the things that were true before AI and remain true now. If your current DoD doesn't cover these, fix that first.



Image


Part 2: AI-Specific Quality Gates (New)These are the criteria your DoD is missing if it were written before AI tools were part of how your team works. Each one addresses a real failure mode.



Image


A Note on the Comprehension RequirementI want to spend a moment on this one because it's the criterion that gets the most pushback."If the code is correct and the tests pass, does it matter whether the team fully understands it?"Yes. It does. For several reasons.First, code that works today needs to be changed tomorrow. If no one understands it, every future change is a risk. You're not accumulating technical debt; you're accumulating a set of problems that will cause issues in the future.Second, and more importantly, when you skip comprehension, you're building what I call capability debt. Anthropic published a randomized controlled trial in January 2026 (Shen & Tamkin, arXiv:2601.20245) that put hard numbers on this. They recruited 52 software engineers learning an unfamiliar Python library, half with AI assistance, half without. The AI-assisted group scored 17% lower on a subsequent comprehension quiz than those who coded by hand, the equivalent of nearly two letter grades, while the productivity gain didn't reach statistical significance. They didn't finish meaningfully faster, but they understood meaningfully less.Here's the part I find most important, though: using AI didn't guarantee a lower score. How someone used it determined how much they retained. Developers who used AI to build understanding, ask follow-up questions, request explanations, and pose conceptual questions while working maintained strong comprehension. Those who simply delegated code generation wholesale scored significantly worse. The tool wasn't the problem. Passive delegation was.This is exactly what the comprehension requirement in your DoD is designed to address. It's not anti-AI. It's pro-intentional use. It creates a structural nudge that pushes your team toward the interaction patterns that preserve understanding rather than erode it. The gate isn't "no AI", it's "someone on this team owns this code well enough to explain and defend it."If every piece of complex work goes straight to AI without a comprehension check, your junior developers don't build the foundational skills they need. Your senior developers start to lose the fluency that made them senior. Harvard Business School research (Zhang et al., 2025) found that foundational skills underpin up to 80% of the value of specialist expertise. You can't outsource the learning and expect the capability to stay. The Right Way to Think About ThisYour DoD isn't a bureaucratic checklist. It's a quality contract with your stakeholders, your future selves, and the people who will maintain this product long after the current team has moved on.For most of software development history, that contract could reasonably assume a human made every meaningful decision in every line of code. That assumption no longer holds. And a contract built on a broken assumption doesn't protect you; it just looks like it does.The good news is that updating your DoD is something your Scrum Team can do in a Retrospective. You don't need permission from anyone. You need an honest conversation about what "done" actually means when AI is doing some of the work — and the discipline to hold the line once you've agreed.Start with the comprehension requirement and the human review gate. Add the others as your context and risk profile require. Revisit it every Sprint or two. The Definition of Done is a living agreement, not a document you file once.AI moves fast. Your quality standards need to keep up.

Схожие новости

#	Наименование новости	Тональность	Информативность	Дата публикации
1	The AI Definition of Done	0	7	21-06-2026
2	Die KI-Definition of Done: Human in the Loop ist kein Qualitätsstandard 🇩🇪	-2	6	25-06-2026
3	How to Avoid AI Debt by Borrowing from Agile Artifacts	0	4.94	27-07-2026
4	The New AI Operating Model. Start By Using Scrum	0	6	07-07-2026
5	You Already Have an AI Working Agreement. Write It Down.	0	6.14	12-07-2026
6	Understand Yourself Deeply: Why Scrum Masters Decide to Learn AI	0	10.94	27-07-2026
7	Sie haben bereits eine KI-Arbeitsvereinbarung. Schreiben Sie sie auf. 🇩🇪	0	7.67	16-07-2026
8	Scrum Isn't for Stormtroopers	0	15.26	28-07-2026
9	The Project Manager Isn't Dead. It Was Disassembled on Purpose!	0	16.43	27-07-2026
10	Wie drei Jira-Spalten Release-Prognosen sabotieren – und wie Scrum Teams ihr Board reparieren	0	11.71	28-07-2026

Классификация: . Схожих патентов: 0. Схожих новостей: 10. Тональность: 0. Информативность: 8.24. Источник: www.scrum.org.