Keep the agent session next to the code

The agent session is worth as much as the diff it produced, so it should live in Git next to the code. That's Thomas Dohmke's case, and his company Entire builds it: a checkpoint that links the prompts, tool calls and rejected approaches of a session to the commit they ended in. The transcript doesn't prove the code is right. It's evidence that the diff matches what you meant.

Thomas ran GitHub as its CEO and now runs Entire. He gave the talk on day two of AGNTCon + MCPCon North America, October 23, then kept going backstage. I've merged 830 pull requests across my repos since October 1. Most of the sessions that wrote them are already on their way out of my disk, so this one hit close.

The review queue grows two ways

He opened with a confession I recognise. He takes an idea in the morning, prompts an agent to plan it and build it, comes back to working code, opens a pull request like a good teammate, and realises he has no idea what all that code does.

The slides put numbers on it. A chart from The Pragmatic Engineer: teams using coding agents reach 57 pull requests a week, against roughly 10 for traditional teams. A chart from Cursor: those pull requests are getting much bigger too. So the queue grows in two directions at once, more changes and more code in each change.

A pull request still arrives with the old expectation: somebody will read it and understand it. Something has to give, and his next slide showed what does: more AI changes accepted without human review.

He's been guilty of it himself. It's Friday, 4 or 5 pm, the agent says it all works, CI is green and the diff doesn't tell you what could have gone wrong. You have three more pull requests. Approve them, let them wait until Monday, or YOLO merge.

Pull requests a week

Teams with coding agents57

Traditional teams~10

And each onebigger than before, on Cursor's data

1ApproveThe agent says it all works, and CI is green.
2WaitLet them sit until Monday.
3YOLOMerge, and hope the diff wasn't hiding anything.

What givesMore AI changes accepted without human review.

The bars are to scale, from his Pragmatic Engineer slide. The Cursor slide showed a trend, not a figure, so there's no bar for it.

The loop was built around a person

His spiciest line: the software development life cycle, as we know it, is dead.

You've seen the infinity symbol. Write, build and test is the inner loop. Integrate, release, deploy and observe is the outer one. For twenty years DevOps and agile made those loops faster and the batches smaller, and it worked because one developer carried the context, the intent and the idea all the way around the circle.

Now an agent drives on those tracks, and we stand at each station handing it a new direction. The work keeps moving. The question is whether the intent you had at the start travels with it.

Backstage he flipped the old goal. We used to make loops smaller so a person could keep up. Now we need them bigger, so agents keep working while he's on a keynote stage, in a customer call, or asleep, and still build what we wanted without wasting tokens. His most frustrating moment: opening the Codex app on his phone in the morning and finding that a run stopped five minutes after he went to bed.

The cost cuts the other way too. He told students at a hackathon it's no achievement to win a $10,000 prize if you spent $50,000 in tokens on it.

Inner loopWrite, build, test

Outer loopIntegrate, release, deploy, observe

His lineThe software development life cycle, as we know it, is dead.

The infinity loop from his slide, redrawn. The yellow square is whoever is driving: it used to be you.

The repo shows what changed, never why

Next slide: the landing page every GitHub repository has. Folders and files, a README somewhere at the bottom, some metadata on the side. You could read the code and piece the reasoning together from issues, pull requests and commit messages.

More often than we'd like to admit, he said, we went to Slack, Discord or an IRC channel to ask the person who wrote that line what they meant. The repository showed what changed. The why never came with it.

Then the last interface we all shared went quiet. He showed a Cursor headline from April 5, 2026: the editor has become the fallback. He still opens it to check a file an agent wrote. His standard interfaces now are Claude Code in a terminal, Codex in a Mac app, or a tmux setup a developer made their own.

That's where the thinking happens now. The session holds the approach you rejected, and the moment you told the agent "this is correct, but not what I wanted". When the session ends, that learning still matters. In three years it's the only way to time travel back and see what you actually wanted.

The repo page

What changed

Folders and files

A README at the bottom

Commits, issues, pull requests

The why: in Slack, Discord or IRC

The agent session

Why it changed

The prompts and the plan

Every tool call

The approach you rejected

"Correct, but not what I wanted"

April 5, 2026Cursor: the editor has become the fallback.

The struck line is the part that never made it into the repository.

A checkpoint ties the session to the commit

Here's the mechanism. On his slide, the session log sits on the left: tool calls, model responses, what he wanted. The Git commit sits on the right, with its diff and its SHA. In the middle is what Entire calls a checkpoint, linking the two inside Git.

Git, because it's the open-source system we've used for more than two decades, so session logs belong there as Git objects. That also means his teammates can read his sessions, and so can whoever joins the team three years from now.

The open-source Entire CLI is MIT licensed and written in Go. Per its README and docs, it works like this:

entire enable --agent claude-code   # installs agent hooks and Git hooks in the repo
git commit -m "..."                 # the hook asks: link this commit to session context?
entire checkpoint explain <id>      # the prompt, transcript and files behind a commit
entire session resume <branch>      # pick the sessions back up in your agent

The agent hooks capture the session as you work: prompts, transcript, tool activity, changed files and token usage when available.
A checkpoint needs both captured context and a commit. Git hooks add an Entire-Checkpoint trailer to the commit message, and that's the link.
The checkpoint is stored in its own ref under refs/entire/checkpoints/, not as a commit on your branch. Your branch stays clean.
One session can produce several checkpoints, and one checkpoint can combine several sessions.

It supports Claude Code, Codex, Cursor, Copilot CLI, OpenCode and a few more. On top sits Entire's hosted platform, where a Trail groups the intended outcome, the changes across repos, the sessions, review findings, CI results and human approvals, with gates for when a change is ready to merge.

The catch is in the same README. Checkpoints are pushed with your code by default, so a public repository exposes its transcripts. Secret redaction runs before a checkpoint is written, and they call it best effort. They suggest previewing with entire checkpoint list --outgoing, a separate private checkpoint repository, or --skip-push-sessions.

1SessionPrompts, transcript, tool calls, files touched, token usage.
2CheckpointIts own ref under refs/entire/checkpoints/, not a commit on your branch.
3CommitThe diff, the SHA, and a trailer: Entire-Checkpoint: <id>.

His pointNot proof the code is correct. Evidence the diff matches the intent.

The catchPushed with the code by default. A public repo exposes its transcripts.

His slide, redrawn, with the storage details from the CLI's README and docs. The id is schematic.

Git's own idea, applied to the server

The other pressure is load. He showed a chart of commits from Claude Code alone climbing fast, then a GitHub chart from August 2026 with pull requests, commits and repositories up by an order of magnitude or more.

If every agent output waits for a human to review it, we're the bottleneck. And if the infrastructure can't scale as fast as the agents, it's the next one.

His answer is the idea Linus had when he built Git, taken one step further. Git is distributed on our laptops: everybody has their own copy of the repo. Then we all send it back to one central hub. He says that doesn't scale, isn't resilient, and doesn't let you decide which country or region hosts your code.

He calls software the largest team sport on earth. Millions of people in companies, open source, research, schools and hackathons, who don't care which country the others are in and often don't even use their real names. That community deserves infrastructure that's decentralised, open source and independent, like Git and Linux themselves.

Git today

One hub

Every laptop has a full copy

Every push goes to one place

You don't pick the region

His ask

Servers distributed too

Hosting as distributed as the clients

Scales with the agents' output

You choose country and region

August 2026GitHub: pull requests, commits and repos up an order of magnitude or more.

Schematic: the number of machines and links is made up. The square is the central hub.

A merge conflict is a question about intent

Backstage, the host brought up a hot take Thomas had given him earlier: merge conflicts are a skills issue. Thomas explained it.

Merge conflicts got easy. You ping your agent, or have CI do it: the PR has a conflict, fix it. Agents are really good at the common kind, where somebody updated main while your pull request was open and you need to rebase.

The other kind is when two people changed the same thing. Then the question isn't textual any more. Is it my intent or Stefan's that's the right call? That still needs a person.

He sees the same pattern in CI. Nobody writes GitHub Actions workflows in YAML by hand now, the agent does. Then a run takes half an hour, then an hour, and you still need to know what normal looks like before you tell it to optimise.

Main moved under my PR

Agent rebases

Ping it, or let CI do it

Textual, not a decision

Both of us changed the same thing

A person decides

My intent or Stefan's?

The agent has the context, not the call

Same in CIThe agent writes the YAML. You still need to know what a normal run time is.

His two cases, as he told them. Stefan is his example, not a real conflict.

Code and prose go opposite ways

The best five minutes backstage weren't about code. He said that when you let AI write a blog post, it looks amazing on first read. On second look, it sounds like a research paper for an audience that isn't the blog's.

And you can't edit your way out of it. What you read from the AI already mixes into your head so much that fixing sentences doesn't make it human written. For text, you have to work the other way round: draft first, then use the agent as a peer reviewer that gives feedback but never writes the text.

Code went the opposite direction. The AI writes all of it and we verify. At Entire, one of their engineers built an agent called slop cop that checks your code for slop. It's an eval on their platform: orange or red, and you're not allowed to merge. Then you tell your agent to address the slop cop's feedback and it rebuilds, tested against the same unit and integration tests. Rewriting code is easy that way. Rewriting prose isn't.

The host added his favourite: run any review skill in a sub-agent, because a context polluted by the agent that wrote the code can't judge it. Thomas warned about the other extreme, review skills that write thousands of lines of tests for a five-line change on CI minutes you pay for.

Code

Agent drafts

1The agent writes it

2Slop cop: orange or red, no merge

3The agent rewrites, same tests

Prose

You draft

1You write it

2The agent reviews, like a peer

3You rewrite. It never writes the text

WhyYou can't edit your way out of AI text.

The two directions, as he described them backstage.

My sessions expire before my PRs do

This is the part that hit close. My setup: work goes into a GitHub issue, an agent builds in its own worktree, a model from another vendor reviews the change, and every change ends as a pull request I merge myself. Since October 1, that's 830 merged pull requests across my repos.

The pull requests will stay forever. The sessions behind them won't. On the Mac mini right now there are 739 Claude Code session files, 4.7 GB of JSONL, and the oldest is from September 28. That's no coincidence: Claude Code deletes local transcripts after 30 days by default, through its cleanupPeriodDays setting. By mid-November, the reasoning behind every early-October PR is gone.

What survives is what I made agents write down. The issue says what was needed, the PR body says what changed and Closes #N links the two, and a changelog fragment rides in the same PR. That's the why in a few lines. The rejected approach and the "correct, but not what I wanted" moments don't make it.

I haven't run Entire yet, and one thing would stop me on some repos: this site is public, and checkpoints push with the code by default. For a public repo I'd want them in a private checkpoint repository, which the README already suggests.

830pull requests merged since October 1

739Claude Code session files on the mini, 4.7 GB

30 daysbefore Claude Code deletes a transcript, by default

What's still on disk

Before Sep 28: goneSep 28 to Oct 27: kept

Survives in Git

The issue: what was needed

The PR body and Closes #N

A changelog fragment

Rolls off after 30 days

The approach I rejected

"Correct, but not what I wanted"

Every tool call in between

My setup on the day I wrote this. The timeline shows the retention window, not my session history to scale.

Try it

The keynote is about eleven minutes and the backstage part about another eleven. Watch the "SDLC is dead" stretch, then read the Entire README's section on where checkpoints are stored before you enable it on anything public.

If you want more:

Thomas Dohmke's keynote at AGNTCon + MCPCon North America, October 23, 2026 (the session-log part starts here, backstage here)
entireio/cli, the open-source CLI, MIT licensed
Capture checkpoints, Entire's guide to how a commit gets its checkpoint
Review the plan, not the pull request, Dylan Ratcliffe's answer to the same review queue, from the same conference
How the Claude Code team reviews code that Claude writes, six layers of checks before a person reads anything
The agentic software factory is the 2022 one with one box swapped, where my own review queue shows up

If you keep your agent sessions somewhere that outlives the chat window, tell me where. I'd love to know whether anyone reads them again after the merge.

Plain text: agent-session-next-to-the-code.md · Atom feed · All notes