37 PRs in two weeks with Claude Code, still not merged two months later (Claude Codeで2週間にPRを37本作ったら、2ヶ月経ってもマージが終わらなかった話)
A · Strong evidence Devlog (Sapporo) engineer's case study built from GitHub records of 63 pull requests, with weekly creation and merge counts, review-wait medians and a coded breakdown of review comments; a single project, but the method is shown and the numbers are internally consistent.
Summary based on the full text·Original: about 8 minutes to read
In short
A Zenn post (5 November 2026) by an engineer at Devlog, a small Sapporo company, on a client project where Claude Code wrote almost all the code. Creation peaked at 37 pull requests in two weeks, but one client-side reviewer could merge about eight a week, and only for three weeks. Two months in, 10 PRs were still waiting. The author concludes that review capacity, not implementation speed, set the project length, and now estimates schedules from changed lines divided by review throughput.
Key numbers
- 37pull requests created with Claude Code in the two weeks from 13 July, against 10 merged in the same period
- 11 daysmedian wait from PR creation to first review
- 13 daysmedian time to merge for both PRs under 500 lines and PRs of 500-1,000 lines
- 34 of 118human review comments about unclear PR explanations (about 30%); 389 comments in total including 271 from Copilot
- ~3,400 linesaverage merged lines per week over 8 weeks, now used as the estimate divisor
As reported by the source.
Japanese·Web page·opens zenn.dev
What it reports
- About 8 weeks (July to August), a tool syncing data with an external service; 63 PRs: 38 merged, 15 closed unmerged, 10 still awaiting review. About 25,000 merged lines including tests, excluding about 3,300 moved lines.
- One reviewer, an engineer on the client side.
- Weekly merges peaked at 8 PRs (4,400 to 6,500 lines) for the three weeks from 20 July, then fell to about 2,000 lines a week. The 8-week average was about 3,400 lines a week.
- Median 11 days from creation to first review. Splitting PRs did not help: median 13 days to merge for both size bands, because most time was queueing.
- 389 comments on the 38 merged PRs: 118 human, 271 GitHub Copilot. Of the human ones, 34 were business-logic bugs only a domain expert would see, 34 unclear explanations or comments ("AI-written text is hard to read", unknown internal abbreviations), 20 duplication or rework across PRs.
- New estimate: review weeks = changed lines (with tests) / 3,400, and / 2,000 from week four. Applied to 25,000 lines it gives about 7.4 weeks against about 8 actual. The author also caps the review queue at about 5 PRs.
- Afterwards the author moved human review to requirements and design, with tests and AI review on code, and keeps mandatory human review for risky changes, citing Anthropic's Claude Code team, GitHub Docs, two arXiv papers and NIST SP 800-218A.
How they got it
PR creation and merge dates, changed lines and review history were pulled from GitHub and tabulated by week. Human comments were categorised by the author.
Limits
- One project with one reviewer; the reviewer's other workload was not accounted for.
- Comment categorisation was done by the author, with no second coder.
- The client repository is private, so the numbers cannot be checked externally.
Why it matters for companies
When agents produce code faster than people can review it, the queue grows and schedules estimated from coding time slip. The numbers here give a simple planning unit: review throughput per reviewer, which falls after a few weeks of heavy load. Smaller PRs do not help if total review volume is unchanged. Two fixes are within the author's control: clearer PR descriptions, and choosing where humans read (requirements, design and risky changes) instead of every line.
Key passages in translation
Japanese original
PRを63本集計してわかったのは、開発期間を決めていたのが実装の速さではなく、人がレビューできる量だったということです。
What tallying 63 PRs showed is that the development period was set not by the speed of implementation but by the amount people could review.
Japanese original
実際には、500行未満のPRも500〜1,000行のPRも、マージまでの日数は中央値で同じ13日でした。
In practice, PRs under 500 lines and PRs of 500 to 1,000 lines had the same median of 13 days to merge.
Japanese original
週3,400行という上限は、人の側の限界です。AIがいくら速く書いても、この上限は上がりません。
The ceiling of 3,400 lines a week is a limit on the human side. However fast AI writes, this ceiling does not rise.
Summary based on the full text. Read the original for the full argument and data.Read the original on zenn.dev
- Tags
- Future of work