---
id: "lib-2026-11-05-37-prs-in-two-weeks-with-claude-code-still-not"
type: "library"
title: "37 PRs in two weeks with Claude Code, still not merged two months later (Claude Codeで2週間にPRを37本作ったら、2ヶ月経ってもマージが終わらなかった話)"
lang: "JA"
org: "devlog (Zenn)"
source_type: "Practitioner post"
date: "2026-11-05"
week: "2026-W45"
url: "https://nosov.ai/library/lib-2026-11-05-37-prs-in-two-weeks-with-claude-code-still-not/"
original_url: "https://zenn.dev/devlog/articles/8ff85c172b50ef"
tier: "A"
tier_name: "Strong evidence"
tier_reason: "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_basis: "full-text"
original_minutes: "8"
tags: ["ai technology", "future of work", "code review capacity", "delivery estimation"]
frames: ["verification-capacity"]
---

# 37 PRs in two weeks with Claude Code, still not merged two months later (Claude Codeで2週間にPRを37本作ったら、2ヶ月経ってもマージが終わらなかった話)

Tier 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.

## 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

- 37: pull requests created with Claude Code in the two weeks from 13 July, against 10 merged in the same period
- 11 days: median wait from PR creation to first review
- 13 days: median time to merge for both PRs under 500 lines and PRs of 500-1,000 lines
- 34 of 118: human review comments about unclear PR explanations (about 30%); 389 comments in total including 271 from Copilot
- ~3,400 lines: average merged lines per week over 8 weeks, now used as the estimate divisor

## 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

> 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.

> 実際には、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.

> 週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.

Original: https://zenn.dev/devlog/articles/8ff85c172b50ef