When the agent codes in seconds, CI becomes the slow neighbour
Priya Nair
Last week I caught myself doing something embarrassing. I asked an agent to scaffold a small handler, watched it return a tidy diff in roughly the time it takes to refill a glass of water, and then I sat there waiting on pull-request CI to tell me a brace was in the wrong place. The author of that code was faster than the reviewer of that code by two orders of magnitude, and the reviewer was a YAML file I had been quietly proud of.
DevOps.com ran an opinion piece this week titled "AI Coding Agents Are Pulling CI Feedback Into the Inner Loop", and it named the thing I had been refusing to name. The piece frames CI/CD the way we built it: humans in the inner loop, pipelines in the outer one. Agents generate code in seconds. Waiting for pull-request-stage CI to handle validation, tests, code review and standards checks no longer keeps pace with the author.
I wanted to push back on that. I cannot.
The split that used to make sense
The inner loop and the outer loop were a sensible deal. You typed, you ran a few things locally, the gate that everyone agreed on lived in CI where the environment was a known quantity. Running every check on every keystroke was unbearable, so we deferred the deep work to a pull request. The pull request became the seam where async machinery did the heavy lifting while the author moved on to something else.
That deal assumed the author was a person who took minutes to write a function. Strip out that assumption and the seam stops holding. The author now produces a coherent diff while you are still composing the prompt, and the heavy lifting of CI is suddenly the part of the loop you can see, second by second.
What "moving in" actually looks like
The honest version of pulling checks into the inner loop is not glamorous. It looks like running lint on the agent's diff before the agent declares itself done. It looks like the unit tests for the files the diff touched firing while the next prompt is being typed. It looks like a policy check telling the agent "this dependency is not on our allowlist" before you spend a round trip on it. Static analysis. SCA. The stuff that used to live in jobs you watched a status indicator for.
That work has to happen somewhere the agent can read the result and react. Otherwise the agent ships five iterations of the same broken pattern because nothing in the loop is telling it to stop.
The rough edge I keep getting stuck on
CI earned its trust by being hermetic. A fresh container, pinned versions, a known cache. If you take those checks out of CI and run them inside the agent's session on a developer laptop, you get the problem CI was invented to solve. "It passed for me." "It linted on my branch." The agent loop has to inherit the hermeticity the pipeline had. Otherwise you are not shortening the loop, you are hiding the noise inside it.
There is a second cost nobody loves to talk about. Every check you pull in costs latency in the inner loop. If lint, tests and a policy engine each take a couple of seconds, the agent's quick turn is no longer quick. Some of that is fine. Some of it will quietly motivate engineers to disable the slow checks locally, just to keep the agent feeling responsive, and now your floor is lower than the one CI was holding.
Where I land on it
I am with the piece. Waiting on pull-request-stage CI to surface a brace problem in agent-authored code is a workflow I cannot defend on a Tuesday afternoon. Move the cheap, deterministic checks in. Lint. Unit tests for touched files. The license check that already runs in under a second. Let the agent see the result and try again before it asks for human attention.
Keep the expensive, environment-sensitive checks where they have always belonged. Integration tests with real services. Build provenance. The SCA scan that wants a fresh container and a stable mirror. The outer loop is not going away. It is going to become the layer that confirms what the inner loop already believes.
What I am watching next
Two things. First, whether the tools that already live in the inner loop (formatters, language servers, pre-commit) get a serious agent-readable mode, with structured output the agent can parse instead of a wall of stderr. The signal needs to be machine-shaped now, because the consumer is. Second, what happens to the CI job that is, in practice, "wait for lint". A lot of pipelines have one of those. When it goes, the rest of the pipeline gets to be about the things only CI can do, and that is the version of this story I want to read in six months.
Source: DevOps.com (devops.com)