The Pull Request Is Already Too Late

Cristian Bogdan — Mon, 15 Jun 2026 20:56:56 +0000

For years, the pull request has been one of the most important quality control mechanisms in software development. A developer writes code, submits a pull request, and another developer reviews the changes before they're merged. Simple, widely understood, and a standard part of modern engineering.

The problem is that the pull request was designed for a world where humans wrote most of the code. That world is changing.

Today, developers can ask AI assistants to generate hundreds of lines of code in minutes. Entire APIs, authentication flows, database models, infrastructure definitions, and deployment pipelines can be created faster than many teams can review them. AI has fundamentally changed the economics of software development. What hasn't changed is how most organisations verify the output. As a result, many teams are trying to solve a 2026 problem with a 2016 process.

The Traditional Review Model

For the last decade, the software development lifecycle has looked something like this: a developer writes code, commits it, opens a pull request, reviewers inspect the changes, issues get identified, code gets corrected, and changes get merged.

The pull request acts as a gate. It's where design issues, bugs, security concerns, and coding standard violations get caught before reaching production.

This model works reasonably well when developers write code manually. A human writes it, another human reviews it, the volume stays manageable, and the assumptions hold. Unfortunately, AI changes those assumptions.

The AI Multiplier Effect

Modern AI coding assistants are remarkably capable. They can generate API endpoints, authentication logic, database queries, infrastructure as code, front-end components, test suites, and deployment scripts.

This isn't inherently a problem - the productivity gains can be substantial. The challenge emerges when generation outpaces verification.

A developer who previously produced a hundred lines of code may now generate a thousand. A team that previously reviewed five hundred lines per day may suddenly need to review five thousand. Reviewers aren't becoming ten times faster. Security teams aren't becoming ten times larger. Yet the volume of code keeps increasing.

The result is predictable: more code, less scrutiny per line, more reliance on assumptions and trust, and ultimately more opportunities for defects to slip through unnoticed.

Security Doesn't Scale Linearly

Many organisations assume that if they simply continue reviewing pull requests, they'll maintain the same level of security assurance. That assumption deserves scrutiny.

Security review isn't a linear process. Reviewing ten lines of code isn't ten times easier than reviewing a hundred. Reviewing a hundred lines isn't ten times easier than reviewing a thousand. As change sets grow, the probability of overlooking something important increases dramatically.

Reviewers get fatigued. Context gets fragmented. Complex interactions become difficult to reason about. The challenge isn't merely finding vulnerabilities - it's maintaining confidence that the review itself was effective. The larger the change set, the harder that confidence is to justify.

AI Doesn't Understand Risk

This is perhaps the most important observation. AI models generate code based on patterns. They don't understand organisational risk, regulatory requirements, your threat model, or the business consequences of a mistake.

An AI assistant may generate a database query that works perfectly - and one vulnerable to injection attacks. It may create an authentication flow that accidentally omits an important authorisation check. It may suggest a configuration that functions correctly while simultaneously exposing sensitive resources.

The code can look professional. It can compile successfully. It can pass functional tests. And it can still introduce risk. Not because the model is defective, but because it's optimising for generation, not accountability.

The Review Bottleneck

Most organisations already struggle to perform thorough reviews. Engineering teams are under pressure to deliver features, product teams to meet deadlines, and security teams to reduce risk.

Adding AI into the process accelerates development but doesn't automatically accelerate governance. In many cases, the opposite happens: developers generate more code, reviewers receive larger pull requests, and security teams receive more findings. The bottleneck simply moves downstream.

What was once a manageable review process becomes an inspection process overloaded with volume. The organisation appears faster - in reality, it may simply be accumulating technical and security debt more quickly.

Shift Left Is No Longer Enough

For years, the industry has promoted "shift left": move testing earlier, move security earlier, move quality assurance earlier. The principle remains sound. But AI-assisted development raises an uncomfortable question - how far left is left enough?

If vulnerabilities are introduced at the moment code is generated, waiting until a pull request may already be too late. The issue has already entered the repository. The developer has already invested time in the implementation. The reviewer must now identify the problem retrospectively, and the organisation pays the cost of detection after creation.

A more effective model may be to verify code while it's being written - before it reaches source control, before it reaches a pull request, before it becomes somebody else's problem.

Verification Is Becoming More Important Than Generation

The tech industry is understandably fascinated by generation. Every week brings a new model, a new coding assistant, a new autonomous development workflow. The conversation is dominated by how quickly software can be created. Far less attention goes to how software should be verified.

This imbalance is becoming increasingly visible. Generation capability is advancing rapidly; verification capability is struggling to keep pace. Yet verification is ultimately what determines whether software can be trusted. Anyone can generate code - the real challenge is determining whether the generated code should exist in the first place.

A New Development Reality

The future of software development is unlikely to involve less AI. It will almost certainly involve more. Developers will generate more code, agents will perform more tasks, and automation will become more sophisticated.

The organisations that succeed won't necessarily be the ones that generate software fastest. They'll be the ones that build effective mechanisms for verification, governance, and accountability.

The pull request isn't disappearing - it remains valuable. But it's increasingly becoming the final checkpoint rather than the primary one. The software industry is entering an era where generation is abundant and verification is scarce. In that environment, verification may become the most important engineering discipline of all.

DEV Community: Cristian Bogdan