The Review Rework Loop: How Repeated "Changes Requested" Rounds Stretch Pull Request Cycle Time
Why do some pull requests go back and forth between author and reviewer for a week before they merge? Learn what engineering leaders on Reddit say about endless code review rounds at enterprise scale, and how Keypup MCP uses changes-requested and approval dates, review states, reviewers, lines changed, repositories and linked Jira issue types to measure how often pull requests go back for rework, what each round costs, where it happens and which pull requests are stuck in rework right now.
TL;DR: In large engineering organizations, a significant share of pull requests don't merge after one review: they go back to their author with "changes requested", come back, and go back again. This is the review rework loop. It rarely shows up in cycle time reports as its own phase, yet on the pull requests caught in it, it is often the longest one. The Keypup MCP Server reads each pull request's first and last changes-requested dates, review request dates, first review date, last approval date, merge date, current review state, last commit date, lines changed and repository, plus every submitted review with its reviewer and state, and the issue type of the Jira issue it resolves. Your AI assistant can then measure how often pull requests go back for rework, where the time goes, how size, reviewers, repositories and kinds of work affect it, and which pull requests are stuck in rework right now.
Every engineering leader has seen the pull request with forty review comments, three "Request changes" reviews and a final approval that arrives a week after the code was first "done". Few can say how many of those pull requests exist, or how much delivery time the back-and-forth absorbs — because standard reports measure the wait for a first review, not what happens after it.
The Friction: "Done" Code That Isn't Done
In a team of six, a pull request that bounces three times is a conversation at the next retro. In an organization with 1,500 engineers and 400 repositories, the rework loop becomes invisible for structural reasons:
Cycle time reports stop at "time to first review". Most review dashboards measure how long a pull request waited before someone looked at it. What happens between the first review and the final approval is folded into one number.
Review standards live in people's heads. One reviewer blocks on naming and test structure; another approves anything that passes CI. Authors learn which reviewer to avoid, not what the standard is.
Design disagreements surface late. When nobody agreed on the approach before the code was written, the pull request becomes the design review — and every round costs a full rewrite.
Each round costs a context switch on both sides. The author has started something else; the reviewer has to reload the change. A round that needs ten minutes of work can take a day of calendar time.
The result: code that was finished on Monday merges the following Tuesday, and leadership sees slow delivery without seeing where it came from.
Why This Matters: The Real Cost of Review Rework
The Throughput Problem
A pull request in its third review round is work in progress that has already been paid for and delivers nothing. Multiply that by thousands of pull requests and a meaningful share of your engineering capacity sits in "almost done".
The Morale Problem
Repeated rounds are where code review turns personal. Authors who are sent back three times by the same reviewer stop proposing ambitious changes; reviewers who feel ignored escalate. Neither side has data, so the conversation stays anecdotal.
The Measurement Problem
A long cycle time can mean a hard problem, a slow reviewer or a design that should have been discussed before coding started. Without separating the rework loop from coding and queueing, you can't tell which — and you fix the wrong thing.
The Enterprise Discussion: What Engineering Leaders Are Actually Saying
Endless review rounds, nitpicking reviewers and "review as design meeting" come up again and again wherever engineering managers, staff engineers and directors compare notes. The quotes below are representative of recurring threads on r/ExperiencedDevs, r/EngineeringManagers, r/programming and r/softwareengineering.
"My PR has been through four rounds of 'changes requested'. Every round a different reviewer finds something new, and half the comments contradict the previous round. The code was ready two weeks ago."
Engineering Manager, Enterprise SaaS Company (r/EngineeringManagers)
"Our cycle time looks fine until you split it. Time to first review is under a day. Time from first review to approval is four days on anything non-trivial. Nobody was measuring that part."
Director of Engineering, Healthcare Group (r/EngineeringManagers)
"I have one team where every senior requests changes on almost everything, and another where nobody ever does. I can't tell which one has the right bar, and I have no numbers to start the conversation."
The pattern holds: leaders feel the cost of review rework, but the reports they use don't isolate it — so the rework loop stays invisible.
How Keypup MCP Measures the Review Rework Loop
The Keypup Model Context Protocol (MCP) Server gives your AI assistant structured access to the data Keypup imports from GitHub, GitLab, Bitbucket, Azure DevOps and Jira. For this analysis, what matters is each pull request's creation date, first and last review request dates, first review submission date, first and last changes-requested dates, last approval date, merge date, current review state, last commit date, lines changed and repository; every submitted review with its reviewer, state and submission date; and the issue type of the Jira issues each pull request resolves.
In the prompts below, changes requested means a formal "Request changes" review. A pull request had changes requested twice or more when its last changes-requested date is later than its first. The rework loop is the time from the first submitted review to the last approval. Durations are in business hours — Monday to Friday, 09:00 to 17:00 UTC by default; adjust the working hours and time zone to match your teams.
1. Running a Review Rework Health Check
The first question: how often does a pull request go back to its author before it merges?
MCP Prompt:
For pull requests merged in the last 12 months, show the number
of pull requests, the share that received at least one
changes-requested review, the share that had changes requested
twice or more, and the median business hours from creation to
merge for pull requests with no changes requested and with
changes requested twice or more.
Output: Review Rework Health Check — Last 12 Months
Key Insight: One pull request in eight goes back to its author at least twice. Those pull requests take a median 61.5 business hours to merge — more than four times as long as pull requests approved without a change request.
2. Seeing Where the Time Goes When Reviews Bounce
Is a bounced pull request slow because it waited longer for review, or because of the rounds themselves?
MCP Prompt:
For pull requests merged in the last 12 months, grouped by no
changes requested, changes requested once, and changes requested
twice or more, show the median business hours from creation to
review request, from review request to first review, from first
review to last approval, and from last approval to merge, as
stacked bars.
Output: Where Does the Time Go When Reviews Bounce?
Key Insight: On pull requests sent back twice or more, the rework loop is 43.2 business hours — over five working days, and six times the wait for a first review. Coding and queueing barely change between groups: the extra time is almost entirely spent between the first review and the final approval.
3. Testing Whether Size Drives the Loop
Are bounced pull requests simply the big ones?
MCP Prompt:
Group pull requests merged in the last 12 months by lines
changed — under 100, 100 to 399, 400 to 999, 1,000 or more. Show
each group's share of merged pull requests as columns and the
share with changes requested twice or more as a line.
Output: Does Size Drive the Rework Loop?
Key Insight: A pull request over 1,000 lines is six times more likely to go back twice than one under 100 lines. The 23% of pull requests above 400 lines account for almost half of all repeat rework: splitting them is the cheapest fix on this page.
4. Checking Whether Reviewers Are Calibrated the Same Way
Size explains part of the loop. Does the reviewer explain another part?
MCP Prompt:
For pull requests in the payments-api and checkout-web
repositories, show each reviewer's number of submitted reviews
in the last 12 months against the share of those reviews that
requested changes, as a scatter plot. Size each point by the
median lines changed of the pull requests they reviewed. Exclude
dismissed reviews and anonymize names.
Output: Are Reviewers Calibrated the Same Way?
Key Insight: Two reviewers request changes on more than 40% of their reviews, against 14% for the median reviewer. Reviewer F also reviews the largest pull requests, which explains part of the gap; Reviewer C does not. That is a calibration conversation about standards — not a performance ranking.
5. Finding Which Kind of Work Bounces Most
Do some kinds of work go back more often than others?
MCP Prompt:
For pull requests merged in the last 12 months, grouped by the
issue type of the Jira issue they resolve — or no linked issue —
show the share with changes requested twice or more, the median
business hours from first review to last approval, and the
number of pull requests.
Output: Which Kind of Work Bounces Most?
Key Insight: Tech debt and Story work bounce far more often than Bugs and Tasks: 17% and 14%, against 9% and 8%. Bugs and Tasks usually arrive with a clear expected fix; refactors and new features are where author and reviewer discover in review that they disagree on the design. This breakdown only works when pull requests reference the Jira issue they resolve, and "Tech debt" only appears if it exists as an issue type in your Jira.
6. Seeing Where Reviews Bounce Most
An organization-wide rate hides the repositories where the loop concentrates.
MCP Prompt:
As a heatmap, show the share of pull requests merged in the last
12 months with changes requested twice or more, by repository
and size bucket of lines changed (under 100, 100 to 399, 400 to
999, 1,000 or more). Add the number of merged pull requests per
repository.
Output: Where Do Reviews Bounce Most?
Key Insight: Size explains a lot, but not everything. identity-service sends back 9% of its smallest pull requests twice or more — three times the rate of data-pipelines — and 47% of its largest. Where small changes bounce, the cause is usually unwritten standards, not size.
7. Listing the Pull Requests Stuck in Rework Right Now
The last step turns the analysis into a list someone can act on in today's stand-up.
MCP Prompt:
List open pull requests whose review state is changes requested.
Show the repository and number, lines changed, whether changes
were requested more than once, business hours since changes were
last requested, whether commits were pushed since then, whether
a review was requested again since then, and age in business
hours. Sort by age.
Output: Pull Requests Stuck in Rework Right Now
Pull Request
Lines Changed
Changes Req. 2+
Since Last Changes Req. (bh)
Commits Since
Re-Review Req. Since
Age (bh)
identity-service #2291
1,240
Yes
26.5
No
No
71.0
payments-api #4815
610
Yes
18.0
Yes
No
52.5
checkout-web #7702
880
Yes
15.5
Yes
Yes
47.0
platform-infra #1938
420
No
22.0
No
No
39.5
mobile-app #6127
315
No
9.5
Yes
No
28.0
identity-service #2304
95
Yes
7.0
Yes
Yes
24.5
data-pipelines #3360
230
No
12.5
No
No
19.0
checkout-web #7731
160
No
4.0
Yes
No
11.5
Key Insight: Three of the eight have had no commit pushed since changes were requested — the fix hasn't reached the pull request yet. Three more have new commits but no new review request, so the reviewer may not know they are ready. Only two are genuinely back in a reviewer's queue.
The Technical Implementation: What Keypup MCP Actually Reads
Every number above comes from fields Keypup already imports from your Git platforms and Jira. It helps to be precise about what they are — and what they aren't.
Rounds Come From Changes-Requested Dates
For each pull request, Keypup records the date changes were first requested and the date they were last requested. When the last date is later than the first, changes were requested at least twice. The Reviews dataset also holds every submitted review with its state — approved, changes requested, commented or dismissed — so you can count changes-requested reviews per pull request or per reviewer. These measures depend on your Git platform recording a formal "request changes" review outcome, as GitHub's "Request changes" does: check how your platform's review votes map before comparing teams across platforms. Two more things to keep in mind: a review left as plain comments, without "Request changes", isn't counted; and the date-based measure can't tell a second round from a second reviewer: two reviewers requesting changes on the same version of the code, a few hours apart, also count as "twice or more".
Phases Come From Review Timestamps
The phases come from the creation date, review request date, first review submission date, last approval date and merge date. If your teams never use the platform's "request review" feature, there is no request date and the queue phase can't be separated from coding.
Reviewer Calibration Comes From the Reviews Dataset
Each review carries its author, state, submission date and the lines changed and repository of the pull request it belongs to. Keypup can hash usernames in a report, so you can look at the distribution before you look at names.
"Waiting on Whom" Comes From Commit and Request Dates
For an open pull request, comparing the last commit date and the last review request date with the last changes-requested date shows whether the author has pushed a fix and whether they asked for another look. Keypup doesn't read review comment threads to decide whether each comment was addressed.
Issue Types Depend on How Pull Requests Reference Jira
Keypup links a pull request to the Jira issues it resolves when the issue key appears in the pull request title, or in its description or a commit message after an auto-closing keyword such as "fixes" or "resolves", and exposes the issue types of those issues on the pull request. Types are read as configured in your Jira instance. A pull request with no key shows no linked issue.
Business Hours Come From a Formula, Not a Calendar
Keypup's BUSINESS_HOURS function counts working time between two dates — Monday to Friday, 09:00 to 17:00 UTC by default — and accepts a different time zone, working hours and working days. It doesn't know about public holidays or vacations: Keypup doesn't import calendars.
Real-World Impact: Enterprise Case Studies
Case Study 1: European Payments Provider
Before Keypup MCP:
1,100 engineers across 300 repositories
Time to first review under one business day, yet median pull request cycle time above four business days
Recurring complaints from authors about "moving goalposts" in review
After Keypup MCP:
The phase breakdown showed the rework loop accounting for most of the cycle time on bounced pull requests, which moved the conversation away from review speed
The size analysis showed pull requests above 400 lines driving almost half of repeat rework; teams adopted a soft 400-line limit and stacked pull requests for larger changes
The share of pull requests with changes requested twice or more fell from 13% to 7% in two quarters
"We had spent a year making reviews start faster. It turned out our problem was what happened after the first review. Once we could see the rounds, splitting large changes did more than any SLA."
— VP Engineering, European Payments Provider
Case Study 2: North American Insurance Group
Before Keypup MCP:
750 engineers, 2,500+ pull requests merged a month
Two platform teams with very different review cultures and no shared standard
Design decisions routinely made inside pull request comments
After Keypup MCP:
The reviewer scatter showed a three-fold spread in changes-requested rates between reviewers of the same repositories, which started a calibration session instead of a blame session
The issue type breakdown showed Stories and Tech debt bouncing most; teams introduced a short design note for any Story expected to exceed 400 lines
Leads review the open "stuck in rework" list at stand-up, nudging authors who haven't pushed and reviewers who haven't been asked again
"The data didn't tell us who was right. It told us we hadn't agreed what 'good' looked like — and that every disagreement was costing us days."
— CTO, North American Insurance Group
Implementation: Getting Started with Keypup MCP
1. Connect Your Git Platforms and Jira
Connect GitHub, GitLab, Bitbucket or Azure DevOps, and Jira, to Keypup. Pull requests, reviews, review dates and commits are imported automatically.
2. Make Review Outcomes Explicit
Ask reviewers to use the platform's "Request changes" and "Approve" actions rather than plain comments, and authors to re-request review once they've pushed a fix. Without those signals, rounds and "waiting on whom" can't be measured.
3. Reference Jira Keys in Pull Requests
Ask teams to put the Jira issue key in the pull request title, or after an auto-closing keyword in its description, so each pull request is linked to the issue — and the issue type — it resolves.
4. Connect the MCP Server to Your AI Assistant
Follow the MCP documentation to connect Keypup to Claude, ChatGPT, Cursor or any MCP-compatible assistant.
5. Set a Baseline, Then Work the List Every Day
Run the health check and the phase breakdown to set a baseline. Then bring the "stuck in rework" list to stand-up, review the size and repository heatmap each month, and run the reviewer calibration view once a quarter.
Frequently Asked Questions
What is the code review rework loop?
The rework loop is the time a pull request spends between its first review and its final approval, going back and forth between author and reviewer. In this article, a pull request is caught in it when changes were requested twice or more.
How do you measure code review rounds?
Count the "Request changes" reviews each pull request receives, or compare its first and last changes-requested dates. Keypup MCP does both, from the review dates on each pull request and the review states in the Reviews dataset.
Why do pull requests go through so many review rounds?
The most common causes are large pull requests, design disagreements discovered during review rather than before coding, and inconsistent standards between reviewers. Measuring the loop by size, kind of work, repository and reviewer shows which one dominates in your organization.
How can we reduce review rework?
Keep pull requests small, agree on the approach for larger changes before writing code, write down review standards per repository, and make sure authors re-request review as soon as they've pushed a fix.
The Bottom Line
A pull request that goes back to its author three times isn't a slow reviewer or a careless author — it's a signal about size, design and standards. Keypup MCP shows how much of your cycle time the rework loop absorbs, and why:
✅ Measuring how often pull requests go back for changes before they merge ✅ Separating the rework loop from coding, queueing and merging ✅ Testing how pull request size drives repeat rework ✅ Comparing reviewer calibration without turning it into a ranking ✅ Finding which kinds of work bounce most, from linked Jira issue types ✅ Showing where the loop concentrates, by repository and size ✅ Listing the open pull requests stuck in rework and who they're waiting on
Ready to see how many rounds your pull requests go through before they merge? Connect the Keypup MCP Server and ask your AI assistant.
Ready to Transform Your Analytics?
Join teams already using AI to make data-driven decisions faster than
ever.
Why do some Jira tickets bounce between engineers and teams for weeks before anyone fixes them? Learn what engineering leaders on Reddit say about ticket reassignment churn at enterprise scale, and how Keypup MCP uses previous assignees, assignment dates, issue types, projects and linked pull request authors to measure how often tickets change hands, what each hand-off costs in cycle time, who actually wrote the code and which open tickets are being passed around right now.
Compare the 6 best engineering analytics tools for Jira and Git in 2026 — Keypup, LinearB, Jellyfish, Swarmia, Faros AI and Pluralsight Flow — across Git and Jira unification, DORA Metrics and cycle time, dashboard customization, AI and natural language, integration breadth, setup speed and security. Find out which platform turns your code and ticketing data into one reporting layer with prescriptive recommendations.
Why do pull requests sit for days before anyone reviews them? Learn what engineering leaders on Reddit say about code review bottlenecks at enterprise scale, and how Keypup MCP uses review request dates, first review dates, approvals, reviewers and lines changed to measure your wait for first review, break cycle time into phases, find when requests get stuck, show who carries the review load and list the pull requests waiting right now.
