Gautam Korlam, Principal Engineer hos Sonar – Interviewserie

Gautam Korlam, Principal Engineer hos Sonar, er en erfaren softwareingeniør og teknologileder, hvis karriere har fokuseret på udviklerinfrastruktur, kodekvalitet, automatisering og AI‑assisteret softwareudvikling. Før han sluttede sig til Sonar, var han medstifter af Gitar og fungerede som CTO, hvor han byggede en AI‑native platform designet til at automatisere kodegennemgang, diagnosticere fejl i kontinuerlig integration (CI), identificere grundårsager og generere rettelser. Sonar købte Gitar i maj 2026, hvor Korlam og Gitar‑teamet gik ind i virksomheden for at fortsætte udviklingen af teknologien som en del af Sonars bredere kodeverifikationsplatform. Før Gitar tilbragte Korlam næsten et årti hos Uber, hvor han gik fra en grundlæggende ingeniør på deres mobilplatformteam til Principal Engineer. I løbet af sin tid hjalp han med at bygge og skalere Ubers centraliserede udviklerinfrastruktur, ledede store monorepo‑ og build‑systeminitiativer, udviklede fjernudviklingsmiljøer og CI/CD‑værktøjer, og eksperimenterede med open‑source store sprogmodeller som StarCoder, OctoCoder og Code Llama for at forbedre AI‑assisteret kodning i Ubers kodebase. Tidligere erfaring omfatter ingeniørroller hos Lookout og forskningsarbejde ved UC Santa Barbara samt praktikophold hos Microsoft og Oracle.

Sonar er en softwarevirksomhed, der fokuserer på kodeverifikation, automatiseret kodegennemgang, kodekvalitet og applikationssikkerhed. Dens flagskibsplatform SonarQube analyserer både udvikler‑skrevet og AI‑genereret kode for at identificere fejl, sårbarheder, vedligeholdelsesproblemer og andre kvalitetsproblemer, før de når produktion, med tilbud der spænder over cloud, selv‑hostet og integrerede udviklingsmiljø‑arbejdsgange. Sonar oplyser, at deres teknologi bruges af mere end 7 millioner udviklere og 22.000 kunder og analyserer over 750 milliarder kodelinjer hver dag. Opkøbet af Gitar udvidede denne tilgang til AI‑native kodegennemgang og -rettelse, ved at kombinere SonarQubes verifikationsmotor med agent‑værktøjer, der kan gennemgå kode, undersøge CI‑fejl og foreslå eller anvende rettelser, efterhånden som softwareudvikling bliver stadig mere AI‑drevet.

Din karriere har taget dig fra at bygge Ubers mobile og udviklerinfrastruktur til at træne open‑source store sprogmodeller på deres kodebase, før du medstiftede Gitar og sluttede dig til Sonar efter deres opkøb. Hvordan har disse oplevelser formet din overbevisning om, at generering af kode kun er en del af udfordringen, og at pålidelig validering af den kan være det sværere problem?

Hos Uber arbejdede jeg på de dele af systemet, der beslutter, om noget overhovedet bliver ship‑et: monorepoen, bygningen, CI‑køen, test‑suite’en. At gøre det lettere at producere ændringer lægger al presset på den maskineri. Man får flere tjenester, der interagerer på uforudsete måder, og flere ingeniører, der venter på at finde ud af, om deres ændring er sikker at merge.

Senere arbejdede jeg på at træne modeller på vores egen kodebase, hvor asymmetrien blev tydelig. En model kan hurtigt producere en plausibel implementering. At vise, at implementeringen passer ind i et live produktionssystem, følger de konventioner, dette team faktisk bruger, og ikke ødelægger noget to tjenester væk, tog meget længere, og størstedelen af dette arbejde endte hos mennesker. Gitar opstod ud fra dette, og det passer sammen med, hvad Sonar har gjort fra analysesiden i over sytten år.

Du har argumenteret for, at AI‑kodegennemgang skal supplere deterministisk analyse snarere end erstatte den. Hvilke typer problemer identificeres bedst gennem gentagelig, regelbaseret analyse, og hvor kan AI levere evner, som traditionelle teknikker ikke kan?

Regelbaseret analyse er det rette værktøj, når egenskaben kan afgøres ud fra selve koden. Forurenet input, der når en sink, en null‑dereference på en sti, nogen har overset, en hardkodet legitimationsoplysning, en afhængighed med en kendt CVE, en import, der krydser et lag, den ikke bør. Du får det samme svar ved hver kørsel, og du kan pege på årsagen til, at den udløstes, hvilket er grunden til, at håndhævelse hører til på dette lag.

Hvad regler ikke dækker, er intention. Ingen parser vil fortælle dig, at en bruger‑vendt streng vil være tvetydig for den, der oversætter den, eller at en ændring påstår at lukke en ticket, mens den kun implementerer halvdelen af, hvad ticket’en bad om, eller at en ny retry‑loop konflikter med den måde, resten af tjenesten håndterer backpressure på. En model, der læser diff’en sammen med den tilknyttede issue og den fulde kodebase‑kontekst, vil påpege disse, og de bør fremkomme som fund, som en person tjekker, snarere end som domme.

AI‑systemer kan vurdere forretningslogik, udviklerintention og arkitektoniske afvejninger, men deres konklusioner er probabilistiske. Hvordan kan udviklingsteams drage fordel af denne kontekstuelle ræsonnement uden at betragte en AI‑reviewers output som iboende korrekt?

AI‑gennemgang fortjener sin plads på de problemer, som konventionelle tjek overser: logikfejl, adfærd der ikke svarer til den erklærede intention, en ændring der ser korrekt ud i sig selv, men er forkert for netop dette system. Disse konklusioner er probabilistiske, så de hører til som input til en beslutning snarere end som selve beslutningen. Teams holder denne grænse ved at holde de deterministiske kontroller foran merge‑processen, hvilket betyder automatiserede tests, CI‑validering, sikkerhedsscanning, politik‑tjek og en person, der ejer ændringen. AI kan foreslå rettelser eller implementere dem inden for de retningslinjer, teamet fastsætter, så længe disse ændringer bestå den samme verifikation som alt hvad en person har skrevet, og de ikke får en forkortelse for at være maskin‑genereret.

Vi trækker den samme grænse i vores egen implementering. Modellen foreslår fund, og review‑dommen beregnes i kode ud fra tilstanden af disse fund. Løsning fungerer på samme måde. Når koden bag et fund er fjernet fra diff’en, er det et deterministisk tjek mod den parse‑de diff, og modellen har ikke lov til at “un‑resolve” det, som diff’en allerede har rettet.

Den generelle version er at overlade den probabilistiske lag de opgaver, hvor fejl er genoprettelige, holde tilstandsmaskinen deterministisk og lade ansvaret ligge hos teamet. Hvad der opbygger tillid, er beviser, som nogen kan inspicere og kontrollere, så de opfører sig ens ved hver kørsel.

Sonar kombinerer kontekst‑bevidste pull‑request‑reviews med deterministisk analyse og quality gates. Hvordan ser en effektiv flerlaget verifikationsproces ud, og hvordan skal de forskellige lag interagere uden at duplikere arbejde eller overvælde udviklere med fund?

Deterministisk analyse og quality gates håndterer de ting, der ikke er til forhandling, og som en merge blokerer på. Kontekstuel review tager de skønsmæssige beslutninger om, hvorvidt en ændring gør, hvad den påstår, om den passer ind i kodebasen, og om en given risiko er værd en persons opmærksomhed.

En mur af fund bliver ignoreret i omtrent samme grad som ingen fund overhovedet. Vi deduplicerer på tværs af reviewers, før noget når forfatteren, dropper kandidater, den ikke kan verificere, og fokuserer på fund med høj signalværdi. På regelsiden beslutter en prædikat, om en regel gælder for den aktuelle diff, før nogen model kører, så de fleste regler koster ingenting på de fleste ændringer. Alt dette vises i pull‑requesten, som udvikleren allerede har åben.

Efterhånden som kodningsagenter producerer mere kode og flere pull‑requests, kan softwaregennemgang og -verifikation blive den nye flaskehals? Hvilke dele af review‑processen bør automatiseres, og hvilke beslutninger bør forblive hos erfarne ingeniører?

Review og verifikation er allerede blevet flaskehalsen. Faktisk viste vores 2026 State of Code Developer Survey, at teams bruger omkring en kvart af arbejdsugen på at tjekke og rette AI‑output. På grund af dette er det ikke overraskende, at kun 48 % af udviklere altid tjekker AI‑genereret kode, før de committer den, selvom flertallet (96 %) ikke har fuld tillid til, at den er funktionelt korrekt.

Det arbejde, der er værd at automatisere, er mekanisk og ubehageligt: at gruppere en CI‑fejl ned til en grundårsag, så ingen behøver læse fire tusinde loglinjer, at beslutte, om et fund stadig gælder efter en rebase, at reproducere en fejl, at skrive den indlysende rettelse. Ingeniører bør bevare intention, design og beslutningen om, hvor meget evidens der er tilstrækkelig for en given ændring. Når en senioringeniør bruger en aften på at læse logs for at finde ud af, hvilken af ni fejl der er vigtig, er det triage snarere end dom, og det er netop den type arbejde, vi bør fjerne fra dem.

AI‑kodegennemgangssystemer kan identificere problemer, foreslå rettelser og validere disse ændringer mod CI‑pipeline’en. Hvordan forhindrer du, at et autonomt remedieringssystem introducerer regressioner eller kun optimerer for en vellykket build i stedet for den bredere kvalitet af softwaren?

Hovedpointen er at nægte at behandle en grøn status som acceptkriterium, da en bestået build kun viser, at de eksisterende tests ikke fejlede.

De fleste af de begrænsninger, vi pålægger vores egen remediation, handler om omfang. Gitar retter CI, der gik i stykker, og den tjekker, at committet før dens egen push var grønt, før den påtager sig ansvar for noget. Den stopper efter to efterfølgende commits i stedet for at arbejde videre på en rød build. Når fejlen ikke har noget med ændringen at gøre – en ustabil test eller en infrastruktur‑glitch – går den ned ad retry‑stien i stedet for fix‑stien, fordi “få testen til at stoppe med at fejle” er det mål, du mindst ønsker, at en kompetent agent forfølger.

Efter det skal ændringen bestå et lag, som Gitar ikke kontrollerer. SonarQube evaluerer resultatet på sine egne vilkår, quality gate er det, som merge‑processen afhænger af, og teamet ejer den politik. Vi tjekker også ændringen mod den issue, den påstår at implementere, med kravudtræk holdt adskilt fra fuldførelsesvurderingen, så et krav, der stille er forladt ticket’en, ikke kan komme tilbage som implementeret.

Effektiv AI‑kodegennemgang afhænger af forståelsen af et repositories konventioner, afhængigheder, arkitektur og formålet med en foreslået ændring. Hvilken kontekst har en AI‑reviewer brug for at træffe brugbare beslutninger, og hvordan kan organisationer holde denne kontekst præcis, efterhånden som deres systemer udvikler sig?

Den har brug for nok kontekst til at resonere som en erfaren reviewer, ikke blot nok til at læse diff’en. Det inkluderer formålet med ændringen, relevante kodeveje og typeinformation, afhængigheder, testadfærd, repository‑konventioner og de arkitektoniske grænser, som teamet forventer, at ændringen respekterer.

Konteksten skal også leve sammen med koden. Hold regler og review‑vejledninger versioneret i repository’en, opdater dem når tjenester eller konventioner ændrer sig, og gør ejerskab tydeligt for arkitektoniske og politiske beslutninger. Ellers kan en AI‑reviewer producere et individuelt plausibelt forslag, som er i konflikt med, hvordan det bredere system faktisk fungerer.

Deterministisk analyse leverer konsistente og auditérbare resultater, mens review baseret på store sprogmodeller kan variere mellem kørsel. Hvordan bør virksomheder dokumentere, reproducere og styre AI‑genererede fund i regulerede eller sikkerhedskritiske miljøer?

Audit‑sporet bør vise den gennemgåede ændring, AI‑fundet, den trufne beslutning og det uafhængige bevis, der blev brugt til at validere resultatet. Teams kan bruge AI til at accelerere review og remediation, mens håndhævelse og godkendelsesbeslutninger forbliver forankret i definerede politikker og menneskelig ansvarlighed.

Hvilke metrics bør tekniske ledere bruge for at afgøre, om AI‑kodegennemgang faktisk forbedrer softwareudviklingen? Skal de prioritere review‑tid, undslupne fejl, falske positive, CI‑fejl, teknisk gæld, udvikler‑tillid eller en anden måling?

Start med resultater, ikke antallet af kommentarer, som et AI‑system producerer. Jeg ville måle tiden fra pull‑request til merge, tiden brugt på at diagnosticere CI‑fejl, andelen af rettelser, der bestå på første valideringsforsøg, og hvor ofte problemer undslipper til senere faser eller produktion.

Herefter hold øje med kvalitetssignaler som falske positive og afvisningsrater, genåbnede issues, regressioner knyttet til nyligt merged ændringer, og udviklerfeedback om, hvorvidt fund er handlingsbare. Den rette kombination af metrics varierer fra team til team, men spørgsmålet er konsistent: reducerer vi genarbejde og ventetid på review uden at sænke baren for sikker, pålidelig software?

Ser du fremad, at softwareudvikling vil blive en kontinuerlig løkke, hvor agenter genererer, reviewerer, tester og reparerer kode under deterministiske sikkerhedsrammer? I et sådant miljø, hvordan vil ansvarsområderne og de nødvendige færdigheder for menneskelige softwareingeniører ændre sig?

Den løkke findes allerede, og teams har en tendens til at adoptere den i en fast rækkefølge: først detektion, derefter remediation, så godkendelse under de betingelser, de nedskriver, og til sidst merge. Ingen springer direkte til det sidste trin, og beviset, der driver dem frem, er deres egen kodebase snarere end et benchmark. Merge er det trin, jeg finder mest interessant, fordi konfliktfrekvensen stiger med commit‑gennemstrømning, og gennemstrømning er det, som alt dette øger.

De færdigheder, der får værdi, ligger omkring løkken snarere end inde i den. At være præcis omkring problemet og dets begrænsninger betyder mere, når en agent tager din beskrivelse bogstaveligt. Det samme gælder beslutningen om, hvilket bevis der er tilstrækkeligt til at lade en ændring passere, hvilket tidligere levede i folks hoveder som en vane, men nu skal nedskrives som politik, som automatisering kan anvende. Resten er systemdesign: at afgrænse, hvad automatiseret arbejde kan berøre, have noget, som agenten ikke kontrollerer, til at tjekke resultatet, og holde det ansvarligt, når det går galt. Ingeniører vil bruge mindre tid på at producere implementeringen og mere tid på at beslutte, hvad der skal eksistere, og hvad der vil tælle som bevis for, at det fungerer.

Tak for det fantastiske interview, læsere der ønsker at lære mere, bør besøge Sonar.