From the Build Side — A Column from Maycon Santos
As AI makes production nearly free, the word done quietly starts meaning two different things — and the one it stops meaning is the one that ships work worth trusting.
“There is a moment most delivery teams reach without noticing it happen: the definition of done stops being applied, because the work moves faster than anyone goes back to it.”
We marked a task done on a Tuesday. The tests passed, the demo worked, the reviewer approved it, and we moved the card to the right. The following Tuesday, two of us were rebuilding most of it, because the thing we had called done handled the happy path and almost nothing else. Nobody had cut a corner on purpose. We had simply never agreed on what done was supposed to mean before we declared it. That was the last time we left that question unanswered.
Done Is Two Words Wearing One Label
It is tempting to read that as a testing problem, or a code review problem, and to fix it with a stricter gate on the pull request. That is the wrong diagnosis. What actually happened is that the word done was carrying two different meanings, and we had stopped noticing the difference. There is done as in produced: the code exists, it runs, it looks like the thing. And there is done as in verified: the work has been checked against a definition of what it had to do, and it holds. Those are not the same state. For most of the history of software they stayed close enough to treat as one, because producing the code was slow enough that the producing and the checking moved at roughly the same pace.
That is the assumption AI quietly broke. When an engineer working with AI produces in an afternoon what used to take three days, the producing accelerates and the checking does not. The definition of done, which used to keep up with the work because the work was slow, now falls behind it. And a definition that falls behind does not stop the work. It just stops being applied. Done drifts, sprint after sprint, from verified against what we agreed toward looks finished, because looks finished is the part AI made cheap, and verified is the part it did not.
This is not a small effect, and it now shows up in the way the industry measures itself. In its 2025 report on AI-assisted software development, DORA found that AI adoption has started to lift delivery throughput, teams really are shipping more, while it continues to correlate with greater instability: more change failures, more rework, longer time to recover when something breaks[1]. The shift was consequential enough that DORA added a new core metric, Rework Rate, the share of deployments that exist only to fix what an earlier deployment got wrong. Read that plainly. The industry just made rework a first-class number, because work increasingly looks done and then has to be done again. Read carelessly, this looks like an argument against AI. It is not. It is an argument about what happens to a definition of done when the work stops waiting for it.
The Gap Is Something Teams Already Feel
I have watched this happen on teams that were, by every visible measure, disciplined. They wrote tickets. They reviewed pull requests. They had a definition of done written on a wiki page somewhere. The page was not the problem. The problem was that the definition lived in a document, and the work moved faster than anyone went back to the document, so done became a judgment call made in the moment by whoever was closing the ticket.
The people doing the work feel the gap even when they cannot name it. In Stack Overflow’s 2025 developer survey, one of the largest of its kind with more than forty thousand respondents, AI tool adoption climbed to 84 percent, while the share of developers who trust the accuracy of those tools’ output fell to 33 percent, and more developers now actively distrust that output, at 46 percent, than trust it[2]. The same survey found that the most common reason developers would still turn to another human, named by 75 percent of them, is precisely when they do not trust the AI’s answer[2]. Sit with that. A team can adopt a tool almost universally, decline to trust most of what it produces, and still move the card to done, because done has come to mean the code is here and it runs, not the code has been checked against what it owed and it holds. The trust gap is the definition gap, showing up as a feeling.
The Slowness Was an Accidental Gate
Here is the distinction most of the coverage misses, because it is busy arguing about whether AI writes good code or bad code. The quality of the generated code is not the mechanism. The mechanism is that slow production used to be an accidental gate. When building took three days, you had three days in which to remember what the thing was supposed to do, to notice the edge case, to feel the discomfort that means not yet. That gate was never designed. It was a side effect of things being slow, and it quietly enforced a definition of done that nobody had to write down. AI removed the slowness, and with it the accidental gate, and exposed that the definition underneath was never actually load-bearing on its own.
So this is a diagnosis of absent structure, not of AI, and the difference is the whole argument. When the definition of done is explicit and checkable before the work starts, when done names specific conditions the work must satisfy and something other than a tired human judgment can confirm them, then cheap production becomes exactly what you want. Every nearly free unit of output lands against a bar that does not move, gets checked against it, and either passes or comes back. The speed compounds into finished work instead of accumulating into rework. Structured AI is not the slow, cautious option. It is AI aimed at a definition of done that was decided before the firing started.
Decide What Done Means Before the Work Begins
So if you lead delivery, the question to stop asking is whether the team is shipping faster. It almost certainly is, the speed is real, and it is not the thing to worry about. The question to start asking is where your definition of done actually lives, and when it gets applied. If the honest answer is that done is decided in the moment, by whoever is closing the ticket, against a standard reconstructed from memory after the work already exists, then you do not have a definition of done. You have a label you attach to work once it looks finished. The fix is not another review stage bolted onto the end. It is deciding, in writing and in checkable terms, what done means before the work begins, so the speed has something fixed to land against. Once we moved the definition to the front, the speed stopped working against us and started to compound.
The risk was never that AI would write the wrong code. It is calling it done before deciding what done has to mean. Settle that first, and speed turns into completion instead of motion.
Sources
- DORA (Google Cloud). State of AI-assisted Software Development 2025. 2025. https://dora.dev/dora-report-2025/
- Stack Overflow. 2025 Developer Survey, AI section. 2025. https://survey.stackoverflow.co/2025/ai
Verification date: 2026-06-11. Each figure was confirmed present and accurate at its cited source on that date. Both sources were published within the trailing twelve months, per MKT_Article_Standard section 12.3.