When Commits Scale Faster Than Reviews

There is an optimistic reading of the current phase of software development, and part of it is true: more people coding, more repositories, more pull requests, more code reaching production.

GitHub Octoverse 2025 points in exactly that direction. GitHub reported more than 180 million developers, 630 million repositories, 121 million new repositories in 2025, more pull requests, more code pushes, and clear signals that AI tools have entered the normal development workflow.

The data point I care about is less shiny: while created pull requests grew 20.4% and code pushes reached more than 986 million commits in the year, comments on issues and PRs were almost flat, up 0.35%. Comments on commits were down 27%.

Octoverse itself frames this as an observational signal, not a causal claim. That is the right way to read it. Still, the tension is hard to ignore: code production is accelerating, but the visible signals of discussion around that code did not accelerate at the same pace.

In June 2026, this reading became less dependent on an annual report. The study “Agentic Very Much! Adoption of Coding Agent in New GitHub Projects” looked at new projects created after an earlier analysis and found coding-agent adoption more than twice as high, with more intensive AI-assisted commit activity. The sample and methodology are different from Octoverse, but the direction is the same: the ability to produce diffs is growing quickly.

That is the problem. Not “AI writes bad code”. Not “developers got lazy”. The problem is simpler and more annoying: review is finite capacity.

Review did not get cheaper

Generating code got cheaper. That does not mean understanding code got cheaper.

An agent can open a PR in minutes. A developer can ask for a large refactor before lunch. A team can move from two changes a week to ten changes a day. But review still requires the same things it always did: reconstructing context, understanding intent, comparing alternatives, spotting risk, checking tests, noticing side effects, and deciding whether the change should enter the system.

The expensive part of review was never reading characters. It was forming judgment.

That cost does not disappear when the diff is generated by AI. In some cases, it increases. Generated code can be locally correct and product-level weird. It can pass the existing tests and reinforce a bad abstraction. It can fix the bug and duplicate the logic in three places. It can look consistent because it copied the repository style, while still misunderstanding half of the business rule.

When the cost of production drops and the cost of verification stays high, the queue moves. The bottleneck leaves implementation and enters review.

The first system to break is the informal one

Many teams run review on implicit rules:

• “Send small PRs.”
• “Ask someone who knows the area.”
• “If CI passed, it is probably close.”
• “If nobody commented, it is fine to merge.”

That worked better when change volume was limited by human implementation time. Manual writing created some natural pacing. Not because it was morally better, but because it had friction.

With assisted generation, that brake weakens. The author can produce more diffs than they can clearly explain. The reviewer receives more PRs than they can keep in their head. And the team starts confusing silence with approval.

Silence in review is not approval. Often, it is saturation.

Small PRs are not aesthetics, they are damage control

The request for smaller PRs is often treated as personal preference. It is not.

A small PR reduces the space of uncertainty. It makes clearer what changed, why it changed, and where the risk sits. It also limits the damage when something slips. A wrong 80-line PR is usually reversible. A 3,000-line PR that mixes refactoring, dependency updates, tests, formatting, and business behavior becomes archaeology before it is even merged.

For AI-generated or AI-assisted code, I would be stricter:

• behavior changes separated from formatting;
• dependency updates separated from refactoring;
• generated code separated from hand-written code;
• mechanical files, such as snapshots or generated clients, in their own commits;
• PR descriptions explaining intent, not just listing files.

This is not bureaucracy. It is reducing how many things the reviewer needs to hold in their head at the same time.

Labeling generated code is not an accusation

Teams that use AI maturely should treat “generated by AI” as operational metadata.

Not to shame the author. Not to create a lower class of code. The author remains responsible for the diff. The tool does not morally sign the commit, join the on-call rotation, or receive the pager.

The label exists to adjust the review mode.

If a change came from a broad prompt, I want to know. If the agent touched many files to solve a small problem, I want to know. If the human edited manually afterward, even better, say where they focused. That helps the reviewer look for the right failure modes: misunderstood requirements, excessive generalization, subtle duplication, tests that validate the implementation instead of the behavior.

Transparency saves time here. Pretending every diff came from the same process only adds noise.

Review needs a budget

If PR volume increases, but the number of reviewers and available time do not, someone is paying the bill. Usually, it is review quality.

A review budget can be simple:

• limit simultaneous PRs per author;
• recommend limits for files or lines per PR;
• protect calendar time for review;
• define an explicit policy for large PRs, such as design review before or pair review during implementation;
• rotate reviewers to avoid overloading the same people;
• make ownership clear for critical areas of the codebase.

The point is not to turn review into a bureaucratic queue. It is to admit that attention is a resource. If the team plans development capacity but not review capacity, it is planning half of the system.

CI is a gatekeeper, not a reviewer

CI helps a lot. Typecheck, tests, lint, static analysis, SAST, coverage checks, and contract validation reduce repetitive human work. The more code is generated, the more important these gates become.

But CI does not know whether the change should exist. It does not know whether the flow became harder to understand, whether a name hides a business rule, or whether the new coupling will cost too much two months from now. It validates known properties. Human review handles judgment.

The mistake is using green CI as a substitute for understanding.

The best use of automation in review is removing mechanical work from humans. Formatting, style, missing tests, broken APIs, incompatible contracts, obvious vulnerabilities. That frees the reviewer to ask better questions:

• does the change solve the right problem?
• is the scope honest?
• is the behavior testable?
• does the abstraction help, or does it only spread complexity?
• who will maintain this when the author is not around?

Measure review load, not only throughput

Teams like measuring how many PRs were merged. It is convenient, but incomplete.

If you want to know whether the review system is healthy, track signals closer to the real load:

• open PRs per active reviewer;
• median PR size;
• time to first review;
• number of re-review cycles;
• PRs merged without a human comment;
• review distribution per person;
• age of PRs waiting for approval;
• changes reverted or fixed shortly after merge.

No single metric tells the whole story. But one pattern should raise concern: PR volume rising, diff size rising, comments flat or falling, and a small group of people carrying most reviews.

That does not prove quality dropped. It proves the system is working near its limit.

Use AI to prepare review, not to pretend review happened

AI can help a lot with review. I like using tools to summarize diffs, point out higher-risk files, suggest test cases, compare behavior before and after, or look for simple inconsistencies.

But there is a large difference between using AI to prepare the review and using AI as an alibi for not reviewing.

An automatic “looks good” comment does not increase confidence. A summary that highlights the PR touches authentication, cache, and data migration helps a lot. A suggested test for an edge case is useful. A bot that approves changes without product context only pushes the problem into production.

Good automation shortens the path to human judgment. Bad automation simulates human judgment.

The honest question

When commits scale faster than reviews, the question is not “how do we merge everything faster?”.

The question is: “what volume of change can we actually understand?”.

That answer can be uncomfortable. Maybe the team needs to limit simultaneous PRs. Maybe it needs to break work down with more discipline. Maybe it needs to reject generated diffs that arrive too large. Maybe it needs to invest more in contract tests, ownership, and observability. Maybe it needs to say that productivity without review capacity is just stored risk.

AI can greatly increase the ability to write software. Good. But if the organization does not also increase its ability to review, explain, and maintain, it did not gain speed. It only moved invisible work into the future.

References

• GitHub Octoverse 2025: A new developer joins GitHub every second as AI leads TypeScript to #1
• Agentic Very Much! Adoption of Coding Agent in New GitHub Projects
• Agentic Much? Adoption of Coding Agents on GitHub