Gautam Korlam, Principal Engineer bij Sonar – Interviewreeks

Gautam Korlam, Principal Engineer bij Sonar, is een ervaren software‑engineer en technologieleider wiens carrière zich heeft gericht op ontwikkelaarsinfrastructuur, codekwaliteit, automatisering en AI‑ondersteunde software‑ontwikkeling. Voordat hij bij Sonar kwam, richtte hij Gitar op en was hij CTO, waarbij hij een AI‑native platform bouwde dat is ontworpen om code‑review te automatiseren, continue‑integratie‑fouten (CI) te diagnosticeren, oorzaken te identificeren en oplossingen te genereren. Sonar nam Gitar over in mei 2026, waarbij Korlam en het Gitar‑team zich bij het bedrijf voegden om de technologie verder te ontwikkelen als onderdeel van Sonar’s bredere code‑verificatieplatform. Voor Gitar werkte Korlam bijna tien jaar bij Uber, waar hij opstapte van oprichter‑engineer van het mobiele platformteam tot Principal Engineer. Tijdens zijn dienstverband hielp hij bij het bouwen en opschalen van Uber’s gecentraliseerde ontwikkelaarsinfrastructuur, leidde hij grote monorepo‑ en buildsysteem‑initiatieven, ontwikkelde hij remote ontwikkelomgevingen en CI/CD‑tools, en experimenteerde hij met open‑source grote taalmodellen zoals StarCoder, OctoCoder en Code Llama om AI‑ondersteunde codering binnen Uber’s codebase te verbeteren. Zijn eerdere ervaring omvat engineering‑rollen bij Lookout en onderzoek aan UC Santa Barbara, evenals stages bij Microsoft en Oracle.

Sonar is een softwarebedrijf dat zich richt op code‑verificatie, geautomatiseerde code‑review, codekwaliteit en applicatiebeveiliging. Het vlaggenschip SonarQube‑platform analyseert door ontwikkelaars geschreven en AI‑gegenereerde code om bugs, kwetsbaarheden, onderhoudsproblemen en andere kwaliteitsissues te identificeren voordat ze in productie komen, met oplossingen die variëren van cloud‑ tot zelf‑gehoste en geïntegreerde ontwikkelomgeving‑workflows. Sonar meldt dat haar technologie door meer dan 7 miljoen ontwikkelaars en 22 000 klanten wordt gebruikt en dagelijks meer dan 750 miljard regels code analyseert. De overname van Gitar breidde deze aanpak uit naar AI‑native code‑review en remediatie, door de verificatie‑engine van SonarQube te combineren met agentische tools die code kunnen beoordelen, CI‑fouten kunnen onderzoeken en oplossingen kunnen voorstellen of toepassen nu software‑ontwikkeling steeds meer door AI wordt gedreven.

Je carrière heeft je van het bouwen van Uber’s mobiele en ontwikkelaarsinfrastructuur naar het trainen van open‑source grote taalmodellen op haar codebase gebracht, voordat je Gitar mede‑oprichtte en bij Sonar kwam na de overname. Hoe hebben die ervaringen je overtuiging gevormd dat code genereren slechts een deel van de uitdaging is, en dat het betrouwbaar valideren ervan misschien het moeilijkere probleem is?

Bij Uber werkte ik aan de delen van het systeem die bepalen of iemand iets kan uitrollen: de monorepo, de build, de CI‑wachtrij, de test‑suite. Het makkelijker maken om wijzigingen te produceren legt alle druk op die infrastructuur. Je krijgt meer services die op onvoorspelbare manieren met elkaar interageren, en meer engineers die moeten uitvinden of hun wijziging veilig kan worden gemerged.

Later werkte ik aan het trainen van modellen op onze eigen codebase, waar de asymmetrie duidelijk werd. Een model kan snel een plausibele implementatie produceren. Aantonen dat die implementatie past in een live productiesysteem, de conventies volgt die dit team daadwerkelijk gebruikt, en niets breekt dat twee services verwijderd is, kost veel meer tijd, en het grootste deel van dat werk viel op mensen. Gitar is hieruit voortgekomen, en het sluit aan bij wat Sonar al meer dan zeventien jaar doet aan de analysekant.

Je hebt betoogd dat AI‑code‑review deterministische analyse moet aanvullen in plaats van vervangen. Welke soorten problemen worden het beste geïdentificeerd via herhaalbare, regel‑gebaseerde analyse, en waar kan AI mogelijkheden bieden die traditionele technieken niet kunnen?

Regel‑gebaseerde analyse is het juiste instrument wanneer de eigenschap beslisbaar is vanuit de code zelf. Besmette invoer die een sink bereikt, een null‑dereferentie op een pad dat iemand over het hoofd zag, een hard‑gecodeerde inloggegevens, een afhankelijkheid met een bekende CVE, een import die een laag overschrijdt die het niet zou moeten. Je krijgt elke keer hetzelfde antwoord en je kunt wijzen op de reden waarom het afgevuurd is, daarom hoort handhaving op die laag.

Wat regels niet dekken, is intentie. Geen parser zal je vertellen dat een gebruikersgerichte string ambigu zal zijn voor wie die vertaalt, of dat een wijziging beweert een ticket te sluiten terwijl slechts de helft van wat het ticket vroeg wordt geïmplementeerd, of dat een nieuwe retry‑loop botst met de manier waarop de rest van de service back‑pressure afhandelt. Een model dat de diff leest samen met het gekoppelde issue en de volledige codebase‑context zal die zaken naar voren brengen, en ze moeten verschijnen als bevindingen die een persoon controleert in plaats van als uitspraken.

AI‑systemen kunnen bedrijfslogica, ontwikkelaar‑intenties en architecturale afwegingen beoordelen, maar hun conclusies zijn probabilistisch. Hoe kunnen ontwikkelingsteams profiteren van dit contextuele redeneren zonder de output van een AI‑reviewer als per definitie juist te beschouwen?

AI‑review verdient zijn plaats bij de problemen die conventionele controles missen: logische fouten, gedrag dat niet overeenkomt met de aangegeven intentie, een wijziging die op zichzelf goed lijkt maar voor dit specifieke systeem onjuist is. Die conclusies zijn probabilistisch, dus ze behoren tot de invoer voor een beslissing in plaats van de beslissing zelf te vormen. Teams handhaven die grens door de deterministische controles vóór de merge te behouden, wat betekent: geautomatiseerde tests, CI‑validatie, beveiligingsscans, beleidscontroles en een mens die eigenaar is van de wijziging. AI kan oplossingen voorstellen, of ze implementeren binnen de guardrails die het team opstelt, zolang die wijzigingen dezelfde verificatie doorstaan als alles wat een persoon schreef en er geen verkorting is omdat ze machinaal zijn gegenereerd.

We hanteren dezelfde grens in onze eigen implementatie. Het model stelt bevindingen voor, en het review‑verdict wordt in code berekend op basis van de status van die bevindingen. Oplossing werkt op dezelfde manier. Wanneer de code achter een bevinding uit de diff verdwijnt, is dat een deterministische controle tegen de geparseerde diff, en het model mag niet ongedaan maken wat de diff al heeft opgelost.

De algemene versie hiervan is om de probabilistische laag de taken te geven waarbij fouten herstelbaar zijn, de toestandsmachine deterministisch te houden en de verantwoordelijkheid bij het team te laten. Vertrouwen wordt verdiend door bewijs dat iemand kan inspecteren en controleren en dat zich bij elke uitvoering hetzelfde gedraagt.

Sonar combineert context‑bewuste pull‑request‑reviews met deterministische analyse en quality gates. Hoe ziet een effectief meerlagig verificatieproces eruit, en hoe moeten de verschillende lagen samenwerken zonder werk te dupliceren of ontwikkelaars te overweldigen met bevindingen?

Deterministische analyse en quality gates dragen de zaken die niet onderhandelbaar zijn, en waarop een merge blokkeert. Contextuele review neemt de beoordelingsbeslissingen over of een wijziging doet wat het beweert, of het past in de codebase, en of een bepaald risico de aandacht van een persoon waard is.

Een muur van bevindingen wordt ongeveer even vaak genegeerd als geen bevindingen. We dedupliceren over reviewers voordat iets de auteur bereikt, laten kandidaten die niet geverifieerd kunnen worden vallen en richten ons op bevindingen met een sterk signaal. Aan de regelkant beslist een predicaat of een regel van toepassing is op de huidige diff vóórdat een model wordt uitgevoerd, zodat de meeste regels niets kosten bij de meeste wijzigingen. Alles verschijnt in de pull‑request die de ontwikkelaar al open heeft.

Naarmate code‑agents meer code en pull‑requests produceren, kan software‑review en -verificatie dan de nieuwe knelpunt worden? Welke delen van het review‑proces moeten geautomatiseerd worden, en welke beslissingen moeten bij ervaren engineers blijven?

Review en verificatie zijn al het knelpunt geworden. In feite heeft onze 2026 State of Code Developer Survey aangetoond dat teams ongeveer een kwart van de werkweek besteden aan het controleren en repareren van AI‑output. Daarmee is het geen verrassing dat slechts 48 % van de developers altijd AI‑gegenereerde code controleert voordat ze deze committen, hoewel de meerderheid (96 %) niet volledig vertrouwt dat deze functioneel correct is.

Het werk dat de moeite waard is om te automatiseren is mechanisch en onaangenaam: een CI‑fout terugbrengen tot een oorzaak zodat niemand vierduizend logregels moet lezen, bepalen of een bevinding nog van toepassing is na een rebase, een fout reproduceren, de voor de hand liggende oplossing schrijven. Engineers moeten de intentie, het ontwerp en de beoordeling van hoeveel bewijs voldoende is voor een specifieke wijziging behouden. Wanneer een senior engineer een avond besteedt aan het lezen van logs om uit te zoeken welke van negen fouten relevant is, is dat triage in plaats van oordeel, en precies het soort werk dat we van hen moeten afnemen.

AI‑code‑review‑systemen kunnen problemen identificeren, oplossingen voorstellen en die wijzigingen valideren tegen de continue‑integratie‑pipeline. Hoe voorkom je dat een autonoom remediatiesysteem regressies introduceert of te smal optimaliseert voor een geslaagde build in plaats van de bredere kwaliteit van de software?

Het belangrijkste is weigeren om groen te beschouwen als acceptatie‑criterium, aangezien een geslaagde build alleen aangeeft dat de bestaande tests niet gefaald hebben.

De meeste beperkingen die we op onze eigen remediatie leggen, hebben te maken met scope. Gitar repareert CI die gebroken was, en controleert dat de commit vóór zijn eigen push groen was voordat het verantwoordelijkheid claimt voor iets. Het stopt na twee opvolgende commits in plaats van door te gaan met een rode build. Wanneer de fout niets met de wijziging te maken heeft, een flaky test of een infrastructuur‑glitch, gaat die de retry‑route in plaats van de fix‑route, omdat “de test laten stoppen met falen” het doel is dat je het minst wilt dat een capabele agent nastreeft.

Daarna moet de wijziging een laag passeren die Gitar niet controleert. SonarQube evalueert het resultaat op eigen voorwaarden, de quality gate is waar de merge van afhankelijk is, en het team bezit dat beleid. We controleren de wijziging ook tegen het issue dat ze beweert te implementeren, met vereiste‑extractie gescheiden van het voltooiings‑oordeel, zodat een vereiste die stilletjes van het ticket is verdwenen niet als geïmplementeerd kan terugkomen.

Effectieve AI‑code‑review hangt af van het begrijpen van de conventies, afhankelijkheden, architectuur en het doel van een voorgestelde wijziging van een repository. Welke context heeft een AI‑reviewer nodig om nuttige beslissingen te nemen, en hoe kunnen organisaties die context accuraat houden terwijl hun systemen evolueren?

Het heeft voldoende context nodig om te redeneren als een ervaren reviewer, niet alleen genoeg om de diff te lezen. Dat omvat het doel van de wijziging, relevante codepaden en type‑informatie, afhankelijkheden, testgedrag, repository‑conventies en de architecturale grenzen die het team verwacht dat de wijziging respecteert.

De context moet ook bij de code leven. Houd regels en review‑richtlijnen versie‑beheerd in de repository, werk ze bij wanneer services of conventies veranderen, en maak eigenaarschap duidelijk voor architecturale en beleidsbeslissingen. Anders kan een AI‑reviewer een individueel plausibele suggestie produceren die in strijd is met hoe het bredere systeem daadwerkelijk werkt.

Deterministische analyse levert consistente en controleerbare resultaten, terwijl review op basis van grote taalmodellen kan variëren tussen runs. Hoe moeten ondernemingen AI‑gegenereerde bevindingen documenteren, reproduceren en beheren in gereguleerde of beveiligingsgevoelige omgevingen?

De audit‑trail moet de beoordeelde wijziging, de AI‑bevinding, de genomen beslissing en het onafhankelijke bewijs dat is gebruikt om het resultaat te valideren, tonen. Teams kunnen AI gebruiken om review en remediatie te versnellen, terwijl handhaving en goedkeuringsbeslissingen verankerd blijven in gedefinieerde beleidsregels en menselijke verantwoordelijkheid.

Welke metrics moeten engineering‑leiders gebruiken om te bepalen of AI‑code‑review daadwerkelijk de software‑ontwikkeling verbetert? Moeten ze prioriteit geven aan review‑tijd, ontsnapte defecten, false‑positive‑percentages, continue‑integratie‑fouten, technische schuld, ontwikkelaar‑vertrouwen of een andere maatstaf?

Begin met uitkomsten, niet met het aantal commentaren dat een AI‑systeem produceert. Ik zou de tijd meten van pull‑request tot merge, de tijd die wordt besteed aan het diagnosticeren van CI‑fouten, het percentage waarbij oplossingen bij de eerste validatie‑poging slagen, en hoe vaak issues ontsnappen naar latere fasen of productie.

Bekijk vervolgens kwaliteitsindicatoren zoals false‑positive‑ en afwijzingspercentages, heropende issues, regressies gekoppeld aan recent gemergde wijzigingen, en feedback van developers over of bevindingen uitvoerbaar zijn. De juiste mix van metrics varieert per team, maar de vraag blijft consistent: verminderen we herwerk en wachttijd voor reviews zonder de lat voor veilige, betrouwbare software te verlagen?

Kijkend naar de toekomst, verwacht je dat software‑ontwikkeling een continue lus wordt waarin agents code genereren, reviewen, testen en repareren onder deterministische guardrails? Hoe zullen in die omgeving de verantwoordelijkheden en vereiste vaardigheden van menselijke software‑engineers veranderen?

Die lus bestaat al, en teams nemen het meestal in een vaste volgorde over: eerst detectie, daarna remediatie, vervolgens goedkeuring onder voorwaarden die ze vastleggen, daarna merge. Niemand springt direct naar de laatste stap, en het bewijs dat hen voortstuwt is hun eigen codebase in plaats van een benchmark. Merge is de stap die ik het meest interessant vind, omdat de frequentie van conflicten stijgt met de commit‑doorvoer, en doorvoer is wat al dit alles vergroot.

De vaardigheden die in waarde toenemen, liggen rond de lus in plaats van erin. Precisie over het probleem en de beperkingen is belangrijker wanneer een agent je beschrijving letterlijk neemt. Ook het bepalen welke bewijzen voldoende zijn om een wijziging door te laten, wat vroeger in de hoofden van mensen als gewoonte zat en nu als beleid moet worden vastgelegd zodat automatisering het kan toepassen. De rest is systeemontwerp: bepalen wat geautomatiseerd werk mag aanraken, iets laten controleren dat de agent niet beheert, en het toerekenbaar houden wanneer het fout gaat. Engineers zullen minder tijd besteden aan het produceren van de implementatie en meer tijd aan het bepalen wat er moet bestaan en wat als bewijs telt dat het werkt.

Bedankt voor het geweldige interview, lezers die meer willen weten, kunnen Sonar bezoeken.