Gautam Korlam is a co-founder of Gitar, the AI code review and validation company acquired by Sonar in May 2026, and a principal engineer at Sonar. His work spans build systems, test reliability and automated code review, addressing the steps that determine whether a proposed change is ready to merge.
From Android engineering to developer infrastructure
Gautam joined Uber in 2014 as an Android engineer and became a founding engineer on its mobile platform team. His responsibilities expanded into developer infrastructure, and he became a principal engineer on the Developer Platform team. In his conversation with The Pragmatic Engineer, he describes a product approach to platform engineering: internal developers are customers, and improvements to their tools need measurement and feedback.
One contribution was his development and maintenance work on OkBuck, a Gradle plugin that generates the configuration needed to build Gradle projects with Buck. This bridge let teams adopt Buck without manually maintaining a second set of build definitions. Gautam joined after Piasy created the project, improved it alongside his Uber colleagues, and helped sustain its maintenance before its transfer to Uber. Piasy's early project history records those collaborative contributions.
Gautam also co-authored an investigation of flaky Java tests. Consolidating repositories exposed tests to concurrency and shared resources they had not previously encountered: a test could pass locally but fail when another test occupied the same hard-coded network port. The team's response combined historical test analysis, isolation of unreliable tests, automated reproduction and static checks to prevent known failure patterns from returning. Making failures reproducible helped developers distinguish defects in their changes from problems in the tests themselves.
His work on Uber's SubmitQueue addressed another source of uncertainty: changes that pass separately can fail together. As he explains in Rebuilding CI for AI-Scale Commit Volume, a merge queue tests combinations of changes before they reach the main branch. Coding agents increase the pressure on that system by producing pull requests faster than queues designed around human arrival rates can process them. Gautam's argument extends his earlier infrastructure work: faster implementation needs faster feedback, repair and approval to translate into delivered changes.
Building Gitar around review and repair
Gautam co-founded Gitar and served as CTO, working with fellow developer-infrastructure veterans including Ali-Reza Adl-Tabatabai. His account of adapting language models to Uber's codebase distinguishes generating a plausible implementation from establishing that it fits an existing production system. Gitar brought automation into the pull-request workflow to review changes, diagnose CI failures and apply fixes.
When Sonar acquired Gitar in May 2026, Gautam and Ali-Reza joined to lead its continued development. The combination brought Gitar's contextual review and repair work together with Sonar's static analysis and verification capabilities.
Decisions that make automated review actionable
Gautam's approach gives models room to propose findings and repairs while assigning specific decisions to software and independent checks. His interview about Gitar's design explains several distinctions:
Review findings and verdicts: Models propose findings; code computes review verdicts and checks whether the offending code remains in the diff. This keeps the status of a review tied to the code under review as it changes.
Bounded repair attempts: Automated repair needs limits and failure diagnosis. A failed check may reflect the patch, a flaky test or an infrastructure problem. Gautam describes limiting repair attempts and requiring independent validation, so an agent does not keep rewriting code to silence an unrelated failure.
Feedback developers will keep reading: In his description of Gitar's review interface, Gautam favors one updating summary, selective inline findings, collapsed resolutions and memory of dismissed issues. Those choices reduce repeated comments and keep attention on unresolved findings.
His CI and merge-policy argument also distinguishes passing tests from permission to merge. Policies should reflect the risk of a change, separate authorship from approval and attach approval to the tested commit. Overrides need recorded reasons that survive the agent's session. These are concrete requirements for increasing automated change volume without losing track of what was tested, who approved it and why an exception was allowed.
Gautam Korlam follows the bottleneck from merge queues to CI repairs, review and approval—and explains why faster feedback needs a lasting record of what was tested and who accepted it.
Merge safety depends on testing combinations of incoming changes; individually passing PRs can still break trunk together.
CI latency multiplies across repair attempts. Gitar reports reducing roughly ten-minute CI to under a minute for warmed incremental steps through reuse, less invalidation and sharding.
