CI isn't a gate anymore - it's a verify tool the agent calls

CI’s role has fundamentally changed, and it’s a good time to own shares in whoever runs your build infrastructure.

There’s a reason CI stands for “Continuous Integration.” The old shape: you push to CI once your tests pass locally, and it checks that your change integrates cleanly with everyone else’s parallel work - and, incidentally, that it actually works on an environment representing production rather than just on your machine, with its personal spaghetti of a dozen language runtime versions. That’s roughly one CI build per branch.

The new shape

That world is gone. CI is now a verify tool that a coding agent calls, repeatedly, as part of its own working loop - not a single checkpoint at the end of a human’s work.

We’re seeing this in real usage data: as teams get more sophisticated with agentic coding, two things happen together. The number of parallel branches goes up, which is expected - more agents, more concurrent work. But the number of CI pushes per branch also goes up, which is the less obvious part.

Why pushes-per-branch is climbing

The reason is that giving an agent good, holistic guardrails increasingly means your test suite can’t run fast enough locally to serve as the loop’s feedback mechanism on its own:

• agents need more guardrails than we’ve ever needed for human-only work, so test suites are getting bigger
• end-to-end and integration tests keep growing in number, and those are inherently slower than unit tests

So the emerging pattern is smoke-test or changed-files-only verification locally, with a push to CI for full verification - but that push is now a step inside the agentic loop, not a final human action once the human is satisfied. The agent watches CI, reads the failures, and iterates against them the same way it iterates against a local test run, just with higher latency.

What that means for infrastructure

A few consequences follow directly from CI becoming a loop-internal call instead of an end-of-work gate:

• you’re actively trying to balance the test suite between what runs locally (fast, narrow) and what runs in CI (slow, comprehensive) - and that balance point moves as your test suite grows
• parallelisation of CI itself becomes much more important, because you’re paying its latency far more often per unit of work
• fail-fast matters more than ever, since a slow failure is now blocking an agent’s loop, not just a human’s afternoon

I also suspect this pushes more orgs toward heavier build systems like Buck2 or Bazel - which, for anyone who remembers two-hour builds of large C codebases, has a certain grim familiarity to it. That’s a lot of complexity to take on, and probably more than most teams should bite off right now. But if CI pushes per branch keep climbing the way we’re seeing in the data, “how fast can a single CI run complete” stops being a nice-to-have metric and starts being a hard constraint on how fast your agents can actually work.