Coding agents move the bottleneck from writing code to CI, review, repair, and approval queues built for human change rates.
2
Incremental builds, caching, sharding, and earlier checks can reduce the cost of repeated repair loops.
3
Approval must depend on change risk and the exact tested commit, with durable records for overrides, authorship, and compliance decisions.
Summary
Gautam Korlam argues that coding agents expose limits in software delivery systems that were designed around human commit rates. At Uber, thousands of daily changes and long builds led him to work on SubmitQueue, which tested likely combinations of commits before allowing them onto the main branch. Agent-generated pull requests create a similar pressure at a higher rate, filling CI and review queues and increasing repair work. Korlam recommends faster incremental CI, caching, sharding, parallel work, and moving suitable checks earlier. Review should also be automated for low-risk changes, with humans handling exceptions. Passing CI is not enough for regulated systems. Teams need to know who or what created a change, which commit was tested, who approved it, why failures or overrides were accepted, and whether the final merged commit still matches the tested one. The talk treats generated code volume as useful only when the full path to an accepted change can keep up.
Merge queues test combinations to keep the main branch usable
At Uber, a large monorepo received thousands of changes each day while builds could run for a long time. Serializing merges could take up to 20 days to get everything green, while merging changes independently left the main branch broken when combinations conflicted. SubmitQueue tested likely combinations in parallel, removed changes that were predicted to break the queue, and allowed a change onto the trunk only after the relevant combination passed. Korlam says the system is still running at Uber.
Agent commit rates overload queues designed for people
CI and review queues were built for developers who generated changes a few times an hour. Agents can create several pull requests in a day and may submit them at the same time, while software factories and background workflows add more activity. Korlam says the commit rate at his company increased tenfold in about three years, and the number of pull requests reviewed by Gitar had been growing by about 25% month over month. The result is pressure on CI and review rather than a faster path to production.
Repair loops make every failed check more expensive
Agent-generated changes can trigger rebuilds, flaky integration tests, and failures that are hard to reproduce locally. Korlam reports that 13% of pull requests on his platform had a recorded CI failure. Each failure can require an agent or developer to read logs, find the cause, make a fix, push another commit, and repeat the cycle. Human review often waits for CI to turn green, so repair also delays review. Durable failure context can stop agents from rediscovering the same problem on every iteration.
Faster feedback comes from incremental work and earlier checks
Korlam recommends removing or moving expensive checks when they do not need to block the fastest CI path. Parallel execution, sharding, caching, and reducing compiler invalidation can make repeated checks much cheaper. His team used Rust for its build system, cached outputs, reduced compilation churn, and sharded work. They brought incremental CI from about ten minutes to less than a minute after the cold CI was warmed up. Checks that can run earlier are cheaper to fix because the agent has more local context.
A green build does not remove the review bottleneck. Korlam says much of the time from pull request to production at Uber was spent in review, and automated reviewers can create more findings that must be addressed. He describes a flow in which an agent reviews and fixes issues first, while humans review what remains. Lower-risk work such as documentation changes, dependency bumps that do not break APIs, security patches, and some internal tooling changes can qualify for automatic approval or merge when the configured policies allow it.
Approval rules should follow the risk of the change
Korlam gives different approval expectations for different areas of a codebase. Documentation and dependency changes may be approved automatically, while changes involving sensitive payment systems may need a human approver. The agent that authored a change must not approve its own work, and a new change that falls outside the existing criteria should be escalated. He connects this to zero-trust approval and to policy enforcement beyond the fact that code compiles.
The tested commit must be tied to the approval record
A passing CI result can become misleading after a force-push, because the branch may point to a different commit than the one that was tested. Korlam says teams should record the commit trusted by CI and save the test report rather than only a status. They should also record the coding agent, originating session, person or workflow that started it, how findings were resolved, the independent approver, and the reason for every override. The merged code must retain this evidence and must not be a small untested change on top.
