The transcript is the work
What AI-assisted development is leaving on the table
When a developer opens a pull request, the artifact they’re sharing is a diff. Lines added, lines removed. The what of what changed.
What it doesn’t show (and has never shown) is the why. The approaches considered and rejected. The thing the author almost did before anticipating a roadblock. The question they never thought to ask.
That gap has always existed. In the AI-assisted development era, that gap becomes a lot more consequential.
Coding agents help engineers write code and other agents help review it, but there’s a third dynamic we’re not yet leveraging properly: the transcript of the session between the original engineer and the coding agent.
That transcript is the journey the engineer took to arrive at the destination (the PR) and almost none of it is visible to the code review process today.
Here’s what might change if an agent was able to review it.
For the author, the most immediate win is a PR description that’s more useful. Less “what changed” but “what I tried, what I rejected and why I landed here.” That’s context every reviewer wishes was available but almost never is. It’s tedious as a PR author to write out that narrative when you’re 5 feet from the finish line of your current task. With a coding agent transcript, that story has already been captured for you.
Even before the PR is created, a transcript-review agent could provide an early feedback pass before the PR lands in a human’s lap. “You implemented the happy path quite thoroughly, but haven’t addressed what happens if this external dependency gets flaky.” That’s a PR reviewer comment that didn’t need to get written.
For reviewers, the biggest win is attention calibration. Right now, reviewers reverse engineer intent based on diffs. A transcript-aware review brief flips that: here’s what the author was trying to do, here’s what they considered, here’s an area to focus. More importantly: here’s code that was edited but never discussed. “There was no record of reasoning about this inherently tricky section of code by either the author or their coding agent.”
There’s also a more subtle dynamic: trust. Was the code accepted wholesale from the agent, or did the author push back, ask questions and iterate? That’s not a visible quality of a PR today.
At the org level, the signal compounds. If a dozen engineers are having long, back-and-forth, confusing sessions with coding agents about particular modules or features that’s a crystal clear signal of which parts of your codebase are difficult to reason about and likely hurting your engineers’ productivity.
The indirect effect is the one I find interesting. How does knowing your transcript is reviewable change how you co-create code with a coding agent? Do developers ask better questions, push back more, and explore more edge cases when they know their journey is going to be reviewed as well? Legibility might be a surprisingly quiet lever on agentic engineering craft.
That question immediately raises a harder one: is this just surveillance? Maybe. But there’s a meaningful difference between reviewing transcripts to evaluate engineers and reviewing them to evaluate code. Keep the output focused on quality and reviewer efficiency, not on grading how someone prompted, and the dynamic shifts considerably.
That framing doesn’t eliminate the tensions. Knowing your transcript is visible could still discourage “dumb” questions, compress exploration, or encourage a kind of prompt theater. Those are real risks and while none of them are fatal, they’re worth designing around deliberately.
The main takeaway is this: as AI continues to change how we build software, the artifacts that matter in development will change as well. The diff is still important, but the transcript behind it might be more important - and right now, we’re just throwing it away.
P.S. The same agents already helping developers write and review code are the natural candidates for transcript review. The infrastructure is already there. The question is whether engineering teams start treating the transcript as a first-class artifact - or keep discarding the most honest record of how the work actually got done.