Skip to main content

Heroku Invented the Preview Environment for Humans. In 2026, AI Agents Are the Ones Clicking the Link.

8 min readDora NodaDora Noda
Share
On this page

Devin Review catches an average of two bugs per pull request before a human ever opens it — and roughly 58% of them are severe: logic errors, missing edge cases, security vulnerabilities. Cognition built it so that Devin, the agent that wrote the code, and Devin Review, a second agent with no shared context, iterate against each other until most of the damage is already fixed. GitHub shipped a version of the same idea into Copilot's code review on March 5, 2026: an agentic pass that gathers full project context, flags an issue, and can hand it straight to Copilot's coding agent to generate a fix PR — closing the loop before a person is in it at all.

Neither of those tools is reviewing code in the abstract. They're reading a running application — the actual build, the actual diff, deployed somewhere they can poke at it. That "somewhere" is the preview environment, a category Heroku invented in 2015 for an entirely different reader: a human, clicking a link, deciding if the thing looks right. Eleven years later, the reader has started to change, and the primitive hasn't caught up.

What Heroku Actually Built

Heroku's Review Apps shipped in beta in 2015 as part of its GitHub integration and went GA in April 2016. The mechanics were simple and, at the time, genuinely novel: open a pull request, and Heroku spins up a disposable app — its own dyno, its own add-ons, its own config — at a temporary URL. Push a new commit, the review app rebuilds. Merge or close the PR, Heroku tears it down. Every competitor's per-PR preview feature since — Netlify deploy previews, Vercel preview deployments, Render's PR environments — is a variation on that same shape.

The entire interface is a URL. There's no status a script can poll, no structured pass/fail, no notion of a caller that isn't a person with a browser tab open. That wasn't a limitation in 2016 — it was the whole point. A review app existed so a teammate could look at something instead of imagining it from a diff. The category was built, correctly, around a human reader.

Four 2026 Tools Already Reviewing Before a Human Does

The reader is no longer only human, and four pieces of 2026 tooling show the shift isn't a one-off:

  • GitHub Copilot's cloud agent works inside its own ephemeral GitHub Actions environment — explore the code, make changes, run tests and linters, all before opening a PR. Sessions are capped at 59 minutes, scoped to one repo and one branch, and the environment is gone when the session ends.
  • GitHub Copilot code review, running on the agentic architecture GitHub shipped March 5, 2026, doesn't just leave comments — it can pass a finding directly to the coding agent, which generates a fix PR. Review and remediation become one loop instead of two separate steps a human bridges.
  • Devin and Devin Review iterate against each other on Cognition's infrastructure before a human ever sees the pull request, catching an average of two bugs per PR at roughly 58% severity. For anything visual, Devin uses Vercel's preview links and sends screenshots into Slack rather than making a person open the deployment themselves.
  • Vercel's Deployment Checks let a team wire E2E tests as a quality gate on a preview deployment, and the CLI supports --no-wait plus a separate inspect command so a caller can kick off a deploy and poll its status instead of blocking on it — output available as JSON, not just a rendered dashboard.

Every one of these is doing the same thing Heroku's Review Apps were built for — validate a change in a running environment before it ships — except the thing doing the validating is a tool call, not a click.

What a Preview Environment Needs to Be an Agent's Review Step

Set Heroku's URL-only interface next to what an agent actually needs to call, and the gap is specific, not vague:

RequirementHeroku-shape preview envWhat an agent's review step needs
StatusA URL a human opens and looks atA machine-readable pass/fail a tool call can poll — build succeeded, tests passed, ready
TriggerA GitHub webhook fired by a human's PRA programmatic trigger the agent itself can call, independent of a PR existing yet
OutputA log stream meant for a person to scroll and eyeballStructured, parseable results — which tests failed, what the diff actually changed
Caller identityA human's OAuth session in a browserA service identity or API token — no browser, no session, no person present

None of these four is exotic — Vercel's Deployment Checks alone covers most of the "status" and "trigger" rows. But no single tool covers all four as one coherent, callable interface, and that's the actual requirement: an agent validating its own PR needs to ask "did this pass" the same way it asks any other tool for a result — a return value, not a page render.

The Honest Gap: What 2026 Tooling Still Doesn't Give You

The four capabilities above exist today, but scattered and vendor-specific, not as a portable platform primitive. Copilot's ephemeral environment is GitHub Actions-shaped and disappears at 59 minutes — useful to the agent that spun it up, not addressable by a different tool afterward. Vercel's Deployment Checks are a real quality gate, but they're configured by a human ahead of time and scoped to Vercel's own deployment model. Devin's Vercel-preview-plus-screenshot workflow is explicitly built for a human reviewing a Slack message, just with an agent doing the looking-and-summarizing step first — the pass/fail judgment still routes through a picture, not a status code.

And most self-hosted or open-source PaaS preview environments haven't moved at all: they still do exactly what Heroku did in 2016 — build the branch, hand back a URL, tear it down on merge. That's not a criticism of the URL; a human still wants one. It's that the URL can no longer be the only thing the environment returns.

Why an MCP-First Deploy API Has a Shorter Path Here

This is where it matters whether a platform's deploy API was built agent-first or human-first, and the difference isn't cosmetic — it's what has to change to add the four rows above.

A human-first incumbent — Heroku's own Review Apps, or Vercel and Netlify's preview flow as most teams use them — authenticates every caller through an OAuth session tied to a person, and returns state as a URL plus a dashboard meant to be looked at, not parsed. Bolting on agent support means retrofitting a second auth path (a service identity or API token model sitting next to the human OAuth flow) and a second output format (a JSON status endpoint standing next to the page a human already reads) without breaking the first — two parallel interfaces to maintain indefinitely.

Bex.co, the open-source, AI-native Render alternative, starts from the other side: its deploy API already treats an MCP-calling agent as a first-class caller alongside a human pushing to git, so there's one identity model and one structured status format to extend, not two to keep in sync. Concretely, a preview-environment status response an agent can poll needs to carry: build status (queued, building, failed, ready), test status if checks are wired in, the preview URL for the human who still wants to look, and a structured diff summary an agent can reason about without screenshotting the page. That's a smaller, incremental addition to an API already shaped for tool calls — not a second system grafted onto a browser-first one.

The Reader Is Changing, Not the Category

Heroku didn't get the preview environment wrong in 2015 — it built exactly the right primitive for the reader it had. What's changing in 2026 isn't the idea of validating a change before it ships; it's who's doing the validating first. Devin Review, Copilot's agentic code review, and Vercel's Deployment Checks are all early, partial answers to the same question: what does a preview environment look like when the first reader is a tool call instead of a browser tab?

The platforms that answer it by extending one interface — rather than maintaining a human-facing one and bolting an agent-facing one alongside it — are the ones that won't be retrofitting this a second time when the next review step moves earlier still.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with a deploy API that already treats an MCP-calling agent as a first-class caller. Star the repo on GitHub or deploy your first app today.

Sources

Related articles

Run this on infrastructure you own

bex is the open-source, AI-native Render alternative — push a git repo and get a running HTTPS service on your own machines.

Get started with bex