@@ · capturing intent @@

AI code change intent documentation: capture the why before the session dies

Othman Shareef · July 24, 2026 · 6 min read · AI and Code Review

A recent thread on r/devops asks a question that will sound familiar to anyone running coding agents: has anyone lost the reasoning behind an AI-generated Terraform change after the session ended? The change works, it merged, and six months later nobody can say why a timeout is 47 seconds or why the pipeline retries exactly three times. The reasoning existed once, in a prompt session, and then the session closed. AI code change intent documentation is the unglamorous fix: write the why down while it still exists, because nothing else will preserve it.

The session is not a record

It is tempting to treat the agent transcript as documentation: everything is in there, after all. But transcripts are the wrong shape for the job. They are long, unordered explorations full of dead ends, they live outside the repo, and they are routinely deleted, truncated, or lost to tool churn. Even when a transcript survives, nobody debugging an incident at 2 a.m. is going to replay four hundred turns to find the one where a constraint was mentioned. As Addy Osmani notes in his essay on agentic code review, the defining problem of reviewing agent-written code is that the author cannot explain itself; the reviewer reconstructs reasoning that was never written down. The cheapest time to write it down is the moment it is still in front of you.

AI code change intent documentation: the four parts

Keep the artifact small enough that it actually gets written. Four sections cover what future readers need:

  • What was asked. The task as given to the agent, including constraints that shaped it: compatibility requirements, deadlines, the bug report it answers.
  • What the agent chose. The approach in the merged code, and the reason you accepted it. One sentence of judgment: this is the part no tool can generate.
  • What was rejected. Alternatives the agent tried or proposed that you turned down, and why. This is the section that saves the next person from re-walking a dead end, or from mistaking a deliberate choice for an oversight.
  • What is untested. The honest list: paths you did not exercise, edge cases you are trusting the agent on, behavior you verified only by reading. Reviewers should spend their attention here first.

Where the artifact lives

Durability and proximity decide the home. The PR description carries the four sections for the change as a whole; it is the durable record after the branch is deleted. Commit messages carry per-step reasoning, which works best when the work is split into atomic commits: one decision per commit, one why per message, instead of a single squashed blob labeled with the prompt. And when an agent change settles an architectural question (a new dependency, a schema shape, a service boundary), the why belongs in a decision log or ADR, because PR archaeology is a bad way to learn your own architecture. The common thread: if git and the repo do not carry the reasoning, the reasoning does not exist.

Self-review is the capture moment

The practical question is when this writing happens, and the answer is: during author self-review, before requesting review. Walking your own diff is exactly when the gaps announce themselves: here is a line I cannot explain, here is a file I did not expect the agent to touch, here is the tolerance it loosened without asking. Each of those observations is either a fix or a sentence in the intent doc. Self-review used to be good manners; for agent-written changes it is the only point in the pipeline where a person who still has the context inspects the change. Skip it, and the first human to really read the code is a reviewer with none of the reasoning, or an on-call engineer with even less.

What this buys you

The payoff is not tidiness; it is speed at the two moments that matter. At review time, a reviewer with the four sections reads the diff against a stated intent instead of guessing at one, which is most of what makes agentic code review harder than the classic kind. And at incident time, the question why is it built this way has an answer that does not depend on whoever ran the agent still being on the team, or still remembering. The r/devops thread reads like a warning from that future: infrastructure nobody can explain, merged by a process everyone trusted. Ten minutes of writing at generation time is the entire insurance premium. Pay it while the reasoning is still yours to write down.

Frequently asked questions

Why does intent get lost with AI-generated changes?

Because the reasoning lives in the prompt session, not in the code. With a human author you can ask why a change was made months later; with an agent, the conversation that contained the constraints, the rejected alternatives, and the trade-offs is deleted or buried when the session ends. Unless someone writes that context down at generation time, the code merges with no recoverable why.

What should intent documentation for an AI change include?

Four things, briefly: what was asked (the task and its constraints), what the agent chose (the approach actually taken and why it was accepted), what was rejected (alternatives tried or ruled out), and what is untested (paths the author did not verify). A few honest sentences per item beats a generated summary, because the value is the judgment, not the prose.

Where should the intent for an AI change be recorded?

In durable, searchable places tied to the change: the PR description for the overall why, commit messages for per-step reasoning, and a decision log or ADR when the change sets architecture. Chat transcripts and session logs are poor homes; they are unsearchable, unordered, and usually gone. The rule of thumb: if git does not carry it, it does not exist.

← All posts