What this video shows
Korlam draws on Uber's SubmitQueue and his work at Gitar, now part of Sonar. A busy repository cannot safely serialize every change for days, but merging individually green pull requests can still break the combined main branch. Merge queues test likely combinations and remove failing changes before they enter the trunk. Coding agents increase the arrival rate, which puts more pressure on build latency, repair loops, review, and approvals.
The talk recommends incremental builds, caching, sharding, parallel checks, durable failure context, risk-based policies, and audit records tied to the tested commit. Product demonstrations and reported latency figures come from the speaker's systems, so teams should measure their own queue time, retries, escaped failures, and review load. Learnetto recommends reducing change size and work in progress before allowing automation to approve low-risk paths.
Use GitHub's merge queue documentation to ensure required checks run against the latest target branch and queued changes. Apply Google's small change guidance before adding infrastructure to process oversized agent pull requests faster.
What you will learn
- Measure elapsed time from proposed change to accepted change, including failed builds, repairs, review, and approval.
- Use incremental builds, caching, sharding, and parallel checks to shorten trustworthy feedback.
- Test queued changes against the target branch and earlier queued work before merge.
- Store approval reasons and audit evidence against the exact tested commit, outside the agent's editable session.
How to apply this safely
- Record queue time, build time, retry count, review time, override rate, and escaped failures for a representative week.
- Reduce change size and concurrent work, then optimize the slowest required check with caching or safe parallelism.
- Configure merge-group checks and verify that two conflicting green pull requests cannot both enter main.
- Define low, medium, and high-risk paths with named owners, required evidence, and durable override records.
Important limitations
- The volume and latency examples come from the speaker's prior and current systems. They do not establish the same gains for another repository or CI provider.
- Risk-based automation can misclassify a sensitive change. Teams still need protected paths, qualified reviewers, independent logs, and incident review.
- Faster CI does not correct weak tests or mistaken requirements. Reviewers must still inspect whether the checks represent user and business behavior.
Sources to check
- Managing a merge queue GitHub's current behavior and CI configuration for merge groups.
- Small changes Google's engineering guidance for focused, testable, reviewable changes.
Continue learning on Learnetto
Review AI-generated code
Use a six-pass workflow for agent pull requests before merge.
Best coding-agent courses
Learn planning, tool use, testing, and review in real repositories.
AI evals guide
Design behavioral and end-to-end checks for AI systems.