After Agents Arrived, PRs Took 49% Longer to Merge. Stop Opening Them From a First Draft

A Harvard working paper by Fiona Chen and James Stratton, drawing on roughly 300 million work events from Jellyfish engineering-analytics data across 718 firms, found that time from pull request submission to merge rose 49% (3.45 days on a 7.03-day baseline) after firms adopted AI coding agents, while the share of PRs receiving formal change requests nearly doubled and lines of code rose 30% with no statistically significant gain in resolved Jira issues. The author argues the fix is to treat an agent's first draft as a draft rather than a pull request—reviewing it and sending corrections back to the agent before opening the PR—since every sent-back PR re-enters an already bottlenecked review queue. The paper is observational, not peer-reviewed, and does not record whether individual PRs originated from agent drafts.

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 https://fion.ac/jellyfish.pdf 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. Fiona Chen and James Stratton used Jellyfish https://jellyfish.co engineering-analytics data: about 300 million work events from GitHub, Jira and Google Calendar, January 2021 to March 2026 paper, pp. 1–3 https://fion.ac/jellyfish.pdf . 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 https://fion.ac/jellyfish.pdf : The review numbers are on pp. 22–23 https://fion.ac/jellyfish.pdf . 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 https://fion.ac/jellyfish.pdf . PRs did not get bigger. Lines added per PR showed no significant change, against a baseline of about 1,168 p. 23 https://fion.ac/jellyfish.pdf . 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 https://fion.ac/jellyfish.pdf . And it does not record whether any given PR came from an agent's first draft. That part is my argument, not their finding. 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 https://fion.ac/jellyfish.pdf : 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. 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. 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 https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests "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 https://cli.github.com/manual/gh pr create . 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 https://cli.github.com/manual/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. I build Hermes IDE https://hermes-ide.com , 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 https://github.com/hermes-hq/hermes-ide/releases , 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 https://dev.to/gabrielanhaia/stop-reviewing-your-coding-agents-final-diff-review-it-turn-by-turn-44l7 . Skip that reading and the cost lands on your reviewer. 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 https://fion.ac/jellyfish.pdf . People still did most of the reading, and the authors report that the bottleneck persists after firms adopt AI review tools pp. 4–5 https://fion.ac/jellyfish.pdf . How does your team handle agent PRs today: straight to review, or a pass by the author first? Tell me in the comments. 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 https://www.amazon.com/dp/B0GX3B8371 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 https://hermes-ide.com/download and star it on GitHub https://github.com/hermes-hq/hermes-ide if it helps.