The Definition of Done I Use for AI-Assisted Work

A change came through recently that passed every check we had. Tests green, review approved, ticket closed. It was also not done, in any sense I care about, because when I asked a simple question about how it handled a particular case, nobody on the team could answer without going back to read code an agent had written and none of us had really absorbed.

That is the gap the old definition of done misses now. "It passes" used to imply "someone understands it," because a person had to build it to make it pass. The agent broke that link. Passing and understood are separate states now, and only one of them holds up when something goes wrong.

It is a subtle failure, because nothing looks broken. The board is green, the client is happy, the demo works. The gap is invisible right up until the day you need to change the thing, or explain it, or fix it under pressure, and discover that nobody actually holds it in their head. A definition of done that only checks the visible signals will pass that work every single time.

So I use a different definition for anything an AI helped build. Not a heavier process, just a few questions I make us answer honestly before we call it done.

Someone on the team can explain how it works, not just point at a green tick. If the only proof it works is that the tests pass, we do not understand it yet, we are trusting it. A person read the change line by line, and that person is answerable for it. Not skimmed. Read. The one whose name is on it did the reading.

The edge cases were checked by a human, not assumed. Agents are reliably good at the happy path and reliably casual about the ugly parts: the empty result, the timeout, the input nobody expected. That is exactly where I slow down now. And it was built against the real requirement, not the one the agent inferred, because models fill gaps with something plausible, and plausible is not the same as correct.

None of these are exotic checks. They are the things a good senior did instinctively when they reviewed a junior's work, back when all work came from a person you could ask. The agent removed the person you could ask, so the checks that used to be instinct now have to be written down and done on purpose, because the instinct has nothing to attach to.

The last two are the ones I would not drop. The decisions baked into the work were decisions someone actually made. If the code committed us to an approach, a human chose that, on purpose, rather than inheriting it because the agent went that way and it happened to work. And the real test underneath all of it: if this broke at two in the morning, could someone fix it? That is where you find out whether the understanding is really there, or whether you have shipped a black box that works today and belongs to no one.

None of this is about distrusting the tools. I use them all day. It is about being honest that speed on the build does not buy you understanding for free, and understanding is the thing that lets you sleep. The agent can make the work. It cannot make you sure, and "done" was always a quiet claim about being sure.

I have watched teams resist this, and I understand why. It feels like adding process to something that was finally fast. But it is not really process. It is just refusing to let speed talk you out of understanding, and understanding was never the slow part. Skimming was fast. Being able to answer for the thing is what actually took the time, and it still does.

I keep this deliberately short, because a definition of done that runs to two pages is one nobody actually uses. Six questions, asked out loud, before the ticket closes. Most of the time the answers are yes and it takes a minute. The value is entirely in the times the answer is no, and someone has to say so before the thing ships instead of after.

Running them out loud is the part that matters. Asked out loud, "can someone explain how this works" is a completely different event from quietly assuming someone can. It puts the understanding on the table while there is still time to go and get it, instead of discovering its absence in the week it finally matters. A checklist you tick privately after the fact catches nothing. A question you have to answer in front of the team catches the thing before it ships.

So here is the one worth stealing and arguing with: on your team, what does "done" mean for something an AI wrote, and would that definition survive someone asking you, calmly, to explain exactly how it works?