Gautam Korlam, hovedingeniør hos Sonar – Intervjuserie

Gautam Korlam, Principal Engineer at Sonar, er en erfaren programvareingeniør og teknologileder hvis karriere har fokusert på utviklerinfrastruktur, kodekvalitet, automatisering og AI‑assistert programvareutvikling. Før han begynte i Sonar, var han medstifter av Gitar og fungerte som CTO, og bygde en AI‑native plattform designet for å automatisere kodegjennomgang, diagnostisere feil i kontinuerlig integrasjon (CI), identifisere rotårsaker og generere rettelser. Sonar kjøpte opp Gitar i mai 2026, og Korlam og Gitar‑teamet ble med i selskapet for å fortsette utviklingen av teknologien som en del av Sonars bredere kodeverifiseringsplattform. Før Gitar tilbrakte Korlam nesten et tiår i Uber, der han gikk fra å være medgrunnlegger av mobilplattform‑teamet til Principal Engineer. I løpet av sin tid bidro han til å bygge og skalere Ub​ers sentraliserte utviklerinfrastruktur, ledet store monorepo‑ og byggsystem‑initiativer, utviklet fjernutviklingsmiljøer og CI/CD‑verktøy, og eksperimenterte med åpen‑kilde‑store språkmodeller som StarCoder, OctoCoder og Code Llama for å forbedre AI‑assistert koding i Ub​ers kodebase. Tidligere erfaring inkluderer ingeniørroller i Lookout og forskningsarbeid ved UC Santa Barbara, samt praksisplasser hos Microsoft og Oracle.

Sonar er et programvareselskap som fokuserer på kodeverifisering, automatisert kodegjennomgang, kodekvalitet og applikasjonssikkerhet. Deres flaggskip SonarQube‑plattform analyserer både kode skrevet av utviklere og AI‑generert kode for å identifisere feil, sårbarheter, vedlikeholdsmessige problemer og andre kvalitetsproblemer før de når produksjon, med tilbud som dekker sky, selv‑administrert og integrerte utviklingsmiljø‑arbeidsflyter. Sonar oppgir at teknologien deres brukes av mer enn 7 millioner utviklere og 22 000 kunder, og analyserer over 750 milliarder kodelinjer hver dag. Oppkjøpet av Gitar utvidet denne tilnærmingen til AI‑native kodegjennomgang og utbedring, ved å kombinere SonarQubes verifiseringsmotor med agent‑verktøy som kan gjennomgå kode, undersøke CI‑feil og foreslå eller anvende rettelser etter hvert som programvareutviklingen blir stadig mer AI‑drevet.

Din karriere har tatt deg fra å bygge Ub​ers mobil‑ og utviklerinfrastruktur til å trene åpne store språkmodeller på deres kodebase, før du medstiftet Gitar og ble med i Sonar etter oppkjøpet. Hvordan har disse erfaringene formet din tro på at det å generere kode bare er en del av utfordringen, og at pålitelig validering kan være det vanskeligere problemet?

Hos Uber jobbet jeg med de delene av systemet som bestemmer om noen får shippe: monorepoen, bygget, CI‑køen og testsettet. Å gjøre det enklere å levere endringer legger alt presset på denne maskinvaren. Man får flere tjenester som samhandler på uforutsigbare måter, og flere ingeniører som venter på å finne ut om endringen deres er trygg å slå sammen.

Senere jobbet jeg med å trene modeller på vår egen kodebase, og da ble asymmetrien tydelig. En modell kan raskt produsere en plausibel implementasjon. Å demonstrere at implementasjonen passer inn i et levende produksjonssystem, følger de konvensjonene teamet faktisk bruker, og ikke bryter noe to tjenester unna, tok mye lenger tid, og mesteparten av dette arbeidet havnet på folk. Gitar oppsto fra dette, og det samsvarer med det Sonar har gjort på analysesiden i over sytten år.

Du har argumentert for at AI‑kodegjennomgang bør komplementere deterministisk analyse i stedet for å erstatte den. Hvilke typer problemer identifiseres best gjennom repeterbar, regelbasert analyse, og hvor kan AI tilby evner som tradisjonelle teknikker ikke kan?

Regelbasert analyse er riktig verktøy når egenskapen er avgjørbar fra selve koden. Forurenset input som når en sink, en null‑dereferering på en sti noen overså, en hardkodet legitimasjon, en avhengighet med en kjent CVE, en import som krysser et lag den ikke skal. Du får samme svar ved hver kjøring og kan peke på årsaken til at den utløste, noe som gjør at håndheving hører hjemme på dette laget.

Det regler ikke dekker, er intensjon. Ingen parser vil fortelle deg at en bruker‑vendt streng vil være tvetydig for den som oversetter den, eller at en endring hevder å lukke en sak mens den kun implementerer halve det saken ba om, eller at en ny retry‑sløyfe strider mot hvordan resten av tjenesten håndterer back‑pressure. En modell som leser diffen sammen med den tilknyttede saken og hele kodebase‑konteksten vil påpeke dette, og de bør komme som funn en person sjekker i stedet for som dommer.

AI‑systemer kan vurdere forretningslogikk, utviklerintensjon og arkitektoniske avveininger, men deres konklusjoner er probabilistiske. Hvordan kan utviklingsteam dra nytte av denne kontekstuelle resonneringen uten å behandle en AI‑gjennomgangs resultat som iboende korrekt?

AI‑gjennomgang fortjener sin plass på problemene konvensjonelle sjekker går glipp av: logiske feil, oppførsel som ikke samsvarer med den uttalte intensjonen, en endring som ser grei ut alene, men er feil for akkurat dette systemet. Disse konklusjonene er probabilistiske, så de hører inn i input‑delen av en beslutning snarere enn å stå som selve beslutningen. Teamene opprettholder denne grensen ved å holde de deterministiske kontrollene foran sammenslåingen, noe som betyr automatiserte tester, CI‑validering, sikkerhetsskanning, policy‑sjekker og et menneske som eier endringen. AI kan foreslå rettelser, eller implementere dem innenfor de retningslinjene teamet setter, så lenge endringene klarer samme verifisering som alt en person har skrevet og ikke får noen snarvei for å være maskin‑generert.

Vi trekker den samme grensen i vår egen implementering. Modellen foreslår funn, og gjennomgangsdommen beregnes i kode ut fra tilstanden til disse funnene. Løsning fungerer på samme måte. Når koden bak et funn er fjernet fra diffen, er det en deterministisk sjekk mot den analyserte diffen, og modellen får ikke lov til å “un‑resolve” det diffen allerede har fikset.

Den generelle versjonen av dette er å overlate den probabilistiske lag til oppgaver hvor feil er gjenopprettbare, holde tilstandsmaskinen deterministisk, og la ansvarligheten ligge hos teamet. Det som gir tillit er bevis på at noen kan inspisere og kontrollere at den oppfører seg likt ved hver kjøring.

Sonar kombinerer kontekst‑bevisste pull‑request‑gjennomganger med deterministisk analyse og kvalitetsporter. Hvordan ser en effektiv flerlags verifiseringsprosess ut, og hvordan skal de ulike lagene samhandle uten å duplisere arbeid eller overvelde utviklere med funn?

Deterministisk analyse og kvalitetsporter håndterer de tingene som ikke er til forhandling, og det er det en sammenslåing blokkerer på. Kontekstuell gjennomgang tar de skjønnsmessige vurderingene om en endring gjør det den påstår, om den passer inn i kodebasen, og om en gitt risiko er verdt en persons oppmerksomhet.

En vegg av funn blir ignorert i omtrent samme grad som ingen funn i det hele tatt. Vi dedupierer på tvers av gjennomgåere før noe når forfatteren, forkaster kandidater den ikke kan verifisere, og fokuserer på høy‑signal‑funn. På regel‑siden bestemmer en predikat om en regel gjelder for den aktuelle diffen før noen modell kjører, så de fleste regler koster ingenting på de fleste endringer. Alt dette vises i pull‑requesten utvikleren allerede har åpen.

Etter hvert som kode‑agenter produserer mer kode og flere pull‑requests, kan programvaregjennomgang og -verifisering bli den nye flaskehalsen? Hvilke deler av gjennomgangsprosessen bør automatiseres, og hvilke beslutninger bør forbli hos erfarne ingeniører?

Gjennomgang og verifisering har allerede blitt flaskehalsen. Faktisk fant vår 2026 State of Code Developer Survey at teamene rapporterer at de bruker omtrent en fjerdedel av arbeidsuken på å sjekke og rette AI‑output. Med dette er det ikke overraskende at kun 48 % av utviklerne alltid sjekker AI‑generert kode før de committer den, selv om flertallet (96 %) ikke fullt ut stoler på at den er funksjonelt korrekt.

Det arbeidet som er verdt å automatisere er mekanisk og ubehagelig: å gruppere en CI‑feil ned til en rotårsak slik at ingen må lese fire tusen logglinjer, avgjøre om et funn fortsatt gjelder etter en rebase, reprodusere en feil, skrive den åpenbare rettelsen. Ingeniører bør beholde intensjon, design og vurderingen av hvor mye bevis som er nok for en bestemt endring. Når en senior‑ingeniør bruker en kveld på å lese logger for å finne ut hvilken av ni feil som er viktig, er det triage snarere enn skjønn, og det er nettopp den typen arbeid vi bør ta fra dem.

AI‑kodegjennomgangssystemer kan identifisere problemer, foreslå rettelser og validere disse endringene mot kontinuerlig integrasjons‑pipeline. Hvordan hindrer du et autonomt utbedringssystem fra å introdusere regresjoner eller optimalisere snevert for en vellykket bygg, i stedet for den bredere kvaliteten på programvaren?

Det viktigste er å nekte å behandle grønn som akseptkriteriet, siden en bestått bygg bare forteller deg at de eksisterende testene ikke feilet.

De fleste begrensningene vi legger på vår egen utbedring handler om omfang. Gitar fikser CI som brøt, og den sjekker at commiten før sin egen push var grønn før den påtar seg ansvar for noe. Den stopper etter to påfølgende commits i stedet for å jobbe videre på en rød bygg. Når feilen ikke har noe med endringen å gjøre, en ustabil test eller en infrastruktur‑glipp, går den ned retry‑veien i stedet for fix‑veien, fordi «få testen til å slutte å feile» er målet du minst vil at en dyktig agent skal forfølge.

Etter det må endringen passere et lag Gitar ikke kontrollerer. SonarQube evaluerer resultatet på sine egne vilkår, kvalitetsporten er det merge‑prosessen avhenger av, og teamet eier den policyen. Vi sjekker også endringen mot saken den hevder å implementere, med kravuttrekk holdt adskilt fra fullføringsvurderingen, slik at et krav som stille forlot saken ikke kan komme tilbake som implementert.

Effektiv AI‑kodegjennomgang avhenger av å forstå et repositoriums konvensjoner, avhengigheter, arkitektur og formålet med en foreslått endring. Hvilken kontekst trenger en AI‑gjennomgår for å ta nyttige beslutninger, og hvordan kan organisasjoner holde den konteksten nøyaktig etter hvert som systemene deres utvikler seg?

Den trenger nok kontekst til å resonere som en erfaren gjennomgår, ikke bare nok til å lese diffen. Det inkluderer formålet med endringen, relevante kodeveier og typeinformasjon, avhengigheter, testadferd, repositoriums konvensjoner, og de arkitektoniske grensene teamet forventer at endringen skal respektere.

Konteksten må også leve sammen med koden. Hold regler og gjennomgangsretningslinjer versjonert i repositoriet, oppdater dem når tjenester eller konvensjoner endres, og gjør eierskap tydelig for arkitektoniske og policy‑beslutninger. Ellers kan en AI‑gjennomgår produsere et individuelt plausibelt forslag som er i konflikt med hvordan det bredere systemet faktisk fungerer.

Deterministisk analyse gir konsistente og reviderbare resultater, mens gjennomgang basert på store språkmodeller kan variere mellom kjøringer. Hvordan bør bedrifter dokumentere, reprodusere og styre AI‑genererte funn i regulerte eller sikkerhetskritiske miljøer?

Revisjonssporen bør vise den gjennomgåtte endringen, AI‑funnene, den tatt beslutningen, og det uavhengige beviset som ble brukt til å validere utfallet. Team kan bruke AI til å akselerere gjennomgang og utbedring, samtidig som håndheving og godkjenningsbeslutninger forankres i definerte policyer og menneskelig ansvarlighet.

Hvilke måleparametere bør tekniske ledere bruke for å avgjøre om AI‑kodegjennomgang faktisk forbedrer programvareutviklingen? Bør de prioritere gjennomgangstid, unnslupne feil, falske‑positiv‑rater, CI‑feil, teknisk gjeld, utvikler‑tillit eller en annen måling?

Begynn med resultater, ikke antall kommentarer et AI‑system produserer. Jeg ville måle tid fra pull‑request til merge, tid brukt på å diagnostisere CI‑feil, andelen av rettelser som passerer på første valideringsforsøk, og hvor ofte problemer slipper gjennom til senere faser eller produksjon.

Deretter følg kvalitetssignaler som falske‑positiv‑ og avvisningsrater, gjenåpnede saker, regresjoner knyttet til nylig merge‑de endringer, og utvikler‑tilbakemeldinger på om funn er handlingsbare. Den rette miks av måleparametere varierer per team, men spørsmålet er konsistent: reduserer vi omarbeiding og ventetid på gjennomgang uten å senke standarden for sikker, pålitelig programvare?

Ser du for deg at programvareutvikling vil bli en kontinuerlig sløyfe der agenter genererer, gjennomgår, tester og reparerer kode under deterministiske rekkverk? I et slikt miljø, hvordan vil ansvarsområdene og de nødvendige ferdighetene til menneskelige programvareingeniører endre seg?

Den sløyfen finnes allerede, og team har en tendens til å adoptere den i en fast rekkefølge: først deteksjon, deretter utbedring, så godkjenning under betingelser de skriver ned, og til slutt merge. Ingen hopper direkte til siste steg, og beviset som driver dem videre er deres egen kodebase snarere enn en benchmark. Merge er steget jeg finner mest interessant, fordi konfliktfrekvensen øker med commit‑gjennomstrømning, og gjennomstrømning er det dette øker.

Ferdighetene som får mer verdi ligger rundt sløyfen snarere enn inni den. Å være presis om problemet og dets begrensninger betyr mer når en agent tar beskrivelsen din bokstavelig. Det samme gjelder å bestemme hvilket bevis som er tilstrekkelig for å la en endring passere, noe som tidligere lå i folks hoder som en vane og nå må skrives ned som en policy som automatisering kan anvende. Resten er systemdesign: å avgrense hva automatisert arbeid kan berøre, ha noe som agenten ikke kontrollerer som sjekker resultatet, og holde det ansvarlig når det går galt. Ingeniører vil bruke mindre tid på å produsere implementeringen og mer tid på å bestemme hva som skal eksistere og hva som vil telle som bevis på at det fungerer.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke Sonar.