Six months after an agent-built feature ships, someone asks why the batch job retries three times and then gives up. The code says what it does. Nothing says why. The engineer who approved it remembers a chat window, and the chat window is gone.
We run production agentic delivery pipelines, and we run our own operations on agents too. Every decision those pipelines make goes into a dated log with a reason attached. That habit started as bookkeeping. It turned out to be the one asset that outlasts the generated output. When AI agents write most of the code, keep a decision record: a dated note of what was chosen, why, what was rejected, who approved it, and what happened next. The code can be regenerated. The judgment cannot.
The output was never the asset
Generated output is cheap to reproduce, so it is not what a team owns. The verified judgment behind it is. Christian Catalini's argument, which Martin Fowler picked up on September 8, 2026, is that AI has cut the cost of generating things without cutting the cost of verifying them. Organizations that measure only the generation get what Catalini calls counterfeit utility: output that satisfies the visible metric while violating the underlying purpose. His advice to professionals is to build a history of decisions, not a gallery of outputs. His advice to companies is to measure verified throughput, the agentic work they can use and accept responsibility for, rather than volume. "Unchecked output is not free productivity," he writes. "It is latent debt."
The volume is real. Docusign CTO Sagnik Nandy told IT Brew in its September 9, 2026 issue that AI has helped create around three-quarters of the company's new code. Any team with a coding agent in its delivery loop is moving the same way. That leaves a question no dashboard answers: when most of the output was generated, what does the team actually own?
Our answer is the decision record.
What should you keep when AI agents write the code?
Keep five things from every consequential agent-built change and let the rest go. In our pipelines, the drafts, the intermediate outputs, and the transcript do not survive. They are working material, and keeping them is how you build a gallery.
The decision and the reason. One sentence for what was chosen and one for why. The reason is the part nobody can regenerate later.
The alternatives rejected. What the agent proposed, what the reviewer turned down, and on what grounds. Catalini calls this kind of record verification-grade knowledge: it teaches a system what to reject, and why. The next reviewer learns more from it than from the list of what shipped.
The verification evidence. What was tested, how, and against what. A patch that passed is a claim. A patch that passed a named test suite on a named date is a fact someone can check.
The approval. Who accepted the change, when, and at which gate. The pipeline stops at defined points and a person signs. The signature and its context go in the record.
The consequence. What happened afterward. The record is not finished when the change merges. It is finished when someone writes down whether the change did what it was supposed to do, and most teams never write that line.
Where the record lives
The decision record lives next to the work, in a form the agent can read back. Ours is one decisions file per month with a one-line index across months, plus a notes field on every artifact the pipeline produces. That field holds the source list, what was checked, and what is still open. A chat transcript is where a decision gets made. It is not where a decision gets kept.
Two rules keep the record honest, and both came from watching it go wrong:
- Record events, never cached state. A decision and its date stay true. A figure like hours remaining is stale the moment someone writes it down.
- Give each fact one owner. A correction replaces the stale line. It does not sit beside it.
We apply the same two rules to the instruction files our agents read, because the failure mode is identical.
The buyer's test
Ask two questions of any team that ships agent-generated work. Six months from now, can someone who was not in the room say why the system is shaped the way it is? Can an auditor see who approved what, when, and against which evidence? A team that answers yes to both can regenerate the code tomorrow and lose nothing. A team that answers no owns a gallery, and in Catalini's terms a gallery of unchecked output is latent debt.
None of this replaces review capacity. As we argued in AI coding moved the bottleneck to code review, the staffing has to follow. The decision record is the part of that review work that lasts. If your team generates most of its output and keeps almost none of its reasoning, our AI implementation framework builds that discipline first.