{"slug": "after-agents-arrived-prs-took-49-longer-to-merge-stop-opening-them-from-a-first", "title": "After Agents Arrived, PRs Took 49% Longer to Merge. Stop Opening Them From a First Draft", "summary": "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.", "body_md": "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.\n\nThat 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.\n\nMy 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.\n\nFiona 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.\n\nFor AI agents, as opposed to autocomplete-style assistants, they report ([p. 3](https://fion.ac/jellyfish.pdf)):\n\nThe 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)).\n\nPRs 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.\n\nRead 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.\n\nLook 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.\n\nNow 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.\n\n*A review queue with fixed capacity, where every sent-back PR joins the line again.*\n\nThe 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.\"\n\nYou can't hire reviewers fast enough to fix that. You can send fewer drafts into the queue.\n\nWhen 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.\n\nSo 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.\n\nPut 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.\n\nThe 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.\n\nYou don't need a new tool for this. Have the agent work on its own branch, then:\n\n```\n# what the agent changed since the branch split off\ngit diff --stat main...HEAD\n\n# read it in the order it was written\ngit log --reverse -p main..HEAD\n\n# run your own checks, not the agent's summary\nnpm test\n\n# push it, but don't ask anyone to review yet\ngh pr create --draft --fill\n```\n\nSwap `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).\n\nWhen you find something, write it the way you'd write a review comment, and send it to the agent, in the same session:\n\nIn src/orders.ts, refund() no longer checks that the order is paid. Put the check back and add a test for an unpaid order.\n\nName 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.\n\nI build [Hermes IDE](https://hermes-ide.com), so weigh this section with that in mind.\n\nHermes 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.\n\n*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.*\n\nWhen 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.\n\nI 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.\n\nSelf-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.\n\nIt 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.\n\nAI 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)).\n\nHow does your team handle agent PRs today: straight to review, or a pass by the author first? Tell me in the comments.\n\nA 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.", "url": "https://wpnews.pro/news/after-agents-arrived-prs-took-49-longer-to-merge-stop-opening-them-from-a-first", "canonical_source": "https://dev.to/gabrielanhaia/after-agents-arrived-prs-took-49-longer-to-merge-stop-opening-them-from-a-first-draft-5bj1", "published_at": "2026-10-28 21:02:04+00:00", "updated_at": "2026-10-28 21:11:21.679340+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-research", "developer-tools"], "entities": ["Fiona Chen", "James Stratton", "Jellyfish", "Harvard", "GitHub", "Jira", "Google Calendar"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/after-agents-arrived-prs-took-49-longer-to-merge-stop-opening-them-from-a-first", "markdown": "https://wpnews.pro/news/after-agents-arrived-prs-took-49-longer-to-merge-stop-opening-them-from-a-first.md", "text": "https://wpnews.pro/news/after-agents-arrived-prs-took-49-longer-to-merge-stop-opening-them-from-a-first.txt", "jsonld": "https://wpnews.pro/news/after-agents-arrived-prs-took-49-longer-to-merge-stop-opening-them-from-a-first.jsonld"}}