AI can generate pull requests faster than humans can review them. The result is not free velocity—it is PR fatigue, delayed scrutiny, and growing security risk.

Hey there,

AI has made it almost effortless to create a plausible pull request. It hasn't made architectural judgment, security and privacy review, or maintainer attention any cheaper. When output scales faster than verification, the bottleneck moves downstream—and the people guarding the merge queue absorb the cost.

PR fatigue occurs when generation scales faster than verification. I’ve heard anecdotally from friends in the industry that PR fatigue is a real problem that existed before AI, but AI is contributing to the challenges. I define PR fatigue as the state a developer reaches when an overwhelming number of PRs require review, leading to judgment errors not out of malice, but from looking at the same thing too many times.

We’re moving to a new concept in software delivery. We’re shifting a developer’s time away from brainstorming, designing code, implementing, and, hopefully, testing and security review. The new paradigm is to iterate with AI and then create a PR. The challenge falls on those who have to review another developer’s PR that was “influenced” or created entirely by an AI coding agent.

The diff isn’t the problem, and it never was. The challenge is that, as a reviewer, you have to sniff out the code's intent and system context, evaluate security constraints (against the threat model), and decide whether to merge the code.

The onus of work is on the reviewer. With AI, you can turn and burn a fix right back into the PR in minutes, and then the reviewer has to start the process over. They have to walk back through the context, determine whether their issues are resolved, and sniff out any new issues the fix may have introduced.

Linux networking gives us our first set of real data to consider. In the first reference below, Jakub Kicinski describes how Linux networking maintainers are measuring the cost of AI-assisted patching and review via a Linux kernel mailing list post.

In the primary Linux 7.3 networking pull request, Jakub reported 632 net patches and 648 net next patches. He estimated that one-third to one-half of the latter were AI-driven low-priority fixes, cleanups, and clarifications, and then wrote that the team was “completely overwhelmed.”

The important signal is not that every AI-assisted patch was bad. It is that cheap generation changed the volume and priority mix faster than the maintainer capacity could adapt to.

Linux is the loudest example, not the only one. The wave of AI-generated PRs is slowing things down and costing extra review work. A study of 22,953 AI-assisted pull requests found that lower-experience contributors submitted 2.15 times as many commits and changed 1.47 times as many files. Their PRs received 4.52 times as many review comments, were accepted 31% less often, and stayed open 5.16 times longer.

The data don’t lie, and we now have more contributors with less experience. AI is enabling folks with less knowledge and experience to code, and they’re generating PRs that are more complex and take more time to review. The fixes required for these PRs are taking longer and requiring more cycles to complete. The Enterprise is not immune to this new paradigm, as we bring on new entry-level developers. They feel empowered by the AI, but the data shows this feeling of empowerment is a false sense of security.

All that we’ve discussed thus far lands here — with the AppSec problem. If reviewers are under pressure from the PR queue, they may skim, defer, or rubber-stamp PRs that cross their virtual desks. If a PR is for a security- or privacy-relevant change, this is exactly the time when we don’t want something skimmed. Attention to detail matters most here.

A green CI result for a PR can prove that known checks passed; it cannot prove that the change matches the intended architecture, preserves trust boundaries via the threat model, or avoids introducing an insecure code snippet, a vulnerability, or an insecure design pattern.

An AI reviewer could help, but it has to be structured so as not to be a token furnace (credit to Ron Perris of Manicode, by way of Jim Manico in an upcoming Application Security Podcast episode), looping back and forth and burning hundreds or thousands of dollars in tokens trying to resolve a problem.

Fixing this isn’t impossible—it just takes deliberate process design. Most Enterprise processes are structured and rigid to some extent, but some items on this list could be improved.

Delivery capacity is not how much code a team can generate. It is how much change the team can responsibly understand, verify, and own. The fastest safe team refuses to generate work faster than it can review it, no matter what model they use.

If AI doubles your pull-request output but your experienced review capacity stays flat, did engineering get faster—or did the risk queue just get longer?

AI Pen Testing Killed Traditional DAST

James Berthoty explains how contextual payloads and application-aware testing are reshaping DAST—and why autonomy, token costs, and production safety still matter.

Is Spec-Driven Development Already Dead?
We debate whether detailed specifications and disposable, AI-generated code can deliver precision—or simply recreate the old problem of implementations failing to follow the spec.

What did I miss this week? Hit reply and tell me.

— Chris