研究指企業採用 AI 編碼智能體後，PR 合併時間增加 49%；作者建議先審閲初稿

• Book: Event-Driven Architecture Pocket Guide
• Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

The agent finished in eleven minutes. You glanced at the summary, the tests were green, and you opened the pull request. Then it sat there for a week, came back with "changes requested", and a teammate spent an afternoon writing comments the agent could have fixed in one more turn.

That wait is not a hunch. In a Harvard working paper covering 718 firms, the time from submitting a pull request to merging it rose 49% after firms adopted AI coding agents. The share of PRs sent back with a formal request for changes nearly doubled. Lines of code went up 30%. Finished work, measured as resolved Jira issues, showed no statistically significant gain.

My take: an agent's first draft is not a pull request. Review it yourself, send the corrections back to the agent that wrote the code, and open the PR only when you would sign it. Your teammates' review time is the scarcest thing in that pipeline. Stop spending it on drafts.

What the paper actually measured

Fiona Chen and James Stratton used Jellyfish engineering-analytics data: about 300 million work events from GitHub, Jira and Google Calendar, January 2021 to March 2026 (paper, pp. 1–3). They compare firms that adopted AI tools earlier with firms that adopted later or not at all, a staggered difference-in-differences design. Adoption is measured per firm, not per developer.

For AI agents, as opposed to autocomplete-style assistants, they report (p. 3):

• lines of code up 30%, commits up 20%, pull requests up 23%
• small, statistically insignificant gains in resolved Jira issues and epics, ruling out an output increase larger than 12% of the baseline

The review numbers are on pp. 22–23. Days from PR submission to merge rose by 3.45 on a baseline of 7.03, the 49%. The standard error is 1.60 days, so the true effect could be a lot smaller or larger. The share of PRs where at least one reviewer formally requested changes rose by 0.12 from a baseline of 0.13. Review comments per PR rose by 0.58 from a baseline of 1.66, a 35% rise. AI assistants showed no significant effect on any of those three. The share of workers doing any code review rose 14% with agents, and 10% with assistants (p. 24).

PRs did not get bigger. Lines added per PR showed no significant change, against a baseline of about 1,168 (p. 23). So the extra rounds aren't explained by PRs growing.

Read it with care. It is a job market paper, current version August 4, 2026, not peer-reviewed. It is observational. Jellyfish reviewed the manuscript only to check it disclosed nothing proprietary, not for its scientific content (p. 1). And it does not record whether any given PR came from an agent's first draft. That part is my argument, not their finding.

A PR sent back is a retry

Look at code review as a queue. Authors produce PRs, reviewers consume them, and the number of reviewers moves slowly. The paper found firms pulling more people into review, but writing sped up faster.

Now add the changes-requested rate. Every PR sent back goes around again: the author fixes it, it re-enters the queue, and a reviewer reads it a second time. That is a retry, and retries add load to the stage that is already the bottleneck. Going from roughly one PR in eight sent back to one in four means far more second reads landing on the same reviewers who were already behind.

A review queue with fixed capacity, where every sent-back PR joins the line again.

The authors give two possible reasons for the extra review work (p. 23): code quality may have dropped, or review standards may have changed. One junior engineer they interviewed described a team where "only one senior engineer was allowed to approve changes," who "could only review my code once a week," and new rules after outages "requiring senior engineer approval for AI-generated code, which created even more review bottlenecks."

You can't hire reviewers fast enough to fix that. You can send fewer drafts into the queue.

The first draft belongs to you and the agent

When a human teammate writes code, the first draft already passed through one reader: the person who typed it. They thought about each line as it went in. An agent's first draft skips that step. It arrives fast and confident, and the first human who reads it closely is often your reviewer.

So the revision loop moves. Corrections that used to happen in the author's head now happen in PR comments, between two humans, at the queue's pace. A request for changes means a round trip through someone else's day.

Put that loop back where it is cheap. The agent that wrote the code is sitting right there with the context loaded. A correction you send it costs one turn. The same correction left as a PR comment costs a reviewer's read, your context switch back, a new push and a second review.

The rule I'd use: you read every change before anyone else is asked to. Anything you'd flag in someone else's PR, you send back to the agent first.

Do the revision loop before the PR

You don't need a new tool for this. Have the agent work on its own branch, then:

# what the agent changed since the branch split off
git diff --stat main...HEAD

# read it in the order it was written
git log --reverse -p main..HEAD

# run your own checks, not the agent's summary
npm test

# push it, but don't ask anyone to review yet
gh pr create --draft --fill

Swap npm test for your own test command. The three dots in main...HEAD show only what your branch changed since it left main. On GitHub, a draft pull request "cannot be merged, and code owners are not automatically requested to review" it, which is the state you want while you and the agent still disagree. --draft and --fill are documented in the gh manual.

When you find something, write it the way you'd write a review comment, and send it to the agent, in the same session:

In src/orders.ts, refund() no longer checks that the order is paid. Put the check back and add a test for an unpaid order.

Name the file, say what's wrong and say what done looks like. Then read the new diff, run the checks again, and repeat until you'd approve it yourself. Only then run gh pr ready, which marks the PR as ready for review. Write the description yourself. If you can't explain the change in two sentences, the reviewer can't either.

How Hermes IDE does it

I build Hermes IDE, so weigh this section with that in mind.

Hermes saves every agent turn, so you can diff or restore a single turn, with undo. The Review Desk (⌘G, Ctrl+Shift+G on Windows and Linux) shows a task's changes by turn or by file, with risk flags, and a line comment you leave there goes back to the agent that wrote that line. That is the pre-PR loop from the last section, without copying file names and line numbers into a terminal by hand.

The Review Desk (⌘G) in By turn view for a Claude Code task in orders-api: two turns (T1: 3 files +69 −1, T2: 1 file +1 −0), turn 1's diff of src/db.ts adding a refunded status, the changed files and a commit message drafted from the turns.

When the turns look right, Land commits, opens a pull request or merges locally in one step, into the branch the task started from, and can be undone. Your own checks can decide when a task is done. Hermes is free, source-available under BSL 1.1, and runs on macOS, Windows and Linux. The current release is 2.3.4, from October 15, 2026. It isn't affiliated with Nous Research, Anthropic, OpenAI or any agent vendor.

I wrote about the turn-by-turn reading itself in Stop Reviewing Your Coding Agent's Final Diff. Skip that reading and the cost lands on your reviewer.

Where this won't save you

Self-review doesn't replace a second reader. You and the agent share the same blind spots about the task, because you wrote the prompt. A reviewer who wasn't in the session still catches things you can't.

It also costs your time. If you ship a dozen small agent PRs a day, a full pass on each is real work. My bet is that someone reads that code closely either way, and the choice is whose afternoon it takes.

AI review bots won't drain the queue for you either. By March 2026 nearly 80% of the firms had used AI tools in code review, yet AI wrote only 23.3% of review comments, and 10.8% of PRs got any AI comment at all (p. 25). People still did most of the reading, and the authors report that the bottleneck persists after firms adopt AI review tools (pp. 4–5).

How does your team handle agent PRs today: straight to review, or a pass by the author first? Tell me in the comments.

If this was useful

A review queue backs up for the same reasons any queue does: producers speed up, consumers don't, and every retry joins the line again. The Event-Driven Architecture Pocket Guide is my short book on systems built around queues and messages, with sagas, CQRS, the outbox and the traps nobody warns you about. If you want the pre-PR loop without the copy-paste, download Hermes IDE and star it on GitHub if it helps.