Gautam Korlam, Ingegnere Principale presso Sonar – Serie di Interviste

Gautam Korlam, Ingegnere Principale presso Sonar, è un veterano ingegnere del software e leader tecnologico la cui carriera si è concentrata su infrastruttura per sviluppatori, qualità del codice, automazione e sviluppo software assistito dall’IA. Prima di unirsi a Sonar, ha co-fondato Gitar e ha ricoperto il ruolo di CTO, costruendo una piattaforma nativa IA progettata per automatizzare la revisione del codice, diagnosticare i fallimenti di integrazione continua (CI), identificare le cause radice e generare correzioni. Sonar ha acquisito Gitar a maggio 2026, con Korlam e il team di Gitar che si sono uniti all’azienda per continuare a sviluppare la tecnologia come parte della più ampia piattaforma di verifica del codice di Sonar. Prima di Gitar, Korlam ha trascorso quasi un decennio presso Uber, passando da ingegnere fondatore del team della piattaforma mobile a Ingegnere Principale. Durante il suo periodo, ha contribuito a costruire e scalare l’infrastruttura centralizzata per sviluppatori di Uber, ha guidato importanti iniziative di monorepo e di sistemi di build, ha sviluppato ambienti di sviluppo remoti e strumenti CI/CD, e ha sperimentato modelli di linguaggio di grandi dimensioni open source come StarCoder, OctoCoder e Code Llama per migliorare la programmazione assistita dall’IA all’interno del codice di Uber. Le sue esperienze precedenti includono ruoli di ingegneria presso Lookout e lavori di ricerca presso UC Santa Barbara, oltre a tirocini presso Microsoft e Oracle.

Sonar è un’azienda software focalizzata sulla verifica del codice, revisione automatizzata del codice, qualità del codice e sicurezza delle applicazioni. La sua piattaforma di punta SonarQube analizza il codice scritto dagli sviluppatori e generato dall’IA per identificare bug, vulnerabilità, problemi di manutenibilità e altre questioni di qualità prima che raggiungano la produzione, con offerte che coprono flussi di lavoro cloud, auto-gestiti e integrati negli ambienti di sviluppo. Sonar afferma che la sua tecnologia è utilizzata da oltre 7 milioni di sviluppatori e 22.000 clienti e analizza più di 750 miliardi di righe di codice ogni giorno. L’acquisizione di Gitar ha ampliato questo approccio alla revisione e alla rimediation del codice nativa IA, combinando il motore di verifica di SonarQube con strumenti agentici capaci di revisionare il codice, indagare sui fallimenti CI e proporre o applicare correzioni man mano che lo sviluppo software diventa sempre più guidato dall’IA.

La tua carriera ti ha portato dalla costruzione dell’infrastruttura mobile e per sviluppatori di Uber all’addestramento di modelli di linguaggio di grandi dimensioni open source sul suo codice, prima di co-fondare Gitar e unirti a Sonar dopo l’acquisizione. In che modo queste esperienze hanno plasmato la tua convinzione che generare codice sia solo una parte della sfida, e che convalidarlo in modo affidabile possa essere il problema più difficile?

Presso Uber ho lavorato sulle parti del sistema che decidono se qualcosa può essere rilasciato: il monorepo, la build, la coda CI, la suite di test. Rendere più facile produrre modifiche sposta tutta la pressione su quella infrastruttura. Si ottengono più servizi che interagiscono in modi imprevedibili, e più ingegneri che attendono di scoprire se la loro modifica è sicura da unire.

Successivamente ho lavorato sull’addestramento di modelli sul nostro codice, ed è lì che l’asimmetria è diventata evidente. Un modello può produrre rapidamente un’implementazione plausibile. Dimostrare che l’implementazione si adatta a un sistema di produzione reale, segue le convenzioni effettivamente usate dal team e non rompe qualcosa a due servizi di distanza richiede molto più tempo, e la maggior parte di quel lavoro ricade sulle persone. Gitar è nato da questo, e si allinea a ciò che Sonar fa dal lato dell’analisi da più di diciassette anni.

Hai sostenuto che la revisione del codice IA dovrebbe integrare l’analisi deterministica piuttosto che sostituirla. Quali tipi di problemi sono meglio identificati tramite analisi ripetibile basata su regole, e dove l’IA può offrire capacità che le tecniche tradizionali non possono?

L’analisi basata su regole è lo strumento giusto quando la proprietà è decidibile dal codice stesso. Input contaminato che raggiunge un sink, una dereferenziazione null su un percorso trascurato, una credenziale hardcoded, una dipendenza con una CVE nota, un’importazione che attraversa uno strato non consentito. Ottieni la stessa risposta ad ogni esecuzione e puoi indicare il motivo per cui è stata attivata, ed è per questo che l’applicazione delle regole appartiene a quel livello.

Ciò che le regole non coprono è l’intento. Nessun parser ti dirà che una stringa destinata all’utente sarà ambigua per chi la traduce, o che una modifica afferma di chiudere un ticket implementando solo metà di quanto richiesto, o che un nuovo ciclo di retry confligge con il modo in cui il resto del servizio gestisce la pressione di ritorno. Un modello che legge il diff insieme al ticket collegato e al contesto dell’intero codebase solleverà questi problemi, e dovrebbero apparire come risultati che una persona verifica piuttosto che come sentenze.

I sistemi IA possono valutare la logica di business, l’intento dello sviluppatore e i compromessi architetturali, ma le loro conclusioni sono probabilistiche. Come possono i team di sviluppo trarre vantaggio da questo ragionamento contestuale senza trattare l’output di un revisore IA come intrinsecamente corretto?

La revisione IA guadagna il suo posto sui problemi che i controlli convenzionali non rilevano: errori logici, comportamenti che non corrispondono all’intento dichiarato, una modifica che sembra corretta di per sé ma è errata per questo specifico sistema. Quelle conclusioni sono probabilistiche, quindi appartengono all’input di una decisione piuttosto che costituire la decisione stessa. I team mantengono quel confine mantenendo i controlli deterministici prima del merge, il che significa test automatizzati, validazione CI, scansione di sicurezza, controlli di policy e un umano responsabile della modifica. L’IA può proporre correzioni, o implementarle all’interno delle barriere impostate dal team, purché tali modifiche superino la stessa verifica di qualsiasi cosa scritta da una persona e non ricevano un trattamento preferenziale per essere state generate dalla macchina.

Tracciamo lo stesso confine all’interno della nostra implementazione. Il modello propone dei risultati, e il verdetto della revisione è calcolato in codice dallo stato di tali risultati. La risoluzione funziona allo stesso modo. Quando il codice relativo a un risultato è rimosso dal diff, ciò costituisce un controllo deterministico sul diff analizzato, e al modello non è permesso annullare la risoluzione di ciò che il diff ha già corretto.

La versione generale di ciò è affidare al livello probabilistico i compiti in cui l’errore è recuperabile, mantenere la macchina a stati deterministica e lasciare la responsabilità al team. Ciò che guadagna fiducia è la prova che qualcuno può ispezionare e controllare, comportandosi allo stesso modo in ogni esecuzione.

Sonar sta combinando revisioni di pull request contestuali con analisi deterministica e quality gate. Come appare un processo di verifica multilivello efficace, e come dovrebbero interagire i diversi livelli senza duplicare il lavoro o sopraffare gli sviluppatori con risultati?

L’analisi deterministica e i quality gate gestiscono gli aspetti non negoziabili, e sono ciò su cui si blocca un merge. La revisione contestuale prende le decisioni di giudizio su se una modifica fa ciò che afferma, se si adatta al codebase e se un determinato rischio vale l’attenzione di una persona.

Un muro di risultati viene ignorato più o meno allo stesso modo di nessun risultato. De‑duplichiamo tra i revisori prima che qualcosa raggiunga l’autore, scartiamo i candidati che non possono essere verificati e ci concentriamo sui risultati ad alto segnale. Per quanto riguarda le regole, un predicato decide se una regola si applica al diff corrente prima che venga eseguito qualsiasi modello, così la maggior parte delle regole non costa nulla nella maggior parte delle modifiche. Tutto ciò appare nella pull request che lo sviluppatore ha già aperta.

Man mano che gli agenti di codifica producono più codice e pull request, la revisione e la verifica del software potrebbero diventare il nuovo collo di bottiglia? Quali parti del processo di revisione dovrebbero essere automatizzate, e quali decisioni dovrebbero rimanere nelle mani di ingegneri esperti?

La revisione e la verifica sono già diventate il collo di bottiglia. In effetti, il nostro 2026 State of Code Developer Survey ha rilevato che i team segnalano di spendere circa un quarto della settimana lavorativa a controllare e correggere l’output dell’IA. Con ciò, non sorprende che solo il 48% degli sviluppatori controlli sempre il codice generato dall’IA prima di committarlo, anche se la maggioranza (96%) non si fida completamente della sua correttezza funzionale.

Il lavoro degno di automazione è meccanico e sgradevole: raggruppare un fallimento CI fino a identificarne la causa radice affinché nessuno debba leggere quattro mila righe di log, decidere se un risultato è ancora valido dopo un rebase, riprodurre un fallimento, scrivere la correzione ovvia. Gli ingegneri dovrebbero mantenere l’intento, il design e la decisione su quanta evidenza sia sufficiente per una determinata modifica. Quando un ingegnere senior trascorre una serata a leggere i log per capire quale delle nove anomalie è rilevante, quello è triage più che giudizio, ed è esattamente il tipo di lavoro che dovremmo togliere loro.

I sistemi di revisione del codice IA possono identificare problemi, proporre correzioni e validare tali modifiche contro il pipeline di integrazione continua. Come si può impedire a un sistema di rimedio autonomo di introdurre regressioni o di ottimizzare in modo ristretto per un build riuscito anziché per la qualità più ampia del software?

La cosa principale è rifiutarsi di considerare il verde come criterio di accettazione, poiché un build riuscito indica solo che i test esistenti non sono falliti.

La maggior parte dei vincoli che applichiamo al nostro rimedio riguarda l’ambito. Gitar corregge i CI che sono falliti, e verifica che il commit precedente al proprio push fosse verde prima di assumersi qualsiasi responsabilità. Si ferma dopo due commit di follow‑up invece di continuare a lavorare su un build rosso. Quando il fallimento non ha nulla a che fare con la modifica, un test instabile o un problema di infrastruttura, si segue il percorso di retry anziché quello di correzione, perché “far smettere di fallire il test” è l’obiettivo che meno desideri che un agente capace persegua.

Successivamente la modifica deve superare uno strato che Gitar non controlla. SonarQube valuta il risultato secondo i propri criteri, il quality gate è ciò da cui dipende il merge, e il team possiede quella policy. Controlliamo anche la modifica rispetto al ticket che dichiara di implementare, mantenendo l’estrazione dei requisiti separata dal giudizio di completamento, così un requisito che è stato rimosso silenziosamente dal ticket non può riapparire come implementato.

Una revisione efficace del codice IA dipende dalla comprensione delle convenzioni, dipendenze, architettura e dello scopo di una modifica proposta in un repository. Quale contesto necessita un revisore IA per prendere decisioni utili, e come le organizzazioni possono mantenere tale contesto accurato man mano che i loro sistemi evolvono?

Ha bisogno di un contesto sufficiente per ragionare come un revisore esperto, non solo per leggere il diff. Ciò include lo scopo della modifica, i percorsi di codice pertinenti e le informazioni sui tipi, le dipendenze, il comportamento dei test, le convenzioni del repository e i confini architetturali che il team si aspetta la modifica rispetti.

Il contesto deve inoltre vivere con il codice. Mantieni regole e linee guida di revisione versionate nel repository, aggiornale quando i servizi o le convenzioni cambiano, e rendi chiara la proprietà per le decisioni architetturali e di policy. Altrimenti, un revisore IA può produrre un suggerimento plausibile a livello individuale che confligge con il modo in cui il sistema più ampio funziona realmente.

L’analisi deterministica produce risultati coerenti e verificabili, mentre la revisione basata su grandi modelli di linguaggio può variare tra esecuzioni. Come dovrebbero le imprese documentare, riprodurre e governare i risultati generati dall’IA in ambienti regolamentati o sensibili alla sicurezza?

Il registro di audit dovrebbe mostrare la modifica revisionata, il risultato IA, la decisione presa e le evidenze indipendenti usate per convalidare l’esito. I team possono utilizzare l’IA per accelerare la revisione e la rimediation, mantenendo le decisioni di applicazione e approvazione ancorate a policy definite e alla responsabilità umana.

Quali metriche dovrebbero utilizzare i leader ingegneristici per determinare se la revisione del codice IA sta realmente migliorando lo sviluppo software? Dovrebbero dare priorità al tempo di revisione, ai difetti sfuggiti, ai tassi di falsi positivi, ai fallimenti di integrazione continua, al debito tecnico, alla fiducia degli sviluppatori o a un’altra misura?

Inizia con i risultati, non con il numero di commenti prodotti da un sistema IA. Misurerei il tempo dalla pull request al merge, il tempo speso a diagnosticare i fallimenti CI, la percentuale di correzioni che passano al primo tentativo di validazione e la frequenza con cui i problemi sfuggono alle fasi successive o alla produzione.

Poi osserva segnali di qualità come i tassi di falsi positivi e di rifiuto, i problemi riaperti, le regressioni collegate a modifiche recentemente mergiate e il feedback degli sviluppatori su se i risultati sono azionabili. La combinazione di metriche giusta varia a seconda del team, ma la domanda rimane costante: stiamo riducendo il lavoro di rifacimento e i tempi di attesa della revisione senza abbassare il livello di sicurezza e affidabilità del software?

Guardando al futuro, ti aspetti che lo sviluppo software diventi un ciclo continuo in cui gli agenti generano, revisionano, testano e riparano il codice sotto barriere deterministiche? In tale contesto, come cambieranno le responsabilità e le competenze richieste agli ingegneri software umani?

Quel ciclo esiste già, e i team tendono ad adottarlo in un ordine fisso: prima la rilevazione, poi la rimediation, poi l’approvazione secondo condizioni che scrivono, infine il merge. Nessuno salta direttamente all’ultimo passo, e le evidenze che li spingono avanti sono il loro stesso codebase piuttosto che un benchmark. Il merge è la fase che trovo più interessante, perché la frequenza dei conflitti aumenta con il volume di commit, e il throughput è ciò che tutto ciò incrementa.

Le competenze che acquisiscono valore si trovano intorno al ciclo piuttosto che al suo interno. Essere precisi sul problema e sui suoi vincoli conta di più quando un agente prende letteralmente la tua descrizione. Lo stesso vale per decidere quali evidenze siano sufficienti per consentire una modifica, cosa che prima viveva nella testa delle persone come abitudine e ora deve essere scritta come policy che l’automazione può applicare. Il resto è progettazione di sistemi: delimitare ciò che il lavoro automatizzato può toccare, far controllare il risultato da qualcosa che l’agente non controlla, e mantenerne la responsabilità quando va storto. Gli ingegneri spenderanno meno tempo a produrre l’implementazione e più tempo a decidere cosa dovrebbe esistere e cosa conti come prova del suo corretto funzionamento.

Grazie per la splendida intervista, i lettori che desiderano saperne di più dovrebbero visitare Sonar.