Gautam Korlam, Principal Engineer på Sonar – Intervjuserie

Gautam Korlam, Principal Engineer på Sonar, är en veteran inom mjukvaruutveckling och teknikledning vars karriär har fokuserat på utvecklarinfrastruktur, kodkvalitet, automatisering och AI‑assisterad mjukvaruutveckling. Innan han gick med i Sonar var han medgrundare till Gitar och tjänstgjorde som CTO, där han byggde en AI‑native plattform avsedd att automatisera kodgranskning, diagnostisera fel i kontinuerlig integration (CI), identifiera grundorsaker och generera korrigeringar. Sonar förvärvade Gitar i maj 2026, och Korlam samt Gitar‑teamet gick med i företaget för att fortsätta utveckla teknologin som en del av Sonars bredare kodverifieringsplattform. Före Gitar tillbringade Korlam nästan ett decennium på Uber, där han steg från en grundande ingenjör i mobilplattformsteamet till Principal Engineer. Under sin tid hjälpte han till att bygga och skala Ub ers centraliserade utvecklarinfrastruktur, ledde stora monorepo‑ och byggsysteminitiativ, utvecklade fjärrutvecklingsmiljöer och CI/CD‑verktyg samt experimenterade med öppen källkod‑stora språkmodeller som StarCoder, OctoCoder och Code Llama för att förbättra AI‑assisterad kodning i Ub ers kodbas. Hans tidigare erfarenhet inkluderar ingenjörsroller på Lookout och forskningsarbete vid UC Santa Barbara, samt praktikplatser hos Microsoft och Oracle.

Sonar är ett mjukvaruföretag som fokuserar på kodverifiering, automatiserad kodgranskning, kodkvalitet och applikationssäkerhet. Deras flaggskeppsplattform SonarQube analyserar kod skriven av utvecklare och AI‑genererad kod för att identifiera buggar, sårbarheter, underhållsproblem och andra kvalitetsbrister innan de når produktion, med erbjudanden som täcker moln, självhanterade och integrerade utvecklingsmiljöarbetsflöden. Sonar uppger att deras teknik används av mer än 7 miljoner utvecklare och 22 000 kunder och analyserar över 750 miljarder kodrader varje dag. Förvärvet av Gitar utökade detta tillvägagångssätt till AI‑native kodgranskning och åtgärdande, genom att kombinera SonarQubes verifieringsmotor med agentbaserade verktyg som kan granska kod, undersöka CI‑fel och föreslå eller tillämpa korrigeringar i en allt mer AI‑driven mjukvaruutveckling.

Din karriär har tagit dig från att bygga Ub ers mobil‑ och utvecklarinfrastruktur till att träna öppna stora språkmodeller på deras kodbas, innan du medgrundade Gitar och gick med i Sonar efter förvärvet. Hur har de erfarenheterna format din uppfattning om att generera kod bara är en del av utmaningen, och att på ett pålitligt sätt validera den kan vara det svårare problemet?

På Uber arbetade jag med de delar av systemet som bestämmer om någon får leverera: monorepot, bygget, CI‑kön, testsviten. Att göra det enklare att producera förändringar lägger all press på den maskinen. Man får fler tjänster som interagerar på oförutsedda sätt, och fler ingenjörer som väntar på att få veta om deras förändring är säker att slå ihop.

Senare arbetade jag med att träna modeller på vår egen kodbas, och där blev asymmetrin tydlig. En modell kan snabbt producera en plausibel implementation. Att visa att implementationen passar i ett levande produktionssystem, följer de konventioner teamet faktiskt använder och inte bryter något två tjänster bort, tog mycket längre tid, och det mesta av det arbetet föll på människor. Gitar föddes ur det, och det stämmer överens med vad Sonar har gjort på analys‑sidan i över sjutton år.

Du har argumenterat för att AI‑kodgranskning bör komplettera deterministisk analys snarare än ersätta den. Vilka typer av problem identifieras bäst genom repeterbar, regelbaserad analys, och var kan AI erbjuda förmågor som traditionella tekniker inte kan?

Regelbaserad analys är rätt verktyg när egenskapen är beslutsbar från själva koden. Förorenad indata som når en sink, en null‑dereferens på en väg någon missat, en hårdkodad credential, ett beroende med en känd CVE, en import som korsar ett lager den inte bör. Du får samma svar vid varje körning och kan peka på varför regeln triggas, vilket är varför verkställning hör hemma på den nivån.

Det som regler inte täcker är avsikt. Ingen parser kommer att säga att en användar‑synlig sträng blir tvetydig för den som översätter den, eller att en förändring påstår sig stänga ett ärende men bara implementerar hälften av vad ärendet begärde, eller att en ny återförsöks‑loop krockar med hur resten av tjänsten hanterar back‑pressure. En modell som läser diffen tillsammans med det länkade ärendet och hela kodbasens kontext kommer att lyfta sådana frågor, och de bör dyka upp som fynd som en person kontrollerar snarare än som slutgiltiga domar.

AI‑system kan bedöma affärslogik, utvecklaravsikt och arkitekturtrade‑offs, men deras slutsatser är probabilistiska. Hur kan utvecklingsteam dra nytta av detta kontextuella resonemang utan att behandla en AI‑gransknings output som per definition korrekt?

AI‑granskning förtjänar sin plats på de problem som konventionella kontroller missar: logiska fel, beteende som inte stämmer med den uttalade avsikten, en förändring som ser bra ut i sig men är fel för just detta system. Dessa slutsatser är probabilistiska, så de hör till som input till ett beslut snarare än själva beslutet. Team håller den gränsen genom att ha de deterministiska kontrollerna framför merge‑steget, vilket innebär automatiserade tester, CI‑validering, säkerhetsskanning, policy‑kontroller och en människa som äger förändringen. AI kan föreslå korrigeringar, eller implementera dem inom de skyddsmekanismer teamet sätter, så länge dessa förändringar klarar samma verifiering som allt som en person skrivit och inte får någon genväg för att de är maskin‑genererade.

Vi drar samma gräns i vår egen implementation. Modellen föreslår fynd, och granskningsverdictet beräknas i kod utifrån statusen för dessa fynd. Lösningen fungerar på samma sätt. När koden bakom ett fynd försvinner från diffen är det en deterministisk kontroll mot den parsade diffen, och modellen får inte “un‑resolve” det som diffen redan har åtgärdat.

Den generella versionen är att låta det probabilistiska lagret ta de jobb där fel är återhämtningsbara, hålla tillståndsmaskinen deterministisk, och låta ansvarigheten ligga hos teamet. Vad som förtjänar förtroende är bevis som någon kan inspektera och kontrollera så att de beter sig likadant vid varje körning.

Sonar kombinerar kontext‑medveten pull‑request‑granskning med deterministisk analys och kvalitetsgrindar. Hur ser en effektiv flerskikts‑verifieringsprocess ut, och hur ska de olika lagren interagera utan att duplicera arbete eller övervälda utvecklare med för många fynd?

Deterministisk analys och kvalitetsgrindar bär de saker som inte är förhandlingsbara, och de är vad ett merge‑blockerar på. Kontextuell granskning tar de bedömningsfrågor som handlar om huruvida en förändring gör vad den påstår, om den passar in i kodbasen och om en given risk är värd en persons uppmärksamhet.

En vägg av fynd ignoreras i ungefär samma takt som ingen fynd alls. Vi deduplicerar över granskare innan något når författaren, slänger kandidater som den inte kan verifiera och fokuserar på högsignal‑fynd. På regel‑sidan bestämmer ett predikat om en regel gäller för den aktuella diffen innan någon modell körs, så de flesta regler kostar ingenting för de flesta förändringar. Allt detta visas i pull‑requesten som utvecklaren redan har öppen.

Allt eftersom kod‑agenter producerar mer kod och fler pull‑requests, kan mjukvarugranskning och verifiering bli den nya flaskhalsen? Vilka delar av granskningsprocessen bör automatiseras, och vilka beslut bör förbli hos erfarna ingenjörer?

Granskning och verifiering har redan blivit flaskhalsen. Faktum är att vår 2026 State of Code Developer Survey visade att team rapporterar att de spenderar ungefär en fjärdedel av arbetsveckan på att kontrollera och fixa AI‑output. Med detta är det inte förvånande att bara 48 % av utvecklarna alltid kontrollerar AI‑genererad kod innan de commitar, trots att majoriteten (96 %) inte fullt ut litar på att den är funktionellt korrekt.

Det arbete som är värt att automatisera är mekaniskt och otrevligt: gruppera ett CI‑fel ner till en grundorsak så ingen läser fyra tusen logglinjer, avgöra om ett fynd fortfarande gäller efter en rebase, reproducera ett fel, skriva den uppenbara korrigeringen. Ingenjörer bör behålla avsikt, design och beslutet om hur mycket bevis som räcker för en viss förändring. När en senior ingenjör spenderar en kväll på att läsa loggar för att avgöra vilken av nio fel som är viktig, är det triage snarare än bedömning, och det är exakt den typen av arbete vi bör avlasta dem från.

AI‑kodgranskningssystem kan identifiera problem, föreslå korrigeringar och validera dessa förändringar mot CI‑pipeline. Hur förhindrar du att ett autonomt åtgärdssystem introducerar regressioner eller optimerar för smal framgång i byggprocessen snarare än den bredare mjukvarukvaliteten?

Det viktigaste är att vägra betrakta ett grönt byggresultat som acceptanskriterium, eftersom ett lyckat bygge bara visar att de befintliga testerna inte misslyckades.

De flesta begränsningarna vi sätter på vår egen åtgärd handlar om omfattning. Gitar fixar CI som gick sönder, och den kontrollerar att committen före sin egen push var grön innan den påtar sig ansvar för något. Den stannar efter två efterföljande commits istället för att fortsätta på ett rött bygge. När felet inte har något med förändringen att göra – ett fluktuerande test eller ett infrastruktur‑glitch – går det ner på återförsök‑vägen snarare än på fix‑vägen, eftersom ”få testet att sluta misslyckas” är det mål du minst vill att en kapabel agent ska jaga.

Efter det måste förändringen klara ett lager som Gitar inte kontrollerar. SonarQube utvärderar resultatet på sina egna villkor, kvalitetsgrinden är vad merge‑steget beror på, och teamet äger den policyn. Vi kontrollerar också förändringen mot det ärende den påstår att implementera, med kravextraktion separerad från slutförandebedömningen, så ett krav som tyst lämnat ärendet inte kan återkomma som implementerat.

Effektiv AI‑kodgranskning beror på att förstå ett repositoriums konventioner, beroenden, arkitektur och syftet med en föreslagen förändring. Vilken kontext behöver en AI‑granskare för att fatta användbara beslut, och hur kan organisationer hålla den kontexten korrekt när deras system utvecklas?

Den måste ha tillräckligt med kontext för att resonera som en erfaren granskare, inte bara för att läsa diffen. Det inkluderar förändringens syfte, relevanta kodvägar och typinformation, beroenden, testbeteende, repositoriums konventioner och de arkitektoniska gränser som teamet förväntar sig att förändringen respekterar.

Kontexten måste också leva med koden. Håll regler och granskningsvägledning versionerade i repositoriet, uppdatera dem när tjänster eller konventioner förändras, och gör ägarskap tydligt för arkitektur‑ och policybeslut. Annars kan en AI‑granskare producera ett individuellt plausibelt förslag som står i konflikt med hur det bredare systemet faktiskt fungerar.

Deterministisk analys ger konsekventa och audit‑bara resultat, medan granskning baserad på stora språkmodeller kan variera mellan körningar. Hur bör företag dokumentera, reproducera och styra AI‑genererade fynd i reglerade eller säkerhetskänsliga miljöer?

Audit‑spåret bör visa den granskade förändringen, AI‑fyndet, det fattade beslutet och det oberoende bevis som använts för att validera resultatet. Team kan använda AI för att påskynda granskning och åtgärd, samtidigt som verkställning och godkännande hålls förankrade i definierade policyer och mänskligt ansvar.

Vilka nyckeltal bör tekniska ledare använda för att avgöra om AI‑kodgranskning faktiskt förbättrar mjukvaruutvecklingen? Ska de prioritera gransknings‑tid, undvikna fel, falska‑positiva‑frekvens, CI‑fel, teknisk skuld, utvecklar‑förtroende eller någon annan mätning?

Börja med resultat, inte antalet kommentarer ett AI‑system producerar. Jag skulle mäta tid från pull‑request till merge, tid som spenderas på att diagnostisera CI‑fel, andelen korrigeringar som går igenom på första valideringsförsöket, och hur ofta problem läcker in i senare steg eller i produktion.

Sedan följer kvalitetsindikatorer som falska‑positiva‑ och avvisningsfrekvenser, återöppnade ärenden, regressioner kopplade till nyligen mergade förändringar, samt utvecklarfeedback om huruvida fynd är handlingsbara. Den rätta kombinationen av mått varierar per team, men frågan är konstant: minskar vi omarbetning och väntetid i granskning utan att sänka ribban för säker, pålitlig mjukvara?

Ser du framåt att mjukvaruutveckling blir en kontinuerlig slinga där agenter genererar, granskar, testar och reparerar kod under deterministiska skyddsmekanismer? Hur kommer ansvarsområdena och de nödvändiga färdigheterna för mänskliga mjukvaruingenjörer att förändras i ett sådant scenario?

Den slingan finns redan, och team tenderar att anta den i en fast ordning: upptäckt först, sedan åtgärd, sedan godkännande under villkor de skriver ner, sedan merge. Ingen hoppar direkt till sista steget, och bevisen som driver dem framåt är deras egen kodbas snarare än ett benchmark. Merge är det steg jag finner mest intressant, eftersom konflikt‑frekvensen ökar med commit‑genomströmning, och genomströmning är vad allt detta ökar.

De färdigheter som får värde sitter runt slingan snarare än i den. Att vara exakt kring problemet och dess begränsningar blir viktigare när en agent tar din beskrivning bokstavligt. Detsamma gäller att bestämma vilken bevisning som är tillräcklig för att låta en förändring gå igenom, vilket tidigare levde i människors huvuden som en vana och nu måste skrivas ner som en policy som en automation kan tillämpa. Resten är systemdesign: avgränsa vad automatiserat arbete får röra, ha något som agenten inte kontrollerar för att kontrollera resultatet, och hålla det ansvarigt när det går fel. Ingenjörer kommer att spendera mindre tid på att producera implementationen och mer tid på att bestämma vad som bör finnas och vad som skulle räknas som bevis på att det fungerar.

Tack för den fantastiska intervjun, läsare som vill lära sig mer bör besöka Sonar. 

gent kontrollerar inte resultatet, och håller det ansvarigt när det går fel. Ingenjörer kommer att spendera mindre tid på att producera implementationen och mer tid på att bestämma vad som bör finnas och vad som skulle räknas som bevis på att det fungerar.