Code review rests on a fifty-year-old assumption: writing code is expensive and reading it is cheap. Coding agents turned that around. What a pull request has to become when machines write most of the code, the two ways the industry is starting to build it, and what we learned building one of them.
Open a pull request written by a coding agent and you get a strange feeling.
The description is perfect: neat headings, a summary, a test plan with every box checked. The diff is 1,200 lines across 31 files. The author's name is yours, because the agent ran on your laptop.
And somewhere in the middle of the diff is a decision nobody made. The agent made it at 3 a.m. while you were asleep. Now it's waiting for a reviewer who'll scroll, see green checks, and type "LGTM".
This isn't a story about bad agents. The agents are good, and that's the problem. They write code much faster than anyone can read it, and the pull request was never designed for that.
This essay is about what the pull request has to become.
The deal code review was built on
Formal code review is older than most of the languages we use. In 1976 Michael Fagan at IBM published a paper on code inspections: a group of engineers in a room, a printout of the code, and a moderator reading it line by line. It was slow and expensive, and it worked.
The next forty years made inspection cheaper without changing what it was. Patches went to mailing lists. Gerrit and Phabricator gave every change a review page. Around 2008 GitHub made the pull request a button, and review became the default way software gets built.
Every form of it rested on the same deal:
- Writing code is expensive. A person spends hours or days on a change, so each change is worth a careful look.
- Reading code is cheap. A reviewer spends minutes on what took the author hours.
- The author is accountable. Someone wrote every line, can explain it, and will remember why tomorrow.
- The conversation is the record. Why something changed lives in the description and the review thread.
From that deal comes the pull request as we know it: a diff, a description, a comment thread, a green CI check, and an approval from someone who has read the change.
The deal is broken
Coding agents reversed it.
| Before agents | With agents | |
|---|---|---|
| Writing | The bottleneck | Nearly free. One developer runs five or six agents, and each one ends in a PR. |
| Reading | The cheap part | The bottleneck. A person still reads at the speed of a person. |
| The author | Can explain the change | A session that ended an hour ago |
| The description | A record | Written by the same model that wrote the code |
On the repository we work in every day, 1,248 pull requests have been merged, and agents opened almost all of them. One person reviews them. Review stops being a quality gate and becomes a queue, and a queue that's too long gets skimmed.
So teams drift into one of two failure modes:
- Review every line. The agents spend most of their time waiting for a person.
- Stop reading and approve on vibes. The team finds out what it merged in production.
Neither is a fix. The fix is a different idea of what a pull request is for.
What a pull request has to become
Strip the PR down to its job:
Decide whether this change can land, and leave a record of why.
In 1976 the only way to do that job was a person reading the code. That's no longer true. Here is what the job looks like now, as six principles.
1. Review intent, not lines.
The first question about agent code isn't "is this line right?" It's "what was the agent asked to do, and did it do that?" A thousand-line diff from five prompts is five things to check, not a thousand.
2. Machines review first, on every push.
Review agents with clear instructions (security, correctness, your team's rules) run on every new commit, and each review names the commit it reviewed.
3. Many reviewers, one voice.
Three agents posting three comment threads is three times the reading. Their findings are merged: duplicates folded, agreement counted, disagreement shown.
4. A finding starts a loop, not a thread.
A finding becomes a task, an agent pushes the fix to the same branch, and the reviewers run again. It's resolved when the next review doesn't raise it, not when someone ticks a box.
5. Merge conditions are rules, not habits.
"Someone looked at it" isn't a rule. "Every required reviewer approved this exact commit, nothing high-severity is open, CI is green" is one. A machine can check it the same way every time.
6. Keep determinism where it matters.
A gate has to give the same answer twice, and an agent run doesn't. CI stays the source of pass/fail. Agents explain failures, trace them to their cause, and fix them.
None of this is exotic. It's the same goal as Fagan's inspections, catching problems before they ship, rebuilt for code that arrives faster than anyone can read it.
Two ways to build it
Nobody has agreed on the shape yet, but two approaches are taking form.
Replace the host. On 26 October Entire launched as a Git forge built around these ideas. Its Trails replace the PR: review agents score every push, and gates combine approvals, CI and findings. Because it hosts the repo and the CI, it can redesign everything from scratch.
Build a layer on top. Leave GitHub or GitLab where it is, with its branch protection and CI, and add an agent-aware layer above it. Nobody moves a repository, and everything also shows up on the host's own PR page. The price: you're limited by each host's API.
"The pull request has become an audit log that only the agent reads."
— Entire, launch post
We took the second approach. For the past few months we've been building it into a tool called Origin. It started as a way to record what coding agents do in a repository: the prompts, the diffs, the cost, and which agent wrote which line.
That record turned out to be exactly what a pull request was missing. The rest of this essay walks through one PR's life with the six principles built in: the details that mattered, and what broke.
A pull request's life, rebuilt
The queue
It starts with the list of open pull requests. Each row shows how many agent sessions produced it and the live state of every review agent: queued, reviewing, approved, or changes requested.
Open pull requests, each with the live state of every review agent.
Principle 1 · Review intent, not lines
Open a PR and you can read the diff grouped by prompt instead of by file. Each card is one request: the agent, the model, the prompt, the decisions it recorded, then the code it wrote.
Restore rolls the code back to before that prompt, if the prompt sent the agent the wrong way.
One card per prompt, then the code that prompt wrote.
Two details made this trustworthy:
- One line, one answer. A line's commit comes from blame at the PR's head, and one function maps commit to session to prompt for every view: the diff, blame, CI failures and review comments. If two views could disagree about a line, you couldn't trust either.
- The intent comes from the agent, while it works. Agents write short markers as they go (an intent, a decision and its reason), and the hooks save them with the turn. A validator then checks each claim against what was captured, and flags "added tests" when no test file changed.
What the agent meant to do, and the decisions it made on the way.
Principle 2 · Machines review first, on every push
A review agent is a job: what to look for, which repos it covers, which coding agent runs it, and when. It can run manually, when a PR opens, or on every push, and it can be marked required.
Three review agents, two of them required.
One choice shaped everything else: review agents run on the developer's machine, not on our servers.
- People pay for Claude or ChatGPT subscriptions that sign in an agent on their laptop.
- The laptop already has the repo's toolchain.
- Running code from someone else's repo on our servers would be a security product of its own.
So the server keeps the queue and the results, and a small runner on the developer's machine does the work:
- GitHub: a PR opens or gets a push. One review is queued per reviewer and commit, never two at once.
- Laptop: the runner, a background service, claims the oldest queued review for a repo it has checked out.
- Laptop: it checks out the PR's head in a separate worktree. Your own checkout is untouched.
-
Laptop: it runs the agent read-only, e.g.
claude -p --permission-mode plan, with the prompt the server built. - Server: the verdict and findings come back, go to GitHub, and update the status check.
The review is read-only by construction: Claude runs in plan mode and Codex in its read-only sandbox, with no "skip permissions" flag. Each finding comes back with a file, line, severity, failure scenario and a confidence of confirmed or plausible.
The prompt is where this beats a generic review bot. A bot sees a diff. This reviewer also sees which agent, model and prompt wrote each file, the decisions the authors recorded, and the open TODOs from the repo's history. It also gets these rules:
From the reviewer's instructions
- Confirm a finding by reading the code it is about. Mark it "confirmed" only when you traced the failure.
- "High" means it breaks the change or exposes data in a reachable path. Style and preference are not findings.
- The authors' own notes are claims, not proof. A stated verification you can't see in the diff is worth a finding.
That last rule matters more than it looks. When the author is an agent, "I verified it" is something to check, not something to trust.
Each review is recorded like any other agent session, so its cost sits on the PR next to the cost of writing the code. Ours take 2 to 20 minutes and cost about $0.70 to $1.10 each.
Principle 3 · Many reviewers, one voice
Once two or more reviewers have finished, a judge combines their findings into one list. Duplicates are folded together, each finding says who raised it, and disagreements stay visible.
Three reviewers, one list.
Each reviewer's own run stays one click away, with its session and what it posted on GitHub.
Each reviewer's own run, and what it posted on GitHub.
Because this is a layer on top of the host, everything also lands on GitHub, for people who never open the tool:
- One summary comment per reviewer, edited on later runs instead of repeated.
- Inline comments on changed lines. GitHub rejects a whole review if one comment points outside the diff, without saying which, so every line is checked against the diff first.
- No duplicates on re-runs. Each inline comment carries a hidden marker (reviewer, file, line, title hash), so a re-run posts only what's new.
- A status check that branch protection can require.
Principle 4 · A finding starts a loop
Every finding has a Fix button, and the judge's list has Fix all. Either one creates a task on the PR's own branch, so the agent pushes to the same PR instead of opening a new one. The push is a new commit, so the reviewers run again:
Push → Reviewers → Judge → Findings → Fix task → Agent pushes the fix ↺
Repeats on every push, until the merge rules hold on the current commit. Then it merges.
There's no "resolved" checkbox, on purpose. A ticked box proves nothing. A clean review of the commit that will merge proves a lot more.
Principle 5 · Merge conditions are rules
This is the real replacement for "a person read it". A repository, or a whole workspace as a default, sets its merge rules: required reviewers approve, no findings above a chosen severity, CI passes, a person approves.
Merge rules, as a workspace default and per repository.
One function checks the rules and returns a line per rule: met or not, and why. The Merge button, the PR page and auto-merge all read that same answer, so the button and its explanation never disagree.
What stands between this PR and the merge, one line per rule.
The idea was simple. The details took most of the work:
-
Everything is checked against the head commit. An approval of commit
a1b2says nothing aboutc3d4. A review of an older commit fails the rule, even if it found nothing. - "Head" means what the host thinks it is. We once ordered a PR's commits differently from GitHub and posted the status on the wrong commit. Now every status post asks the host first.
- Auto-merge is stricter than the rules. It lands code nobody clicked on, so it needs an explicit approve of exactly this commit from every required reviewer, and no check failing or still running.
- Auto-merge acts as a person. It merges as whoever turned it on, re-checks their permission every time, and says so in the audit log.
- It wakes on every event that could unblock a merge: a review finishing, a person approving, CI completing.
None of this replaces the host. Branch protection still applies, and a merge on GitHub's own page follows GitHub's rules.
Principle 6 · Keep determinism where it matters
CI stays the source of pass/fail. Agents work around it:
-
Failures traced to prompts. A failed check's
file:linegoes through the same blame step, so "the type check failed" becomes "it failed on a line written by this prompt". - Fix with an agent. A failed check gets a button that creates a task on the PR's branch with the failure, the suspect commits and the end of the log. It ends with: "Don't change the check to make it pass."
- Local CI for repos without CI. The same runner runs a fixed test command on every new commit. The command lives in the tool, not the repo, so no branch can decide what runs on your laptop.
The record
The timeline shows everything GitHub's conversation tab shows, plus what only the agent layer knows: which sessions started, which prompt produced which commit, and the fixes agents were asked for.
The pull request's story, with the sessions and prompts behind each commit.
What broke along the way
- Work queued with nobody to run it. With a reviewer on every push, one repo queued more than twenty reviews a day, and nothing ran them without a runner. Now the runner installs as a background service, the card says "Waiting for a runner" with the command, and stale reviews expire.
- Approvals of code that no longer existed. Before every check was tied to the head commit, an approval from three pushes ago kept a PR green. The first version didn't have this rule. It's now the most important one.
- Agents believed agents. Before the "claims, not proof" rule, a reviewer would read "added tests" in the description and take it as true.
- Hosts set the limits. Inline comments work on GitHub only for now, and RhodeCode has no CI event to react to. That's the trade-off of building on top, and the one Entire avoided by becoming the host.
What a pull request is now
The pull request isn't dying. It's still the place where a change waits before it lands, on the same host, behind the same branch protection. What changes is the contract.
| The old contract | The new contract |
|---|---|
| A person read it, and CI is green. | Every required reviewer approved this exact commit. Nothing above the bar is open. CI is green. A person signed off if the repo says one must. Every line can be traced to the request that produced it. |
When a person does look, they don't read a thousand lines. They read five requests and the decisions behind them, and decide whether those were the right things to ask for.
That was always the point of review. Fagan's inspections were never about reading code for its own sake. They were about catching the wrong decision before it shipped.
Agents just took the reading off our hands.
Whether the future is a new forge or a layer on the forges we already have, the direction is the same: review on every push, mostly by machines, against rules anyone can read, with people spending their attention on decisions instead of diffs.
Origin, the layer described here, is at getorigin.io. It connects to GitHub, GitLab and RhodeCode and leaves your repositories where they are.
Top comments (0)