Stop sending me huge PRs; a rant
Large, AI-generated pull requests are overwhelming human code reviewers and exposing limits in current development workflows. Commenters debate whether to enforce strict PR size limits, rely more heavily on automated and AI-assisted review, or rethink feature planning so changes are introduced in smaller, narrative chunks that are easier to understand and test. Underneath the tooling talk is a deeper concern about accountability, software quality, and how much responsibility can safely be delegated to large language models.
AI-generated large PRs & review bottleneck
- Many maintainers report fatigue from 1,000–4,000 line PRs “one‑shotted” by agents; human review becomes the bottleneck.
- Some say if a PR is too big for humans to review, teams may be tempted to drop approvals and rely solely on CI, which others consider dangerous.
- There is worry that if no one can fully review the code, no one truly understands the system anymore, weakening a company’s “moat.”
Limits, tooling, and workflow strategies
- Proposed mitigations: CI checks or git hooks that reject PRs over N lines with a polite message; others argue this just fragments incomprehensible work.
- GitHub’s stacked PRs, “chaptered” PR review tools, and browser extensions are cited as ways to make large changes more digestible.
- Some describe custom “skills” or workflows that enforce atomic commits or split branches; others find LLMs stubbornly bad at good git hygiene without heavy prompting.
Small vs large PR philosophy
- One camp insists on small, narrative PRs: introduce foundations, then glue, then feature; big dumps or multiple big PRs at once are rejected.
- Another camp argues some features “can’t be half‑pregnant”; splitting is extra, pointless work, especially when everything must ship together.
- Counterpoint: most large features can be staged using feature flags or preparatory refactors; “if there’s a will, there’s a way.”
Role of tests and code quality
- Several commenters stress that LLM‑written tests can be vacuous or encode incorrect behavior as the spec; tests should often be written or at least reviewed carefully by humans.
- Clean commit history and small, focused changes are framed as core to good review, not optional polish.
Humans vs AI in review and accountability
- Some advocate AI reviews as the only scalable path; critics ask who audits the AI and warn “slop begets slop.”
- A contrasting view: reduce or remove human reviewers and increase personal accountability for the “prompter.”
- Others maintain that genuine human review is critical, especially in regulated or safety‑critical contexts.
Organizational and OSS dynamics
- In OSS, maintainers can simply close giant/AI PRs and often consider blocking anonymous AI contributions entirely.
- In companies, compliance, deadlines, leadership attitudes, and reviewer–author power dynamics make “just say no” much harder.