# The Feedback Loop Is Moving Out of CI > Source: > Published: 2026-09-03 16:26:18+00:00 # The Feedback Loop Is Moving Out of CI Paul Hammant pointed out that Google separated verification from merge coordination more than fifteen years ago. He was right. What actually changed is who owns the feedback-and-repair loop — and that shifts what CI needs to be. *A follow-up to '**AI Broke the Assumptions Behind CI**,' after **Paul Hammant's** response.* Paul Hammant sent me a response that reframed the entire argument. What I was describing — separating pre-integration verification from merge coordination, having infrastructure privately answer whether a change is safe before it lands — is the same pattern Google built with TAP, Piper, and Critique over a decade ago. He's right, which forced me to reconsider what I was actually claiming was new. My first reaction was that Google's system was too specialised to be a useful comparison. Then I realised that was exactly his point. The architecture existed. The question was what actually changed when the system producing the code can also own the loop from implementation through failure and repair. ## What Google actually built Google's monorepo handled 40,000 commits per day by early 2015: roughly 16,000 from engineers and 24,000 from automated systems. [Potvin and Levenberg documented it in CACM in 2016](https://www.researchgate.net/publication/304529269_Why_Google_stores_billions_of_lines_of_code_in_a_single_repository?ref=stack72.dev). The number people skip past is the automated rate. Bots were already committing more changes than humans before anyone was talking about AI agents. The infrastructure that made this possible was built over years. Piper handled version control at scale. Blaze (open-sourced as Bazel) tracked the dependency graph precisely enough that TAP, the Test Automation Platform, could determine the affected tests for any change and reject what broke. Critique handled code review and submission coordination. Changes were reviewed and passed presubmit verification before they landed on trunk. The separation I wrote about in the CI post was already there. As Hammant put it: "Nobody argued about whether a change was safe; the infrastructure answered it privately for the would-be build breaker." This is the [third style of trunk-based development](https://trunkbaseddevelopment.com/styles/?ref=stack72.dev) that Hammant documents: the coupled patch review system. Changes are marshalled in an external system before trunk integration, guaranteeing quality before arrival. But look at who did what. TAP was a service. It ran tests on remote infrastructure, selected via the dependency graph, and reported results. Critique surfaced those results and enforced that review criteria were met before submission. The developer authored the change, submitted it for verification, read the results in Critique, and — when something failed — returned to their workspace, interpreted the failure, fixed the implementation, and resubmitted. Google had a presubmit gate (a fast subset of affected tests, averaging about eleven minutes) and comprehensive postsubmit testing with build cops and rollback as the backstop. In both phases, verification was an infrastructure service. The developer consumed it. The feedback-and-repair loop crossed system boundaries and still depended on human interpretation at each iteration. ## The infrastructure caught up Google's internal systems required enormous investment: dedicated teams, years of development, tightly integrated tooling. But the architecture was not unique to Google for long. Over the following decade, open-source tools and cloud infrastructure commoditised many of the same components. Gerrit (open-sourced by Google in 2008) implemented the coupled review model with pre-submit gated verification. Phabricator brought Facebook's version of the same pattern to the open-source community in 2010. Zuul gave OpenStack project-level gating in 2012. TeamCity and TFS had offered pre-tested commits and gated check-in since roughly 2007-2010. CI became a SaaS product. Containers made hermetic test environments trivial. Bazel brought Google-style dependency-aware test selection to anyone who adopted it. By the early 2020s, merge queues had become a standard repository feature. The PR-plus-CI workflow became dominant not because alternatives were unavailable, but because it was the simplest workflow in the ecosystem most teams had already adopted. Across these systems, the workflow still left the same part to the human. Infrastructure reported failures. A developer interpreted them, fixed the code, and resubmitted. Narrow automated repair existed — auto-formatters, linter auto-fix, domain-specific tools like Facebook's SapFix and Getafix — but general-purpose failure interpretation and repair remained human work. ## Who owns the loop The architectural change is not that verification infrastructure became cheaper. That already happened. The change is that the system producing the code can now own the verification-and-repair control loop. In every prior model, the loop required a human at the interpretation step. Infrastructure reported a failure. The developer re-entered the problem, understood what went wrong, fixed it, and resubmitted. In the agent model, the code-producing system owns the full loop. It implements the change. It invokes verification: tests, lint, type checks, builds, review steps. The tests might execute locally or on a remote cluster; that's an implementation detail. What matters is that the same system that produced the implementation reads the failure output, determines what went wrong, modifies the implementation, and retries. The loop repeats until the required checks pass. No handoff to a human between verification and repair. No human re-entering the problem to interpret a failure report. The distinction is not execution locality — where the tests run. It's control-loop ownership — who owns implement, verify, interpret, repair, retry. An agent invoking a remote test cluster while controlling the iteration is owning the loop. A developer running the same tests locally owns the loop too — but manually. The change is that the loop itself can now be executed by the code-producing system without requiring human interpretation between iterations. Narrow automated repair already existed: SapFix, Getafix, auto-formatters. These could repair constrained categories of failures using domain-specific techniques. An LLM agent can interpret failures across a general-purpose codebase, relate test expectations to implementation behaviour, and make correspondingly general code changes. The result is that the general-purpose feedback-and-repair loop becomes automatable and enforceable as part of the system rather than dependent on individual developer discipline. Good developers always ran tests locally and fixed failures before pushing. That was a practice. In this model, it becomes a defined stage that is required on every change, governed by versioned rules, and produces evidence of what happened. ## What CI becomes CI does not disappear. Its centre of gravity shifts. When the code-producing system owns the verification-and-repair loop, CI no longer needs to be the primary place where a change discovers whether it works. It can focus on what only an independent system can do: enforce policy, validate evidence, coordinate concurrent changes, and provide a trust boundary the authoring agent does not control. That means validating that the attestation contains the required verification evidence: checking its completeness, freshness, and that the configuration checksums match the files at the verified commit. It means detecting when trunk has moved since verification ran, invalidating stale results. It means rerunning checks where independent execution is required: security-sensitive tests, privileged environments, secret-dependent integrations, anything the authoring agent should not have access to. It means producing release artifacts on trusted infrastructure the developer doesn't control. And it means enforcing merge ordering to prevent semantic conflicts between concurrent changes. Once verification occurs outside the merge system's trust domain, the merge boundary needs an explicit interface for consuming evidence of what happened. An attestation — structured evidence of what was verified, under what configuration, with what results — is one implementation of that interface. Attestation and provenance patterns predate this architecture; in-toto, SLSA, and supply-chain frameworks have formalised the concept. The specific role here is bridging the gap between the agent-owned verification loop and the independently controlled coordination layer. When CI ran the tests itself, it could trust its own results implicitly. When verification runs in the authoring environment, CI needs a way to consume evidence without blindly trusting the author. CI can independently verify which configuration should have governed the run and that the attestation references the expected configuration. The attestation includes checksums of review prompts, workflow definitions, and configuration files at the verified commit, and CI can hash those files and confirm they match. What CI cannot verify from the attestation alone is whether the authoring environment actually honoured that configuration during execution. Result integrity — did the tests actually produce the claimed results — is not provable from the attestation alone. These are distinct gaps, and the CI post was explicit about both because pretending they don't exist helps nobody. For controls where result integrity requires a higher level of assurance, running them on independent infrastructure is the right call. The model does not require everything to run in the authoring environment. It requires that verification run wherever its trust requirements make sense, and that the results flow forward as structured evidence rather than being re-executed at the merge gate by default. ## Practices follow constraints Hammant's feedback connects to something I've [written about before](https://stack72.dev/practices-have-a-half-life-architecture-shouldnt/) — practices have a half-life. The PR-plus-CI pipeline was a good fit for a world where general-purpose pre-integration verification required either Google-scale infrastructure or the operational expertise to assemble it from open-source components. Agents changed who owns the iteration from failure to fix: the general-purpose interpretation and repair that previously required a human developer at each step. Google proved fifteen years ago that separating verification from coordination scales. Over the next decade, open-source tooling and cloud infrastructure made the same capabilities broadly accessible. Agents made the feedback-and-repair loop executable by software.