In an AI-native SDLC, a PR without a preview is a feature you're shipping blind

When your developer built a feature, you could walk over and watch them click through it. When an agent builds it, there is no desk to walk to. In an AI-native SDLC, a live preview for every pull request is how you see the feature before you approve it. And it's easier than you might think!

There was always a way to see a feature before you approved it. You walked over to the developer's desk and you clicked through it together. Or they pulled you a build, or you checked out the branch and ran it locally. The specifics varied, but the moment was the same: a person showed you the running thing, and you judged it by how it looked and behaved, not by how its code read.

That moment is quietly disappearing, because increasingly the developer is an agent.

There is no desk to walk to

When an agent implements a feature, there is no desk to visit. Nobody is going to walk you through the flow, seed the test data, or say "oh, ignore that, it does the right thing when you click here." The agent hands you a pull request and moves on to the next one. Then it opens three more.

So you are left with the diff. And the trouble with a diff is not that the code is wrong. The code may be perfect, exactly what the spec asked for. The trouble is that a diff is almost impossible to imagine your way through. You cannot feel a flow by reading it. You approve what looks reasonable, and only later, when you finally see it running, do you actually understand what you asked for, and sometimes realize the spec itself should change.

That realization has to arrive before the merge, not after. If you merge first and adjust once you have seen it live, every adjustment lands on top of code that was already accepted. Do that across dozens of agent-authored pull requests and the codebase fills with half-baked features that were never quite right and are now hard to pull back out. Seeing the feature live is the moment you decide whether it should exist in this shape at all, and that moment is cheap before the merge and expensive after it.

The volume makes this urgent rather than merely nice. One agent can open more pull requests in a day than a person can carefully read, let alone check out and run one at a time. The old ritual, "pull the branch and try it locally," does not scale to that. It was already friction when humans wrote every line. At agent throughput it is a wall.

Let the pull request show you the feature

The fix is to make the running feature come to you, automatically, on every pull request. A pull request preview is a live, isolated deployment of the change, reachable at a stable URL, created when the pull request opens and torn down when it closes. Every change gets its own running copy of the product, wired up enough to click through.

That is the developer's desk, rebuilt for a world where the developer is an agent. A reviewer opens the link and uses the feature. A product manager checks the copy and the flow without asking anyone to run anything. A designer sees the real rendered UI instead of a screenshot. Nobody has to imagine the feature from a diff, because the feature itself is right there to use, and the decision to ship it, change the spec, or send it back is made against the real thing while it is still cheap to change.

It also gives your automated reviewers something to stand on. If an agent is going to verify a change, it needs a running target to exercise, not just a patch to reason about. The preview is that target. The loop closes: a change is proposed, deployed, exercised, and judged against real behavior, before it reaches the main branch.

Two ideas that keep it cheap

The objection is always cost. A full environment per pull request sounds slow and expensive. It does not have to be, and two principles are what keep it affordable.

Deploy only what changed. A pull request that only touches the frontend should not redeploy the backend, but a change in the backend requires a frontend using the new backend. Detect which surfaces a change actually affects and deploy just those. Most pull requests touch one thing, so most previews are small and fast, and only the rare change that touches everything pays for everything.

Isolate what is risky, share what is safe.Each preview needs its own copy of the parts that would collide: the application code, the routes, the URL namespace. It does not need its own copy of everything. Stateful, slow, or expensive layers, the database, identity, the content delivery layer, can be shared from a long-lived development environment, with each preview reaching them through its own scoped path. Isolation where two previews would step on each other, reuse where they would not. That single decision is the difference between a preview that appears in a minute and one nobody wants to wait for.

Make it standard, not a perk

The teams that treated continuous integration as optional a decade ago lost to the teams that ran the tests on every commit, no exceptions. Previews are following the same curve, and agents are accelerating it. When the developer is a machine and there is no desk to visit, the preview is not a convenience for the scary changes. It is the only place the feature exists to be seen before it merges.

So make the running preview a property of every pull request, the same way the test suite is: simply there, on all of them, funded and maintained as core infrastructure rather than something a senior engineer wired up once and hoped would survive.

The question to bring to your team is small and revealing: before we merge this, can we click through it? If the honest answer is "only if someone checks out the branch and runs it," and increasingly no one will, that gap is worth closing. In an AI-native SDLC it is the difference between reviewing what the code says and seeing what the change does.

A follow-up post will get concrete about how to build this, the change detection, the routing, the shared-versus-isolated split, and the teardown, in a way that stays cheap at scale.