What a Green Check on a Pull Request Should Promise
Most merge gates stop at build, unit tests and contracts. Coding agents clear those easily, so the check that matters most, behavior against the real system, has to run before merge.
Pick a merged pull request with a green check and ask the team what the check guarantees. You will hear which jobs ran. You will rarely hear what anyone downstream can now assume.
That matters because main is shared ground. Other teams cut branches from it, ship their own services against it and, when something breaks, start from the belief that what was already merged is correct. Every merge makes that promise to them, usually without anyone stating its terms.
Leaving the terms vague was cheap while people wrote each change and stuck around to support it. Coding agents undo both. They raise the number of PRs, and a growing share comes from sessions that keep no memory once the work is handed off. For teams verifying AI-generated code on Kubernetes, the merge gate is where that missing context shows up first.
The four questions a merge answers
Remove the tool names and a change has four questions to clear before others should depend on it.
- Does it build? The code compiles, clears linting and static analysis, and yields an artifact you can deploy.
- Does its logic hold? Unit tests show the code behaves as written, on its own, with its dependencies replaced by stubs.
- Does it keep its promises at the boundaries? The API shapes its callers rely on and the message formats it publishes stay compatible.
- Does it behave correctly in the running system? Through the real call paths, it returns correct results and stays within acceptable latency, error rate and resource use next to live versions of its neighbors.
Questions one through three are inexpensive. No environment is needed, they parallelize freely and they finish in minutes.
Question four needs a live system, and it alone catches the failure that does the most damage in microservices: code that is right in isolation and wrong in context. One consumer still reads a field that was renamed. A new retry loop triples traffic to a service two hops downstream. A query passes its test and then times out on data shaped like production’s.
Why most gates stop at question three
Until recently, question four could not be answered before merge. It required an environment with every service up, and such environments were rare, slow to build and costly to run. A typical organization had one or two shared staging copies, always in demand and often broken.
The industry adapted. Changes merged once they cleared the first three questions, and system behavior got checked later, in a shared environment where untested work from every team accumulated. Release management, code freezes and on-call for pre-production grew up largely to handle that accumulation.
Nobody decided on principle that system behavior should be tested after merge. The gate was sized to the infrastructure. Because pre-merge environments were out of reach, the check that needed one moved to the other side of the merge.
The arrangement worked while people set the pace. Ten changes a day in staging could be untangled by reading the log and messaging a few authors, who still remembered their code and could ship a patch.
What coding agents do to a three-question gate
Agents increase the flow of changes. In GitLab’s 2026 research with the Harris Poll, 85% of respondents agreed that AI has shifted the bottleneck from writing code to reviewing and validating it. Nearly all of that extra output clears questions one through three, since those are the checks an agent can run and retry until they pass.
The agent has no view of the consumer three services away, because that consumer is not part of its loop. The cost of that blind spot is measurable. CodeRabbit’s analysis of 470 open-source pull requests found AI-generated PRs contained about 1.7 times as many issues as human-only ones, and logic and correctness issues were 75% more common. A three-question gate now waves through exactly the changes most likely to fail the fourth.
Catching those failures after merge gets harder with every additional change. Tracing a break across ten merged changes is an afternoon. Tracing it across fifty, many from agent sessions that have already ended, turns into a cross-team investigation, and each extra change in the window makes every failure slower to pin down.
So the old arrangement fails on both sides. More risky changes get through the gate, and the after-merge safety net is too overloaded to catch them.
Answering question four costs seconds now
The infrastructure limit behind that arrangement no longer applies. Giving a single change a realistic system no longer requires cloning the stack.
Here is the approach that replaced cloning. One set of stable services runs in the cluster, kept current by your existing deployment pipeline. For each pull request, only the service or two it modified get deployed beside that set.
The routing layer keeps changes apart. Test requests for a pull request carry a routing key in a header, passed from service to service by standard context propagation such as OpenTelemetry baggage. When a request with that key reaches a service the PR changed, it goes to the PR’s version. Everywhere else it goes to the shared stable version.
So each pull request gets a full, production-like system in which its own code is the only change, and dozens can run side by side on one cluster. Since only the modified services start, the lightweight ephemeral environment is up in seconds, and answering question four costs roughly what a unit test run does.
Writing the contract down
Without that limit, the pipeline can split its work cleanly.
| Stage | Questions it answers | Where it runs | Target time |
|---|---|---|---|
| CI | 1 to 3: build, logic, contracts | CI runners, no environment | Minutes |
| Pull request environment | 4: integration, end-to-end and smoke-level non-functional checks | A lightweight ephemeral environment per PR | Minutes, in parallel with every other open PR |
| After merge | Confirmation that nothing changed in aggregate | Shared environment | A thin smoke check |
CI speeds up once it drops every job that depends on a live system. The pull request takes on integration and end-to-end testing, whether a person or an agent wrote the code. The slow integration stage after merge becomes a quick smoke test or disappears.
What each stage is for changes too. After merge, the pipeline confirms there are no problems instead of hunting for them. The hunting is done before the promise to other teams is made.
Now the contract can be written in full, because each line is checked. The change builds. The logic passes its tests. The interfaces are compatible. The change ran correctly among the real services. A green check means proven, not likely.
The gate is a decision now
For a long time, a merge gated whatever the available environments allowed. That excuse is gone. Testing each change in a realistic system is no longer the costly step, and writing code is no longer what limits delivery. Verifying it is.
The teams getting the most from coding agents are not the ones with the highest output. They are the ones that test system behavior before merge, so extra output turns into shipped features rather than a backlog of unproven changes. Merging to test is the habit that change retires.
Signadot supplies the pull request stage in the table above: lightweight ephemeral environments on the Kubernetes cluster you already run, plus Jobs that execute integration and end-to-end suites inside them for every PR. Signadot for agentic development shows how that stage fits an agent-heavy pipeline. What stays with your team is deciding what a green check should guarantee, and writing that down.
