Branches Are Dead.
Here's What Replaced Them.

You're a developer on a small team. You've got a PR process. You've convinced yourself it's working.

Then something breaks in prod, and you have The Conversation. You know the one.

"Should we add more review gates?" "Maybe we need required approvals?" "What if we protected the branch better?"

You add more process. The next break happens anyway. You add more process. Here's the thing nobody says out loud: you're not actually reviewing anything. You're performing safety.

I know because I spent years performing it too.

What PR Reviews Actually Look Like

Your teammate pushes 400 lines across 12 files. You open the diff.

You don't have the full context of what they were solving. You scroll. You look for obvious stuff — a typo, maybe a missing null check. You write "looks good" or "nit: rename this." You click approve.

That's not a review. That's theater with extra steps.

You were never going to catch the bug where the auth middleware conflicts with the Stripe webhook handler by reading a diff. That kind of bug only surfaces when you run the thing. In a real environment. With real data flowing through it. But nobody said that. So we kept performing.

What I Did Instead

Last month a teammate pushed something that broke our auth flow. Stripe webhooks stopped firing. Classic.

I thought about adding a dev branch. I thought about it for maybe ten minutes. Then I said no. Instead I spent an afternoon building something that actually catches bugs.

Hours 1-2: copied our existing Terragrunt config. We already had AWS infra defined in layers. Spinning up a parallel environment was mostly copy-paste with AI filling in the parts I didn't remember. Hours 3-4: wired GitHub Actions — push to main, build container, deploy to dev0 on ECS Fargate. Hours 5-6: Playwright E2E tests bootstrapped. Login flow, critical paths, the stuff that actually breaks.

Five to six hours. The result catches more bugs than any PR review I've ever done.

The Pipeline Is the Reviewer

Here's the flow now: push to main, GitHub Actions builds the container, deploys to dev0 — its own database, its own auth, its own everything — Playwright runs against the live deployment, green means auto-promote to prod, red means fix and push again.

Playwright doesn't get tired. It doesn't rubber-stamp because it's Friday. It doesn't skip the auth flow because "I'm sure that part's fine." Same checks, every time, against a real running app.

That's a better reviewer than I ever was.

"But What About Code Quality?"

Yeah, I know. Knowledge sharing. Mentorship. Culture of accountability.

Sure. In theory.

In practice on a two-person team: knowledge sharing happens in Slack, mentorship happens in pairing sessions, and code quality comes from linting and type checking — all of which run in CI anyway.

You know what actually improves code quality? Shipping fast, seeing what breaks, fixing it immediately. Tight feedback loops beat gatekeeping every time.

Why This Works Now and Didn't Three Years Ago

When something breaks in dev0, I can fix it roughly as fast as I can find it. AI diagnoses the failure, understands the stack trace, generates the fix. Red build to green build in minutes, not hours.

That changes the entire calculus.

PR gates were always a hedge against slow recovery. "Breaking prod is expensive, so we need humans to read code before it ships." But what if breaking a dev environment is cheap and fixing it is fast? Then the gate is just friction.

Branches were a hedge against slow recovery. When recovery is fast, branches are just slowing you down.

The Blast Radius Principle

Same thinking extends to production. Don't try to prevent every bad change. Make bad changes cheap.

Feature flags: ship dark, feature is in prod but off, enable it for 5% of users, watch error rates and conversion, roll it wider or kill the flag — no deploy, no drama. Canary deploys: route 5-10% of traffic to the new container, if errors spike the other 90% never noticed. Blue/green environments: deploy to the inactive one, verify, swap the load balancer — wrong? Swap back in seconds.

Old thinking: prevent bad changes from reaching users. New thinking: let changes flow fast, control the blast radius. The first optimizes for safety through slowness. The second optimizes for safety through speed of recovery. When AI makes both building and fixing fast, the second wins by a mile.

The Question You Should Sit With

When was the last time a PR review caught a real bug? Not a typo. Not a style nit. Something that would have actually broken prod.

Now count how many hours your team spent last week on reviews. Writing them, waiting for them, addressing comments, resolving merge conflicts from stale branches.

What if you spent those hours writing E2E tests instead?

Most teams already know PR reviews are theater. They just haven't given themselves permission to stop.

So here's my challenge: try it. Stand up a dev environment. Write some Playwright tests. Push to main. See what happens. I think you already know what you'll find.

Next in the series: The Death of the PR — If branches were the first casualty, PRs are next. What happens when verification shifts from reading code to monitoring outcomes?