Gautam Korlam, Principal Engineer at Sonar, is a veteran software engineer and technology leader whose career has focused on developer infrastructure, code quality, automation, and AI-assisted software development. Before joining Sonar, he co-founded Gitar and served as CTO, building an AI-native platform designed to automate code review, diagnose continuous integration (CI) failures, identify root causes, and generate fixes. Sonar acquired Gitar in May 2026, with Korlam and the Gitar team joining the company to continue developing the technology as part of Sonar’s broader code verification platform. Prior to Gitar, Korlam spent nearly a decade at Uber, progressing from a founding engineer on its mobile platform team to Principal Engineer. During his tenure, he helped build and scale Uber’s centralized developer infrastructure, led major monorepo and build-system initiatives, developed remote developer environments and CI/CD tooling, and experimented with open-source large language models such as StarCoder, OctoCoder, and Code Llama to improve AI-assisted coding within Uber’s codebase. His earlier experience includes engineering roles at Lookout and research work at UC Santa Barbara, as well as internships with Microsoft and Oracle.
Sonar is a software company focused on code verification, automated code review, code quality, and application security. Its flagship SonarQube platform analyzes developer-written and AI-generated code to identify bugs, vulnerabilities, maintainability problems, and other quality issues before they reach production, with offerings spanning cloud, self-managed, and integrated development environment workflows. Sonar says its technology is used by more than 7 million developers and 22,000 customers and analyzes more than 750 billion lines of code each day. The acquisition of Gitar expanded this approach into AI-native code review and remediation, combining SonarQube’s verification engine with agentic tools capable of reviewing code, investigating CI failures, and proposing or applying fixes as software development becomes increasingly AI-driven.
Your career has taken you from building Uber’s mobile and developer infrastructure to training open source large language models on its codebase, before co-founding Gitar and joining Sonar following its acquisition. How did those experiences shape your belief that generating code is only part of the challenge, and that reliably validating it may be the harder problem?
At Uber I worked on the parts of the system that decide whether anyone ships: the monorepo, the build, the CI queue, the test suite. Making it easier to produce changes pushes all the pressure onto that machinery. You get more services interacting in ways nobody predicted, and more engineers waiting to find out whether their change is safe to merge.
Later I worked on training models on our own codebase, which is where the asymmetry got obvious. A model could produce a plausible implementation quickly. Showing that the implementation fit a live production system, followed the conventions this team actually used, and did not break something two services away took much longer, and most of that work landed on people. Gitar came out of that, and it lines up with what Sonar has been doing from the analysis side for over seventeen years.
You have argued that AI code review should complement deterministic analysis rather than replace it. What types of problems are best identified through repeatable, rule-based analysis, and where can AI provide capabilities that traditional techniques cannot?
Rule-based analysis is the right tool when the property is decidable from the code itself. Tainted input reaching a sink, a null dereference on a path someone missed, a hardcoded credential, a dependency with a known CVE, an import that crosses a layer it should not. You get the same answer on every run and you can point at the reason it fired, which is why enforcement belongs on that layer.
What rules don’t cover is intent. No parser is going to tell you that a user-facing string will be ambiguous to whoever translates it, or that a change claims to close a ticket while implementing half of what the ticket asked for, or that a new retry loop fights the way the rest of the service handles backpressure. A model that reads the diff along with the linked issue and the full codebase context will raise those, and they should arrive as findings a person checks rather than as verdicts.
AI systems can assess business logic, developer intent and architectural tradeoffs, but their conclusions are probabilistic. How can development teams benefit from this contextual reasoning without treating an AI reviewer’s output as inherently correct?
AI review earns its place on the problems conventional checks miss: logic errors, behavior that does not match the stated intent, a change that reads fine on its own and is wrong for this particular system. Those conclusions are probabilistic, so they belong in the input to a decision rather than standing as the decision. Teams hold that boundary by keeping the deterministic controls in front of the merge, which means automated tests, CI validation, security scanning, policy checks, and a human who owns the change. AI can propose fixes, or implement them inside guardrails the team sets, as long as those changes clear the same verification as anything a person wrote and get no shortcut for having been machine-generated.
We draw the same boundary inside our own implementation. The model proposes findings, and the review verdict is computed in code from the state of those findings. Resolution works the same way. When the code behind a finding is gone from the diff, that is a deterministic check against the parsed diff, and the model is not allowed to un-resolve what the diff has already fixed.
The general version of this is to hand the probabilistic layer the jobs where being wrong is recoverable, keep the state machine deterministic, and leave accountability with the team. What earns trust is evidence someone can inspect and control that behave the same way on every run.
Sonar is combining context-aware pull request reviews with deterministic analysis and quality gates. What does an effective multilayered verification process look like, and how should the different layers interact without duplicating work or overwhelming developers with findings?
Deterministic analysis and quality gates carry the things that are not up for negotiation, and they are what a merge blocks on. Contextual review takes the judgment calls about whether a change does what it claims, whether it fits the codebase, and whether a given risk is worth a person’s attention.
A wall of findings gets ignored at roughly the same rate as no findings at all. We dedupe across reviewers before anything reaches the author, drop candidates it cannot verify and focus on high signal findings. On the rules side, a predicate decides whether a rule applies to the current diff before any model runs, so most rules cost nothing on most changes. All of it surfaces on the pull request the developer already has open.
As coding agents produce more code and pull requests, could software review and verification become the new bottleneck? Which parts of the review process should be automated, and which decisions should remain with experienced engineers?
Review and verification have already become the bottleneck. In fact, our 2026 State of Code Developer Survey found that teams report spending roughly a quarter of the work week checking and fixing AI output. With this, it’s no surprise that only 48% of developers always check AI-generated code before committing it, even though the majority (96%) do not fully trust that it’s functionally correct.
The work worth automating is mechanical and unpleasant: grouping a CI failure down to a root cause so nobody reads four thousand log lines, deciding whether a finding still applies after a rebase, reproducing a failure, writing the obvious fix. Engineers should keep intent, design, and the call on how much evidence is enough for a particular change. When a senior engineer spends an evening reading logs to work out which of nine failures matters, that is triage rather than judgment, and it is exactly the kind of work we should take off them.
AI code review systems can identify problems, propose fixes and validate those changes against the continuous integration pipeline. How do you prevent an autonomous remediation system from introducing regressions or optimizing narrowly for a successful build rather than the broader quality of the software?
The main thing is refusing to treat green as the acceptance criterion, since a passing build only tells you that the tests which exist did not fail.
Most of the constraints we put on our own remediation are about scope. Gitar fixes CI that broke, and it checks that the commit before its own push was green before claiming responsibility for anything. It stops after two follow-up commits rather than grinding away at a red build. When the failure has nothing to do with the change, a flaky test or an infra blip, that goes down the retry path instead of the fix path, because “make the test stop failing” is the objective you least want a capable agent pursuing.
After that the change has to clear a layer Gitar does not control. SonarQube evaluates the result on its own terms, the quality gate is what the merge depends on, and the team owns that policy. We also check the change against the issue it claims to implement, with requirement extraction kept separate from the completion judgment, so a requirement that quietly left the ticket cannot come back as implemented.
Effective AI code review depends on understanding a repository’s conventions, dependencies, architecture and the purpose of a proposed change. What context does an AI reviewer need to make useful decisions, and how can organizations keep that context accurate as their systems evolve?
It needs enough context to reason like an experienced reviewer, not just enough to read the diff. That includes the purpose of the change, relevant code paths and type information, dependencies, test behavior, repository conventions, and the architectural boundaries the team expects the change to respect.
The context also has to live with the code. Keep rules and review guidance versioned in the repository, update them when services or conventions change, and make ownership clear for architectural and policy decisions. Otherwise, an AI reviewer can produce an individually plausible suggestion that conflicts with how the broader system actually works.
Deterministic analysis produces consistent and auditable results, while large language model-based review can vary between runs. How should enterprises document, reproduce and govern AI-generated findings in regulated or security-sensitive environments?
The audit trail should show the change reviewed, the AI finding, the decision taken, and the independent evidence used to validate the outcome. Teams can use AI to accelerate review and remediation, while keeping enforcement and approval decisions anchored in defined policies and human accountability.
What metrics should engineering leaders use to determine whether AI code review is actually improving software development? Should they prioritize review time, escaped defects, false-positive rates, continuous integration failures, technical debt, developer trust or another measure?
Start with outcomes, not the number of comments an AI system produces. I would measure time from pull request to merge, time spent diagnosing CI failures, the rate at which fixes pass on the first validation attempt, and how often issues escape into later stages or production.
Then watch quality signals like false-positive and dismissal rates, reopened issues, regressions linked to recently merged changes, and developer feedback on whether findings are actionable. The right metric mix varies by team, but the question is consistent: are we reducing rework and review waiting time without lowering the bar for safe, reliable software?
Looking ahead, do you expect software development to become a continuous loop in which agents generate, review, test and repair code under deterministic guardrails? In that environment, how will the responsibilities and required skills of human software engineers change?
That loop exists already, and teams tend to adopt it in a fixed order: detection first, then remediation, then approval under conditions they write down, then merge. Nobody jumps straight to the last step, and the evidence that moves them along is their own codebase rather than a benchmark. Merge is the step I find most interesting, because conflict frequency rises with commit throughput, and throughput is what all of this increases.
The skills that gain value sit around the loop rather than inside it. Being precise about the problem and its constraints matters more when an agent takes your description literally. So does deciding what evidence is sufficient to let a change through, which used to live in people’s heads as a habit and now has to be written down as policy something automated can apply. The rest is systems design: bounding what automated work can touch, having something the agent does not control check the result, and keeping it attributable when it goes wrong. Engineers will spend less time producing the implementation and more time deciding what should exist and what would count as proof that it works.
Thank you for the great interview, readers who wish to learn more should visit Sonar.
Credit: Source link
