CircleCI’s 2026 State of Software Delivery Q2 Pulse Report named the key performance metric we’re talking about here: Merge Efficiency Ratio (MER). How many feature-branch validation cycles does it take to get a change onto main?
Median teams sit around 3.9. The top 5% run about 2.6. An elite cohort of twenty orgs is already near 1.3.
Most of the industry is still grinding through several rounds of feature-branch rework before earning the right to merge to main. The leaders are closer to one.
When coding agents are the ones waiting on those rework cycles, MER is not a vanity metric. It is the clock and the bill. Extra loops mean more tokens burned, more CI credits spent, and more agent context rotting on a red light from CI.
The Q2 Pulse Report is blunt: lower MER is a DX win, an AX win, and a cost win.
I ran a small AFK lab experiment that rhymes with that report. Not an org-level MER study. Same shape of problem, inside a single agent setup.
Hypothesis
If a green PR is already likely, pushing only once at the end should burn far fewer outer-loop CI credits than pushing after every task. And if deterministic checks live on the inner loop once, you stop paying time and money three times for the same linter.
Pushing once at the end is only safe once the agent can reliably go green.
Setup
In our core experiment to determine the cost of a green PR, we found that if you give the agent a sneak peek at the CI setup, let it take notes before coding begins, and let it do a practice run on inner-loop checks before pushing to outer-loop CI, you can achieve 100% green PRs with zero rework.
The sneak peek is actually quite simple. Before task one, before a line of game code gets written, the agent receives a short inventory of the CI setup: which checks fire on the inner-loop practice run, which jobs fire on the outer-loop CI pipeline, and pointers to the scripts and configs that define them. This information is descriptive, but not an answer key. The agent writes its own notes from that inventory preflight.md) and can @-read those configs whenever it wants more. In our codebase, the inventory is a “CI validation manifest,” which tells the agent what will be graded and where the grading logic lives, before it starts guessing from vibes.
Fix loops drop to zero. Green PRs go to 100%.
This piece starts there. Same AFK Snake game build. Same seven tasks. Same two cadences, now with the sneak peek on.
Per-task-push: a pipeline after every task. Seven tasks, seven trips.
Single-push: finish the stack, clear practice run, push once at the end.
How often you push is the lever under test. First you have to be equipped to push green.
A linter is a linter. Compute is compute, whether it runs on a laptop, in a Chunk sidecar microbuild, or in a cloud job financed with CI credits.
There is no real reason to run the same deterministic check on localhost, again on the sidecar, and again on the outer-loop CI pipeline, as if three identical stamps make the code more correct.
That stack is a relic of human by-hand engineering. A person in flow forgets to run the test suite, pushes red, and we paper over forgetfulness by re-running the universe on every layer. Coding agents do not forget the same way. You can (and should) instruct them to clear inner-loop checks before they spend a single outer-loop CI credit.
In this calibration we moved inner-loop checks fully onto the sidecar and left thick outer-loop CI as the honest final test. Slimming true duplicates on the outer-loop surface is later work. The principle does not wait though: do not triple-pay for the same answer.
Results
Headline: once sneak peek made 100% green likely, a single end-of-run push cut estimated CI credits from ~81 to ~14.
Per-task-push: 7 pipelines. ~81.4 estimated CI credits.
Single-push: 1 pipeline. ~14.0 estimated credits.
About 5 to 6x fewer CI credits on the single-push run.
Wall-clock stayed in the 50 to 60 minute band either way (55.5 vs 56.7). LLM dollars stayed in the $15 to $17 band (17.15 vs 15.73). Tokens still track agent work. The CI credit collapse comes from the push cadence, not a cheaper model.
That bargain only holds when a sneak peek plus inner-loop checks make a 100% green PR likely. If you pile up unproven work and trigger the outer-loop pipeline once cold, you have not saved anything. You have postponed finding out you are red. When that one pipeline fails, you still pay the fix loop, and a retry can pick up new last-mile surprises.
Earn one take. Then trigger outer-loop CI once.
TL;DR
Elite engineering teams do not win by loving rework. They win by needing less of it.
Think of agent-era validation as a continuum. Inner loop to outer loop, hybrid on purpose. Each check earns its place.
Deterministic checks live inward: cheap, early, once.
World-shaped risk lives outward: policy, last-mile, flaky integrations, the CVE that did not exist at 9am. You name it.
Place each check where its information is unique. Everything else is just another duplicate cost for the same answer.
Outer-loop CI should still exist. It is where the world gets a vote. It should not be a museum of jobs you already passed in identical form on the previous two layers of validation.
At AFK scale, the inheritance path looks like this:
Make preventable reds disappear (push a /green PR in one take).
Keep remaining retries cheap (use the
--failure-reportflag).Put deterministic checks on the inner loop once. Push to outer-loop CI as often as your green rate deserves.
Once 100% green is something you can count on, pushing only once at the end of the run is an obvious CI credit win.
Bake that into your agent setup. Low MER should not be a hero dashboard you inspect after the damage. It should be the default the agent loop was engineered to produce.
Rework should be reserved for unknown failures from the real world. Preventable failures should be totally eliminated.