Gautam Korlam told AI Engineer his small team now ships 10 times as many commits as three years ago with the same headcount, and Korlam said PRs reviewed by QAR are still climbing 25% month over month. That pace breaks the central queues that test, review and merge code.
The queues were built for humans.
Korlam, co-founder and CTO of QAR and now principal engineer at Sonar after its acquisition, drew on a decade running build and merge infra at Uber. The monorepo saw thousands of changes a day with long builds, Korlam said, and serial merges would have taken 20 days to stay green while skipping checks left main red. His answer was SubmitCube, a system that tests likely combinations of incoming commits in parallel, predicts which PR will break, pulls it from the queue for a fix, and only lets combinations that pass together onto trunk. Korlam said it still runs at Uber today.
That design assumed a few human PRs per hour. Korlam said agents now open several PRs a day per developer and fire background workflows at once, so CI and review pile up. QAR tried to move faster by caching Rust build outputs, reducing compiler churn and sharding, Korlam said, cutting incremental CI from about 10 minutes to under a minute once warm. Review remains the longer wait, Korlam said, with P90 time to production dominated by review at Uber and now again. QAR's response is layered review and policy, where Korlam said routine docs or dependency bumps can auto-approve, sensitive paths like payments still need a human, and an agent cannot approve its own change.
Korlam said 13% of PRs on QAR's platform showed at least one recorded CI failure, each requiring a round trip to read logs, fix and push again, and Korlam said humans rarely review until CI is green so failures serialize the line. He also argued green CI does not mean compliant, since reruns, flaky tests and expired logs erase what was checked. His fix is to keep a durable record on the PR itself: which agent opened it, what session and trigger created it, the exact commit where CI was trusted with full test reports, how each finding was resolved, who approved it if not the author, and why any override was allowed. The data does not show how many of those 13% failures were flaky versus real defects, nor the cost of reruns. A breakout of flake rate and retry time would change the read on whether speed or stability is the bigger tax.
