The Death of the PR

You've got 50 open PRs. Comments flying. Reviewers saying LGTM. The process is humming.

You feel productive. The product isn't moving.

I've been shipping software infrastructure for 15 years. Startups, Fortune 500s, my own company. And I'm going to tell you something that sounds wrong until you think about it: pull requests review the one thing that matters least.

You're Tasting the Recipe, Not the Dish

A PR answers one question: does this code look safe to deploy?

But looking at code doesn't tell you if it works. It tells you if it looks like it works. A senior engineer reviewing a diff is pattern-matching against their experience — reading a recipe and guessing whether the dish will taste good.

Meanwhile, the deploy goes out. Nobody checks if latency spiked. Nobody checks if conversion dropped. Nobody checks if the feature actually solved the problem it was supposed to solve.

We built an entire industry ritual around inspecting ingredients. Nobody ever tasted the food.

How We Got Here

Software has always had a feedback problem. How do you know what you shipped actually works? The answer has evolved in three eras. Most companies are stuck in the first one.

Era 1: Human → Human. Developer writes code. Another developer reads it. Manual QA. "It works on my machine." Feedback cycle measured in days to weeks. You can catch a typo. You cannot catch a race condition that only shows up under load. One of my clients ships through three review gates. Average time from PR to production: 11 days. Their competitor ships daily.

Era 2: Human → Agent. This is where most teams are right now. Agents — AI coding tools, CI pipelines, automated tests — are entering the loop. But there's still a bottleneck: the human who has to read the diff and approve. In my own setup, our agent writes code, runs E2E tests, deploys to a dev environment, and monitors PostHog for user impact. By the time I look at the "PR," the agent has already validated more than I ever would by reading a diff. My review is a formality. I'm the rubber stamp at the end of a process that already verified itself. That should make you uncomfortable.

Era 3: Agent → Agent. Agent deploys. Agent monitors latency, errors, conversion, business KPIs. Metrics degrade? Agent rolls back or proposes a fix. Feedback cycle measured in minutes. The human moves from reviewer to policy setter. You don't read every diff. You define what "healthy" looks like — latency under 200ms, error rate below 0.1%, users still converting — and the system verifies against those definitions continuously. The PR was a proxy for trust. If you can verify the outcome directly, reviewing the code is theater.

The Part Everyone Gets Backwards

We've spent decades arguing about how to review code. Pair programming vs. async. Required approvals vs. optional. Nobody stopped to ask: should we be reviewing the code at all?

Think about what happens before the PR. Someone writes a requirement — a Jira ticket, a Slack message, a one-pager. That's the intent. The reason the code exists. Then a developer (or an agent) turns that intent into code. And we review the code.

But if the intent was wrong — if the requirement was based on untested assumptions, if nobody challenged whether this feature should exist — then it doesn't matter how clean the code is. You built the wrong thing perfectly.

The PR reviews the implementation. Nobody reviews the intent.

On my team, before a line of code gets written, we challenge the intent. We run the strategic question through multiple AI models independently, compare where they agree and disagree, and catch bad assumptions before they become bad code. It catches the real failures — the "we built the wrong thing" failures that no amount of code review would have stopped.

And once you've challenged the intent, the output is an implementation plan — how you're going to build it, what architecture, what tradeoffs, what order. And that's what deserves peer review.

A human reviewing an implementation plan can actually add value: "You're solving the right problem the wrong way." "This won't scale." "There's a simpler path." A human reviewing a diff at 4:47 PM on a Friday? They're checking syntax. The CI can do that.

The Verification Stack

The stack should look like this: Intent — challenge the assumptions before writing anything, multi-model if high-stakes. Plan — peer review the architecture and tradeoffs, not the code. Code — push to main, E2E tests, automated pipeline. Production — agent monitors latency, errors, business metrics continuously. Outcomes — did it move the KPIs you said it would?

We were reviewing the code — the one layer where human judgment adds the least value. Exactly backwards.

What Replaces the PR

Verification shifts in both directions — left to the intent, right to production. The middle (code review) becomes the least important checkpoint.

Push to main. No branches, no PRs. Auto-deploy to dev/staging on every push. Automated E2E tests verify the app behaves correctly, not that the code looks right. Progressive rollout — canary deploy, feature flags, 1% of traffic then 10% then 100%, controlled blast radius. Production monitoring — an agent watches latency, errors, and business metrics continuously. Fix forward, don't rollback — the code is already in main, fix it, push the fix, let it promote through the same pipeline. And code review still happens — async, after the fact, for learning. Not a gate. A retrospective.

Your job changes from "read this diff and tell me if it's safe" to "define what safe looks like and let the system verify it."

The Honest Question

How many security vulnerabilities has your PR process caught in the last year? Not typos. Not style comments. Real security issues that would have made it to production.

Now compare that to how many issues were caught by monitoring, alerts, and automated tests.

The data isn't even close.

I'm not saying code review is worthless. I'm saying it's not worth blocking deploys for. Review the code after. Learn from it. But stop pretending a human reading diffs is what's keeping your production environment safe. Your monitoring is. Your tests are. Your recovery speed is.

Next in the series: Your Software Has a Pulse — What happens when your software stops being a static artifact and starts monitoring itself, responding to change, and evolving?