The Faster AI Writes Your Code, the More You Need End-to-End Tests

Vibe coding — describing what you want and letting an AI agent write it, reviewing the result at the level of "does it look right" rather than line by line — has moved from a meme to a workflow. Whole features now ship where no human has read every line of the diff. Depending on which survey you believe, somewhere between a quarter and half of new production code at AI-forward companies is machine-written.

The productivity gain is real. So is the tradeoff nobody prices in: code volume goes up while human review depth goes down. Those two curves cross somewhere, and past that point your quality gate isn't the reviewer anymore. It's whatever your CI pipeline actually checks.

Why Your Existing Tests Won't Catch It

"But we have tests" usually means unit tests — and in an AI-assisted workflow, unit tests have a specific blind spot: they were often written by the same model, in the same session, from the same understanding of the task as the code they test. If the AI misread the requirement, the tests encode the same misreading. They verify that the implementation agrees with itself, not that the feature does what the user needs.

Type systems don't close the gap either. TypeScript will catch a renamed field. It will not catch that an order's price calculation quietly changed, that a status transition now fires twice, or that a serialized blob written by last month's code can't be read by this month's.

And that's exactly where AI-era regressions concentrate: in the seams. Service boundaries, shared libraries, persisted data shapes, event flows. We maintain a manufacturing client's ordering platform where one shared calculation library feeds the web client, several backend services, and documents stored years ago. A single confident-looking PR can change what a stored offer means — and every unit test still passes, because every unit still does what it individually promised.

E2E Tests Don't Care Who Wrote the Code

An end-to-end test makes no assumptions about the implementation. It logs in, builds an order, checks that the price is right, generates the PDF, and asserts the outcome in the same terms the business would: the customer got the correct document.

That implementation-blindness used to be cited as a weakness of E2E testing — the tests are slow, they don't tell you which function broke. In a vibe coding world it's the whole point. When the implementation is machine-generated and lightly reviewed, the only durable definition of "the app still works" is a test that exercises the app the way a user does. E2E tests are that definition, in executable form.

Per-PR, or It Doesn't Count

An E2E suite that runs nightly, or manually before releases, gives you archaeology: you learn something broke, then spend a day figuring out which of yesterday's twelve merges did it. AI-assisted teams merge faster than that feedback loop can absorb.

The suite has to run on every pull request, as a merge gate. Practically, that means the pipeline can boot your whole stack in CI — app, services, database with seeded data — stub the external dependencies like ERPs and email, wait until everything is actually ready, and drive a headless browser through the flows. Getting there is an infrastructure project first and a test-writing project second. In most codebases we've audited, the local dev stack almost works in CI: the routing config assumes a developer's machine, external services have no stubs, nothing exposes a health check. Fixing that foundation is the bulk of the work — and it's a one-time cost.

Keep the Suite Small and Ruthless

The classic failure mode is aiming for coverage: hundreds of E2E tests, hours of runtime, flaky enough that developers learn to re-run red builds without reading them. A flaky suite is worse than no suite, because it trains the team to ignore the one gate they have left.

The alternative is to rank your features honestly — by business importance, and by how many services and shared libraries a change elsewhere can break them through — and cover the top of that list. When we did this exercise recently for a dealer platform with about twenty distinct features, the entire money path came down to four use cases: create an order, price the products, produce the offer with its PDF, submit and confirm. Ten to fifteen well-chosen flows catch most of the disasters that matter. The rest can stay with unit tests and humans.

AI-assisted development isn't going to slow down, and the review bottleneck isn't coming back. The teams that get to keep the speed are the ones that moved the safety net from "a person reads the diff" to "a pipeline proves the product still works" — on every PR, before merge.

Rebooted Solutions builds automated E2E pipelines — from CI infrastructure and stubbed dependencies to a focused test suite over your critical flows. If your team is shipping AI-written code faster than it can review it, book a strategy session and we'll scope what a per-PR safety net would look like for your stack.