A merge is a contract. The moment a change lands on main, every other team in the organization starts building on the assumption that it works. They branch from it, deploy on top of it, and debug their own failures, believing that what came before them was sound.Most engineering organizations have never written that contract down. They have a pipeline that runs checks, and whatever the checks cover is what the merge promises. Ask what a green checkmark on a PR actually guarantees, and you rarely get a precise answer.“A merge is a contract. The moment a change lands on main, every other team in the organization starts building on the assumption that it works.”That vagueness used to be affordable. Code arrived at human speed, written by people who carried its context in their heads and stayed around after merging. Both of those conditions are now gone. Coding agents are multiplying PR volume, and an increasing share of changes arrive written by something that holds no lasting context at all. The industry has already noticed the consequence: in GitLab’s recent survey, 85% of respondents said the bottleneck has shifted from writing code to reviewing it. It is time to define the contract explicitly and then look honestly at where today’s pipelines fall short of it.The four layers of confidenceStrip away tooling, and a change needs four things established about it before the rest of the organization builds on top of it.First, it is well-formed. It compiles, passes lint and static analysis, and produces a deployable artifact.Second, it is internally correct. Unit tests confirm the logic does what its author intended, in isolation, with dependencies stubbed out.Third, it is compatible at its boundaries. It honors the API contracts its consumers depend on and the schemas its producers emit.Fourth, and this is the layer that matters most in a distributed system, it behaves correctly against the real system. This means both functional and non-functional behavior: functionally, it returns the right results and honors the flows its neighbors expect; non-functionally, it holds up under real traffic in latency, error rates, resource usage, and backward compatibility. This is checked not against mocks or recorded fixtures, but against live versions of the services it calls and the services that call it, with real data shapes and real failure modes.“The fourth is the expensive one. And the fourth is the only layer that catches the class of bug that actually hurts in microservices: the change that is locally correct and systemically wrong.”The first three layers are cheap. They need no environment, they parallelize trivially, and they finish in minutes. The fourth is the expensive one, because it needs somewhere real to run. And the fourth is the only layer that catches the class of bug that actually hurts in microservices: the change that is locally correct and systemically wrong.How the top layer slipped out of the gateFor most of the last decade, the fourth layer did not run before the merge. It could not. Establishing real-system behavior meant having an environment where every service was running, and such environments were scarce, expensive, and slow to create. Teams had one or two shared ones, contested and often broken.So the industry made a quiet compromise. Merge on the first three layers, then discover system behavior afterward, in a shared environment where everyone’s unvalidated changes accumulate together. We built release management, freeze windows, and on-call rotations for pre-production largely to manage the consequences.The compromise held, barely, at human pace. When a shared environment underwent ten changes, someone could reconstruct the timeline and find the culprit by asking around. The author was still nearby, context intact, ready to push a fix.“It was never a principled position that system validation belongs after merge. It was a concession to an infrastructure constraint.”Notice what the compromise actually was. It was never a principled position that system validation belongs after merge. It was a concession to an infrastructure constraint: pre-merge environments were impractical, so the gate shrank to fit what infrastructure could deliver.Agents turn a compromise into a liabilityNow change the arrival rate. Agents let a team of a hundred engineers produce PR volume that once required several hundred. Every one of those changes easily clears the first three layers, because those are precisely the checks agents are best at meeting. An agent iterates until the build is green, the units pass, and the contracts line up.What an agent cannot do on its own is discover that its locally perfect change breaks a consumer three services away, because nothing in its feedback loop contains that consumer. It is not a hypothetical risk: analysis of open-source pull requests has found that AI-authored changes carry roughly 1.7 times as many issues as human-written ones, with logic and correctness errors overrepresented. If the merge gate stops at layer three, the gate is now systematically passing changes whose most dangerous failure mode was never examined.Post-merge discovery breaks down for the same arithmetic reasons. Attribution over a shared branch was tolerable with ten changes in the batch. With fifty, most of them machine-authored and their authors context-free the moment the PR closed, a red suite becomes archaeology. Each additional change in the batch makes every failure more expensive to diagnose, precisely when batches are growing.Both halves of the old compromise failed together. The gate passes changes it should not, and the after-the-fact safety net can no longer absorb them.The constraint that justified all of this is GoneHere is what changed on the infrastructure side. You no longer need a full copy of the stack to give one change a real system to run in.The model that replaced duplication is straightforward. Your Kubernetes cluster runs a single shared, stable environment that contains the current version of every service, kept up to date by your standard deployment pipeline. When a PR needs validation, only the one or two services changed by that PR get deployed alongside it.Isolation comes from routed traffic, not from duplicating the entire stack. Requests belonging to that PR carry a small identifying label in their headers. The routing layer reads the label and directs those requests to the changed services where they exist, and to the stable versions everywhere else. Every PR sees a complete, production-like system containing only its own changes, and dozens of PRs can validate simultaneously in the same cluster without affecting each other.“Isolation comes from routed traffic, not from duplicating the entire stack. Every PR sees a complete, production-like system containing only its own changes.”Because only the changed services start, such a lightweight ephemeral environment is ready in seconds. The fourth layer of confidence, the one that was too expensive to establish before merge, now costs about as much as a unit test run. This is the capability that platforms like Signadot provide, and it removes the last reason the merge gate stops at layer three.Rewriting the contractWith the constraint gone, the pipeline reorganizes around a clean division of labor.CI keeps the first three layers and gets faster by shedding everything else. Build, static analysis, unit tests, contract checks, done in minutes. Its job is to answer one question: is this a well-formed component?The fourth layer moves into the PR itself. Every pull request, human- or agent-authored, gets its own ephemeral environment and runs its integration and end-to-end validation there, in parallel with every other open PR, before merge. The heavyweight post-merge integration stage, the one that made the whole pipeline slow, shrinks to a thin smoke check or disappears entirely.The bigger change is in what the stages mean. The post-merge pipeline stops being where problems are discovered and becomes where their absence is confirmed. Discovery belongs before the contract is signed, not after.The merge contract is then worth writing down, because every clause is enforced: this change builds, its logic is tested, its contracts are compatible, and it has run correctly against the real system. Green means validated, not probably fine.The gate is a choice nowFor years, the honest answer to what a merge should gate was whatever our environments could support. That answer is not accurate anymore. Per-change validation against a production-like system is no longer the expensive part of the pipeline, and code volume is no longer the limiting factor of software delivery. Validation is.Teams adapting fastest to agent-assisted development are not the ones generating the most code. They are the ones who moved system validation to the left side of the merge, so that velocity arrives as shipped features instead of as a longer queue of unvalidated changes. The infrastructure permits it. The volume demands it. What remains is deciding what your green checkmark should mean and building the gate that enforces it. If you want to see that gate running against your own services, Signadot is a practical place to start.The post 85% say code review is the new bottleneck. Here’s what the AI coding narrative leaves out. appeared first on The New Stack.