Ten-line pull requests get twenty comments. Two-thousand-line pull requests get "LGTM" in four minutes. Learn what engineering leaders on Reddit say about rubber-stamp code reviews in large organizations, why the problem stays invisible, and how Keypup MCP uses pull request size, review timestamps, approvals and comments to measure it repository by repository.
TL;DR: In most enterprise codebases, review attention doesn't grow with pull request size. Small pull requests get long discussions, while pull requests with thousands of changed lines get approved in minutes, often without a single comment. A minority of oversized pull requests carry most of the code that ships, so most of the risk goes through the least-reviewed path. This is the LGTM problem. The Keypup MCP Server reads every pull request's lines added and deleted, its review request, first review and approval timestamps, its approval count, its comments and who merged it. Your AI assistant can then size the problem, show how review attention falls as size grows, spot approvals that arrive too fast to be real reviews, follow the trend and point to the repositories where a size limit will help most.
Every engineer knows the joke: ask for a review of 10 lines and you get 10 comments, ask for a review of 500 lines and you get "looks good to me". In a startup, it's a joke. In an enterprise with hundreds of repositories, change approval policies and auditors who read "approved by a second engineer" as a control, it's a risk nobody measures.
The LGTM problem is when a pull request is approved without being meaningfully reviewed, and it happens most often to the pull requests that need review the most: the big ones. It's not caused by lazy reviewers. It's caused by a process that asks people to do something they can't do well — hold 2,000 lines of change in their head between two meetings.
It stays invisible for structural reasons:
The result: the review step that compliance, security and quality all rely on is strongest on trivial changes and weakest on the risky ones.
Code review is one of the few checks that catch design flaws, missing edge cases and security issues before they ship. When a 2,000-line change is approved without discussion, that check didn't run — but the dashboard says it did.
SOC 2, ISO 27001 and internal change management policies often rely on "every change is reviewed and approved by someone other than the author". An approval that arrives in under a minute, or a large change merged by its own author, satisfies the letter of that control and none of its intent.
Review is how teams share context. Oversized pull requests approved in silence mean nobody but the author knows what changed, which deepens key-person risk and makes the next incident harder to debug.
Pull request size and review quality come up again and again wherever staff engineers, engineering managers and platform leads at large organizations compare notes. The quotes below are representative of recurring threads on r/ExperiencedDevs, r/programming, r/softwareengineering and r/devops.
"Somebody opened a 4,000-line pull request on Thursday afternoon and had two approvals by Friday morning. Zero comments. That code moves money. Our audit report says every change is peer reviewed."
"Small pull requests get bikeshedded to death, so people learned to batch everything into one giant pull request that nobody has the energy to argue with. We accidentally trained the team to avoid review."
"I can't honestly review more than a few hundred lines at a time. When I get 1,500, I check the tests pass, skim the file names and approve. Everyone does. We just don't say it."
The pattern holds: everyone knows big pull requests get rubber-stamped, but nobody can show how many there are, how little review they get, whether it's getting worse or which teams are most exposed — because that evidence is spread across the sizes, timestamps, approvals and comments of tens of thousands of pull requests.
The Keypup Model Context Protocol (MCP) Server gives your AI assistant structured access to the pull requests, reviews and comments Keypup imports from GitHub, GitLab, Bitbucket and Azure DevOps, alongside your Jira issues. For every pull request, that includes its lines added, deleted and changed, its creation, review request, first review, approval and merge timestamps, its approval count, its comments with their authors and dates, its reviews with their state, and who merged it. That's everything needed to see whether review effort follows risk.
The first question is how much code goes through oversized pull requests, and how much of it is approved in silence.
MCP Prompt:
For pull requests merged in the last 6 months: how many are there, what is the median number of lines changed, what share have 1,000 or more lines changed, what share of all lines changed do they represent, and how many of them were approved without any comment?
Output: Pull Request Size and Review Health — All Repositories
Key Insight: One pull request in six carries almost three quarters of all the code that changed, and almost half of those oversized pull requests were approved and merged without a single comment. Most review effort goes to small changes while most of the risk ships through the large ones.
If reviewers were keeping up, comments would grow with size. They don't.
MCP Prompt:
For pull requests merged in the last 6 months, grouped by lines changed (under 100, 100–399, 400–999, 1,000 or more), show the average number of comments per pull request as bars and the number of comments per 100 lines changed as a line.
Output: Review Attention by Pull Request Size
Key Insight: A 1,000-line pull request gets fewer comments than a 400-line one. Attention per line falls 50-fold from the smallest bucket to the largest: 10.8 comments per 100 lines for small changes, 0.2 for oversized ones. Past a few hundred lines, reviewers stop reviewing and start skimming.
Comment counts can miss silent but careful reviews. Approval speed is a second, independent signal.
MCP Prompt:
For approved pull requests merged in the last 6 months, by size bucket, show the share approved less than 10 minutes, 10–60 minutes, 1–4 hours and more than 4 hours after the review was requested, as a 100% stacked bar chart.
Output: How Fast Do Approvals Arrive?
Key Insight: The bigger the pull request, the faster it gets approved. 38% of approvals on pull requests with 1,000 or more lines arrive less than 10 minutes after the review request — over 100 lines a minute. That isn't a review; it's a signature.
Averages hide the teams where the problem concentrates. A bubble chart puts every repository on the same map.
MCP Prompt:
For the 12 repositories with the most merged pull requests in the last 6 months, plot the median lines changed per pull request against the share of pull requests with 1,000 or more lines that were approved without any comment, with bubble size showing merged pull requests.
Output: Repositories — Median Size vs Silent Approval Rate
Key Insight: The two problems travel together. Repositories with larger typical pull requests also approve more of their oversized ones without discussion. Four repositories sit in the top-right corner with 61% to 72% silent approvals, while teams that keep pull requests small also discuss their rare large ones.
Pull request size drifts slowly, so nobody notices until it's normal.
MCP Prompt:
By month of merge over the last 12 months, plot the median lines changed per merged pull request and the share of merged pull requests with 1,000 or more lines changed, as two lines.
Output: Pull Request Size Over 12 Months
Key Insight: Pull requests are getting bigger every quarter. The median merged pull request grew from 132 to 214 lines in a year (+62%), and the share of oversized pull requests went from 11% to 19%. Review habits didn't change to match. If your teams adopted AI coding assistants over the same period, this is the chart to watch.
Fixing the LGTM problem works best repository by repository, starting where the risk is highest.
MCP Prompt:
For the six repositories with the highest share of pull requests with 1,000 or more lines approved without any comment, over the last 6 months, show merged pull requests, median lines changed, the share with 1,000 or more lines, that silent approval share, the median business hours from review request to first review on those large pull requests, and the share of them merged by their own author.
Output: Review Risk by Repository
| Repository | Merged PRs | Median Lines | 1,000+ Lines | 1,000+ Approved, No Comment | Median Hours to First Review (1,000+) | 1,000+ Merged by Author |
|---|---|---|---|---|---|---|
| data-pipeline | 840 | 520 | 31% | 72% | 0.6 h | 58% |
| ledger-service | 760 | 400 | 27% | 67% | 0.8 h | 41% |
| infra-terraform | 980 | 490 | 29% | 64% | 0.5 h | 63% |
| checkout-web | 1,180 | 310 | 22% | 61% | 1.1 h | 22% |
| payments-api | 1,420 | 240 | 18% | 58% | 1.4 h | 17% |
| mobile-app | 1,650 | 380 | 24% | 49% | 2.3 h | 12% |
Key Insight: In three repositories, oversized pull requests get their first review in under an hour and around two thirds are approved without comment. In infra-terraform, 63% are also merged by their own author. That's where a size limit and a second required reviewer will pay off first.
Every number above comes from data Keypup already imports from your Git platform. It helps to be precise about what that data is — and what it isn't.
Keypup imports each pull request's additions, deletions and lines changed (the sum of both). Size buckets are computed from lines changed. These counts include every file in the diff — lock files, generated code, snapshots and vendored dependencies — so a repository that commits generated files will look bigger than it is. Keypup doesn't import the list of files in a pull request, so you can't exclude them by path; if this matters, use a label (for example generated) on those pull requests and filter it out in your prompts.
For every pull request, Keypup stores when the review was first requested, when the first review was submitted, when it was first approved and when it was merged. "Approval speed" is the time from review request to first approval; "time to first review" can be measured in calendar or business hours. Pull requests where nobody formally requested a review have no request timestamp and are left out of these speed measures.
Keypup imports every comment on a pull request with its author and date, along with every submitted review and its state (Approved, Changes Requested, Commented). "Approved without any comment" means the pull request has an approval and no comments. It's a strong signal, not proof: a reviewer can read carefully and approve without writing anything, and a discussion held on a call leaves no trace. That's why the approval speed chart is useful alongside it.
Keypup imports each pull request's approval count, the number of approvals required by your branch protection, review state, author and who merged it. "Merged by its own author" compares the merger with the author, which is normal in many workflows once approvals are in place — it only becomes a risk signal combined with silent or very fast approvals.
Before Keypup MCP:
After Keypup MCP:
"We were reporting 100% peer review to our auditors and believed it. The approval speed chart showed that a third of our biggest changes were approved faster than anyone could read them. Now we report how many changes were actually reviewed, not just approved."
Before Keypup MCP:
After Keypup MCP:
"Everyone agreed small pull requests were better, and everyone kept opening big ones. Seeing the comments fall off a cliff above 400 lines did what years of guidelines couldn't. Our median is down by a third and reviews actually say something again."
Connect GitHub, GitLab, Bitbucket or Azure DevOps to Keypup. Pull request sizes, review requests, reviews, approvals, comments and merge data are imported automatically. You can also add Jira: pull requests are linked to issues when they reference the Jira issue key.
Pick thresholds that fit your teams — for example under 100, 100–399, 400–999 and 1,000 or more lines changed — and use them consistently in your prompts so trends stay comparable.
Ask teams to label pull requests that are mostly generated code, dependency updates or migrations. Excluding that label in your prompts keeps legitimate large changes from inflating the numbers.
Follow the MCP documentation to connect Keypup to Claude, ChatGPT, Cursor or any MCP-compatible assistant.
Run the KPI, comments-by-size and approval speed prompts to set a baseline. Use the repository triage table to pick where to start: a size guideline, a second required reviewer for large pull requests, or a rule against self-merging oversized changes. Re-run the prompts every month to check the trend is reversing.
A rubber-stamp review is an approval given without meaningfully reading or discussing the change. It satisfies a process requirement — "one approval needed" — without providing the quality, security or knowledge-sharing benefits that code review is meant to deliver.
There's no universal limit, but most teams find review quality drops sharply above 200 to 400 lines changed. Measure your own curve: plot comments per 100 lines by size bucket and set your guideline where the line flattens.
Look for oversized pull requests approved without any comment, and for approvals that arrive within minutes of the review request. Neither signal is proof on its own, but together, and concentrated in the same repositories, they show where review has become a formality. Keypup MCP computes both from pull request, review and comment data.
Yes. Reviewers can only hold so much change in their head at once. As pull requests grow, comments per line fall and approvals often get faster, which means each line gets less scrutiny precisely where the risk is highest.
An approval isn't a review. Keypup MCP shows how much of your code is actually being reviewed and where it isn't:
✅ Sizing the problem — how much code ships through oversized pull requests ✅ Showing that attention doesn't scale — comments per line by size ✅ Spotting approvals too fast to be reviews — time from request to approval ✅ Finding where oversized pull requests slip through — repository by repository ✅ Following the trend before larger pull requests become the norm ✅ Planning action per repository, starting where silent approvals concentrate
Join teams already using AI to make data-driven decisions faster than ever.
Compare the 5 best value stream analytics platforms for engineering leaders — Keypup, Pluralsight Flow, LinearB, Jellyfish and Swarmia — across DORA Metrics depth, cross-platform data unification, contextual analysis, customization, AI and natural language capabilities, and setup speed. Find out which value stream management platform turns Git, Jira and CI/CD data into prescriptive, actionable insights.
Enterprise Jira backlogs grow every month until nobody trusts them: thousands of zombie tickets, year-old "High" priorities and grooming sessions that change nothing. Learn what engineering leaders on Reddit say about backlog bankruptcy, why the problem stays invisible, and how Keypup MCP uses issue age, workflow history, priority, resolution and linked pull requests to measure it and plan a reset.
Story points are supposed to make delivery predictable, yet an 8-point issue rarely takes much longer than a 3-pointer and points inflate quarter after quarter. Learn what engineering leaders on Reddit say about story points, why the estimation gap stays invisible in enterprise reporting, and how Keypup MCP compares Jira story points with workflow history, sprints and linked pull requests to measure it.