Gautam Korlam: CI for a Stream of Agent Changes (#AI4SDLC)

An agent fixes the code in a minute, then waits ten minutes for CI. A check fails, and another round begins. After the third attempt, someone opens the review and asks for one more edit. A familiar engineering merry-go-round that faster coding only spins harder :)

That is the subject of the 19-minute talk Rebuilding CI for AI-Scale Commit Volume by Gautam Korlam, Gitar’s co-founder — Gitar is now part of Sonar, where Gautam is now a principal engineer. His argument: agent-generated changes run into the capacity limits of builds, checks and approvals. The mechanics of those delays are what make this interesting.

Green PRs can break the shared branch.

Korlam describes Uber’s SubmitQueue: a queue that tests likely combinations of changes in advance. Individual PRs passing does not establish their compatibility. The way I read it, a green check always needs a qualification: which combination of code did it test?

Every repair attempt pays for CI again.

The speaker offers two telling figures:

• at least 13% of PRs on his platform had a required CI check fail;
• Gitar’s team reduced roughly ten-minute CI to under a minute for warm incremental steps through caching, less unnecessary invalidation and sharding. That claim does not cover cold builds.

These are the speaker’s own figures. Alongside run duration, I would measure the number of passes needed before a change is accepted. Three quick edits can mean three full builds and three waits. That gives each additional agent attempt a tangible cost.

Review needs ways to shed load, too.

Korlam proposes automating the first pass and acceptance of qualifying routine changes, while routing sensitive ones to a human. A change’s author must not approve their own work.

There is a concrete example, too: tests were parallelized with nextest, but a shared database lacked the necessary safeguards against interference. According to Korlam, Gitar caught and fixed the problem before merge. An attempt to speed up CI nearly introduced flaky tests.

What interests me most here is how risk is determined. A dependency update can alter a service’s behavior; an internal tool change can affect releases across the company. I would like to see a mistaken automatic approval and how the policy changed afterward. I would also count the work an AI reviewer creates: someone has to assess every finding, even when it turns out to be nonsense.

The grounds for a merge need to outlive CI logs.

Toward the end, Korlam discusses retaining the tested commit, report, independent approval and reasons for exceptions.

This part is particularly useful. Six months later, you want to reconstruct why a particular failure was allowed through and who made that decision. The branch name may already point to different code. I would preserve that context with the change immediately: once the logs are gone, reconstructing the history will be too late.

The talk continues the theme of my discussions of CI/CD and delivery speed and Scion: a growing flow of changes forces us to rethink the entire pipeline. Here the focus is the path from a proposed edit to accepted code.

The talk also includes a Gitar demonstration, so these examples are too little to establish the product’s effectiveness across teams. I would take away a question for my own team: how much time and repeated work does one accepted change cost, including repairs, review findings and exceptions?

#AI4SDLC #DevOps #DevTools #Engineering #Metrics