AI changed the cost of writing code. It did not change the cost of being wrong.
That asymmetry is the whole story of CI/CD right now. When a team of five ships thirty changes a week, a human approval gate before production feels like diligence. When the same team ships thirty changes a day because most of the code is drafted by agents, that gate becomes one of two things: a rubber stamp, or a queue. Neither is safety.
The answer might seem uncomfortable: automate deployment to every environment, including production, and put all of your rigor into the gates.
The workflow
One pipeline, triggered by a merge to the main branch. No manual steps after that point.
- Fast checks first. Typecheck, lint, build, unit tests. Minutes, not hours. This stage exists to catch the boring 80% before you spend infrastructure on it.
- Deploy to Test — automatically. Not a mock, not a container graph on the runner. The real deployment mechanism, into a real environment, built from the same infrastructure code as production.
- Run end-to-end tests against Test. This is the stage that earns the right to skip a human. It exercises the deployed system through its actual interfaces.
- Green? Deploy to the next environment — automatically. Staging, pre-prod, whatever you call it. Run the e2e suite again, plus whatever only makes sense with production-shaped data: performance checks, contract tests, migration rehearsals.
- Green? Deploy to production — automatically. Then post-deploy smoke tests and health checks, with automatic rollback if they fail.
The only human decision in the entire path is the merge. Everything after it is a proof obligation, and proof obligations belong to machines.
Why this is the right shape for AI-native delivery
- Tests are the specification agents actually work against. An agent can't read your intent, but it can turn a red suite green with remarkable persistence. That cuts both ways: whatever your tests assert is what you get, and whatever they leave unsaid is what drifts. In a codebase where most changes originate from a model, the test suite stops being a safety net and becomes the source of truth for what the system is supposed to do.
- The old excuse for skipping e2e tests is gone. Comprehensive end-to-end coverage was always the correct answer and always too expensive to write and maintain. That cost has collapsed. If the reason your pipeline still ends in someone clicking "Deploy to production" is that nobody had time to write the tests that would replace the click, the constraint you're working around no longer exists.
- Unattended iteration needs deterministic gates. The most valuable thing you can give an agent is a fast, honest signal it can loop against without a human in the room. A pipeline that requires interpretation — a flaky suite, a "usually fine" warning, a soak period someone eyeballs — can't be part of that loop.
- Small batches are the actual safety mechanism. Manual gates encourage batching, because clicking twelve buttons is annoying, so changes pile up until someone does a release. Bigger batches, bigger blast radius, harder debugging. Continuous deployment inverts it: every change ships alone, so when something breaks you already know what broke it.
What you have to get right first
This isn't a lifestyle choice you adopt on a Tuesday. It has preconditions, and skipping them is how teams conclude that continuous deployment "doesn't work here."
- Zero tolerance for flaky tests. A suite people re-run to get green is worse than no suite, because it teaches everyone that red means nothing. Quarantine flakes the day they appear, then fix or delete them.
- Environments built from the same code. If Test and production differ in configuration, a passing e2e run proves nothing about production.
- Deploy decoupled from release. Feature flags are what make "production deploys automatically" compatible with "we don't ship half-finished features." Merging becomes safe long before the feature is done.
- Backward-compatible migrations. Expand-contract, always. Automated deploys and irreversible schema changes are a bad combination.
- Observability and automatic rollback. Your last gate runs in production. It needs to be able to undo a deploy without waking anyone.
- A pipeline under twenty minutes. Past that, people and agents start batching around it, and you lose the benefit you paid for.
The anti-patterns, named
A manual approval before production. A QA sign-off phase. A staging environment that soaks for a day while nobody looks at it. Release branches and cherry-picks. Mocking your way through the e2e suite because the real environment is slow.
Every one of these asks a human to certify something they can't actually verify by looking at it. That was already a fiction when humans wrote all the code. It doesn't survive contact with a codebase where they don't.
Put the judgment in the tests. Let the pipeline ship.
Curious what this looks like in a real delivery project? Get in touch.