Rebuilding CI for AI-Scale Commit Volume — Gautam Korlam, SonarSource
A talk on why coding agents shift the bottleneck from code generation to CI, merge queues, review, and approvals, and how to redesign those systems around speed, automated repair, policy enforcement, and auditable records.
Coding agents move the bottleneck from writing code to landing it
Gautam Korlam starts from nearly a decade of build and merge infrastructure work at Uber on a monorepo, followed by his work at Gitar, now part of Sonar. His central claim is that agents make code generation cheap enough that the systems around it (CI, merge queues, review, and approvals) become the constraint. Those systems have to be redesigned for agent-scale commit volume, and the problem is sharpest in highly regulated industries such as banking, where speed and auditability have to coexist.
Why merge queues exist
At Uber, one giant monorepo received thousands of changes a day, and builds were long-running. Serializing every merge to protect the main branch could take up to 20 days to get everything green. Letting everyone merge freely kept main red, because changes that were green individually could break once combined. The answer was SubmitQueue, which tests the likely combinations of incoming changes in parallel, predicts which change will break the trunk, ejects it back to its author, and lands only combinations that pass. It still runs at Uber. Korlam notes that hosted merge queues from GitHub and other code hosts now exist, but at the time nothing comparable was available.
Queues built for human speed
The CI and review queues were designed around human arrival rates, when a developer produced changes a few times an hour. Agents change that arithmetic. Developers and background agents open many PRs a day, often at the same moment, and automated workflows trigger on their own. The queues pile up and the whole software factory slows down because CI and review are over capacity.
Korlam cites Gitar’s own growth as evidence. Commit volume has grown roughly tenfold in about three years with a team that is still small, and the number of PRs Gitar reviews grows about 25 percent month over month. He says GitHub has published similar growth figures, and he expects every team, including banks moving through their AI adoption, to hit the same wall.
The core technical issue is that each PR can pass CI in isolation and still break the trunk once merged with others. The queue therefore has to test changes against each other, and CI and code architecture have to become smarter about how changes combine.
The software factory and its repair loops
In a software factory, agents write code from specs while humans own the specs and the review. Every stage of the line built for human speed slows under that load. Build and test suffer from rebuilds after compile breaks, slow integration tests, and flaky tests that do not reproduce locally. Retries on complex builds can take hours. Review and approval then become the new queue. Many reviewers are rubber-stamping PRs because they cannot keep up, and they lean on weaker signals to get through.
Repair is a major cost. At least 13 percent of PRs on Gitar’s platform had a recorded CI failure. Each failure starts a round trip: a developer or agent reads the logs, identifies the root cause, pushes a fix, and waits for CI again. Human reviewers usually wait for green CI before they look, so review also queues up behind repair.
Records that expire
CI logs expire, so the evidence of what was actually checked disappears, leaving only an approval stamp. Korlam argues for durable records, including agent trajectories, outcomes after each push, saved test reports, and how each finding was resolved. These records become the source of truth for audit and compliance. Without them, a force push can leave a green status pointing at code that no longer exists.
Making CI and review faster
Korlam’s first recommendation is to make CI fast. That means removing expensive checks from the critical path, moving them post-merge where appropriate, and using parallelism, sharding, and caching. Moving checks left, earlier in the pipeline or into local agent work, is much cheaper. Agents that gather context locally can often fix issues faster than a remote loop can.
Review should also run in multiple passes. A fast AI first pass gives developers quick signal, and deeper human review is reserved for higher-risk changes. Low-risk changes may not need a human at all.
He gives a concrete example from a Rust build system where CI took about 10 minutes. The team cached outputs aggressively and reduced compiler churn with fixes that made compilation more cacheable and less often invalidated. Sharding and removing overhead followed. Incremental CI on a warm cache dropped to under a minute. The lesson is the difference between rebuilding everything and testing only the affected work.
In his experience, most of the P90 time from PR to production was spent in review and extra testing rather than in CI. AI reviewers add their own findings, which someone must still address, either through an agent on CI or locally, so that humans only see what remains.
He also describes a case where Gitar caught a test-isolation problem. The team had parallelized tests with nextest and introduced a shared database. Under heavy CI load, cross-contamination made tests flaky. Gitar flagged the issue before merge, suggested the fix, committed it, and credited the engineer as co-author.
Policy beyond passing CI
Regulation is central to his argument. He recounts Uber losing its license to operate in London after a feature flag change let drivers onboard without the proper checks. Afterward Uber required lineage for every change that affected London, showing which controls applied. That process won back the license. Passing CI does not mean a change complies with HIPAA or similar frameworks. Agents will not know those rules unless enforcement happens at the merge boundary, and the enforcement itself has to be recorded.
Risk-based approval and separation of duties
Policies should match the risk of the change. Routine, lower-risk changes such as documentation, dependency bumps that do not break APIs, security patches, and some internal tooling can be auto-approved and auto-merged. Gitar supports this out of the box and also accepts custom rules written in plain English. Changes that touch sensitive areas, such as payments, need a human approver on top.
Authorship must be separated from approval. The agent that wrote a change cannot approve it, and neither can the engineer who prompted it, because that would violate zero trust. When a change does not meet the criteria, it escalates to another approver. Korlam says adoption of auto-approval and auto-merge is growing quickly, including at large organizations with more than 100,000 developers.
Tested commits, overrides, and audit evidence
He illustrates the audit problem with two pipelines. One failed and one passed. The passing one recorded why a known failure mode occurred and that another person had approved it, so it satisfies the checks. Without that record, a passing run is only blind trust in the agent.
The records he suggests keeping include which coding agent made the PR, where the PR originated, which session started it, and whether a human or an automated workflow triggered it. They also include the commit on which CI was trusted, saved test reports rather than bare status, and how each finding was resolved: dismissed, followed up, or fixed. Approval should come from someone other than the bot and the prompting engineer. Overrides and skipped checks, such as skipped coverage, need explicit reasons. Approval must be tied to the exact commit that was tested, so nothing unreviewed slips in afterward.
Takeaway
Korlam’s closing argument is that faster CI and automated review remove bottlenecks, reduce test load, and free humans to focus on exceptions. Every approval and merge should be recorded, since that history shows how the factory improves over time. The transferable lesson is to measure the whole path from proposed change to accepted change, including recovery and accountability, before treating more generated code as more delivered value. He cautions that the volume and latency figures come from his own systems and are not general productivity guarantees. The product demonstrations show how this coordination can be automated.