Seconds-to-Minutes Feedback: CI/CD as a Feedback Channel

Linters catch syntax and type issues in milliseconds, but they cannot answer deeper questions: does the code build successfully? Have module dependencies broken? Do integration tests pass? These questions require actually running build and test processes, pushing feedback delay from milliseconds up to seconds and minutes.

In traditional development, the CI/CD pipeline's role is deployment: code is written, it goes through the pipeline, it gets deployed. In Agent-driven development, its primary role shifts: the pipeline is first and foremost a feedback channel, and only secondarily a deployment tool. After each commit, the pipeline tells the Agent: did the build succeed or fail? Which tests broke? Are integration points intact? These signals determine the Agent's next action.

This means pipeline design priorities need to change. Traditional pipelines optimise for completeness and safety: run all tests, pass all checks, get approval, then deploy. Agent-driven pipelines must optimise first for speed: the Agent needs to know as quickly as possible whether its code has problems. If a full CI run takes 40 minutes, the Agent either sits idle for 40 minutes or continues writing code based on unverified assumptions. Neither is ideal.

The solution is not to reduce CI coverage, but to layer it. The first layer is a fast feedback layer: run only the builds and tests directly related to the current change, returning results within tens of seconds. The second layer is a full verification layer: run all tests and integration checks, proceeding asynchronously. The Agent works with the fast feedback from the first layer, and if the second layer reveals problems, it interrupts and fixes them.

In multi-Agent parallel scenarios, CI design has another critical requirement: traceability. When three Agents work on three branches simultaneously, CI results must clearly associate with a specific Agent and a specific task. "Build failed" is not enough. You need "Agent B, working on task #42, modified payments/handler.go, causing integration test TestPaymentFlow to fail." Without this level of traceability, you face a pile of unattributable red marks.

Integration frequency also needs to increase. Traditional teams might integrate once a day. With multiple Agents working in parallel, each Agent should trigger integration upon completing an atomic task. The cost of fixing a deviation is proportional to how long it has existed: two Agents each working for a day before integrating might discover conflicts requiring a full day's rollback. Integrating every hour limits the worst case to one hour.

Pipeline stability is equally critical. If CI has flaky tests (tests that fail randomly), Agents cannot distinguish "my code has a problem" from "CI itself is unstable". For humans, a flaky test is a minor annoyance — just rerun it. For Agents, a flaky test is a false signal: they may spend significant tokens "fixing" a non-existent problem, or conversely, learn to ignore test failures because "it was like this last time and a rerun fixed it." Eliminating flaky tests is not a nice-to-have; it is the baseline for platform reliability.