Gautam Korlam, Inginer Principal la Sonar – Seria de Interviuri

Gautam Korlam, Inginer Principal la Sonar, este un inginer software veteran și lider tehnologic a cărui carieră s-a concentrat pe infrastructura dezvoltatorilor, calitatea codului, automatizare și dezvoltare asistată de AI. Înainte de a se alătura Sonar, a co-fondat Gitar și a ocupat funcția de CTO, construind o platformă nativă AI concepută pentru a automatiza revizuirea codului, a diagnostica eșecurile de integrare continuă (CI), a identifica cauzele rădăcină și a genera remedieri. Sonar a achiziționat Gitar în mai 2026, iar Korlam și echipa Gitar s-au alăturat companiei pentru a continua dezvoltarea tehnologiei ca parte a platformei mai largi de verificare a codului a Sonar. Înainte de Gitar, Korlam a petrecut aproape un deceniu la Uber, evoluând de la inginer fondator în echipa de platformă mobilă la Inginer Principal. În timpul mandatului său, a contribuit la construirea și scalarea infrastructurii centralizate pentru dezvoltatori a Uber, a condus inițiative majore de monorepo și de sistem de build, a dezvoltat medii de dezvoltare remote și instrumente CI/CD și a experimentat cu modele de limbaj mari open‑source precum StarCoder, OctoCoder și Code Llama pentru a îmbunătăți codarea asistată de AI în baza de cod a Uber. Experiența sa anterioară include roluri de inginerie la Lookout și cercetare la UC Santa Barbara, precum și stagii la Microsoft și Oracle.

Sonar este o companie software axată pe verificarea codului, revizuirea automată a codului, calitatea codului și securitatea aplicațiilor. Platforma sa emblematică, SonarQube, analizează cod scris de dezvoltatori și generat de AI pentru a identifica erori, vulnerabilități, probleme de mentenabilitate și alte probleme de calitate înainte de a ajunge în producție, oferind soluții pentru cloud, medii auto-găzduite și fluxuri de lucru integrate în mediul de dezvoltare. Sonar afirmă că tehnologia sa este utilizată de peste 7 milioane de dezvoltatori și 22.000 de clienți și analizează zilnic peste 750 de miliarde de linii de cod. Achiziția Gitar a extins această abordare către revizuirea și remedierea codului nativ AI, combinând motorul de verificare SonarQube cu instrumente autonome capabile să revizuiască codul, să investigheze eșecurile CI și să propună sau să aplice remedieri pe măsură ce dezvoltarea software devine tot mai orientată spre AI.

Cariera ta te-a purtat de la construirea infrastructurii mobile și pentru dezvoltatori la Uber, la antrenarea modelelor de limbaj mari open‑source pe baza sa de cod, înainte de a co-fonda Gitar și de a te alătura Sonar după achiziție. Cum au modelat aceste experiențe credința ta că generarea de cod este doar o parte a provocării, iar validarea fiabilă a acestuia poate fi problema mai dificilă?

La Uber am lucrat la părțile sistemului care decid dacă cineva poate livra: monorepo‑ul, build‑ul, coada CI, suita de teste. Facilitarea producerii de modificări pune toată presiunea pe acea infrastructură. Apare un număr mai mare de servicii care interacționează în moduri neprevăzute și mai mulți ingineri care așteaptă să afle dacă modificarea lor este sigură pentru a fi îmbinată.

Mai târziu am lucrat la antrenarea modelelor pe propria noastră bază de cod, moment în care asimetria a devenit evidentă. Un model putea genera rapid o implementare plauzibilă. Demonstrând că implementarea se potrivește unui sistem de producție în funcțiune, respectă convențiile pe care echipa le folosește efectiv și nu strică ceva la două servicii distanță a durat mult mai mult, iar cea mai mare parte a acestei munci a căzut pe oameni. Gitar a rezultat din această nevoie și se aliniază cu ceea ce Sonar face din perspectiva analizei de peste șaptesprezece ani.

Ai susținut că revizuirea codului prin AI ar trebui să completeze analiza deterministică, nu să o înlocuiască. Ce tipuri de probleme sunt cel mai bine identificate prin analiză repetabilă, bazată pe reguli, și unde poate AI oferi capabilități pe care tehnicile tradiționale nu le pot?

Analiza bazată pe reguli este instrumentul potrivit atunci când proprietatea este decidabilă din codul în sine. Intrare contaminată care ajunge la un sink, o dereferențiere null pe un traseu ratat, o acreditare hardcodată, o dependență cu un CVE cunoscut, o importare care traversează un strat pe care nu ar trebui să-l treacă. Obții același răspuns la fiecare rulare și poți indica motivul declanșării, motiv pentru care aplicarea se află la acel nivel.

Ceea ce regulile nu acoperă este intenția. Niciun parser nu îți va spune că un șir orientat către utilizator va fi ambiguu pentru cineva care îl traduce, sau că o modificare pretinde că închide un tichet în timp ce implementează doar jumătate din cerințele acestuia, sau că un nou ciclu de retry contravine modului în care restul serviciului gestionează presiunea inversă. Un model care citește diff‑ul împreună cu problema legată și contextul complet al bazei de cod va semnala aceste aspecte, iar ele ar trebui să apară ca constatări pe care o persoană le verifică, nu ca verdicturi.

Sistemele AI pot evalua logica de business, intenția dezvoltatorului și compromisurile arhitecturale, dar concluziile lor sunt probabilistice. Cum pot echipele de dezvoltare să beneficieze de acest raționament contextual fără să trateze output‑ul unui reviewer AI ca fiind inerent corect?

Revizuirea AI își câștigă locul pe problemele pe care verificările convenționale le omite: erori de logică, comportament ce nu corespunde intenției declarate, o modificare care pare corectă luată izolat, dar este greșită pentru sistemul respectiv. Aceste concluzii sunt probabilistice, așadar fac parte din inputul unei decizii, nu reprezintă decizia în sine. Echipele mențin această limită păstrând controalele deterministe în fața îmbinării, adică teste automate, validare CI, scanare de securitate, verificări de politică și un om responsabil de modificare. AI poate propune remedieri sau le poate implementa în cadrul limitărilor stabilite de echipă, atâta timp cât acele modificări trec aceeași verificare ca orice cod scris de o persoană și nu beneficiază de un scurtcircuit pentru faptul că au fost generate de mașină.

Aplicăm aceeași limită în propria noastră implementare. Modelul propune constatări, iar verdictul revizuirii este calculat în cod pe baza stării acelor constatări. Rezolvarea funcționează în același mod. Când codul aferent unei constatări a dispărut din diff, aceasta reprezintă o verificare deterministică a diff‑ului analizat, iar modelului nu i se permite să anuleze ceea ce diff‑ul a rezolvat deja.

Versiunea generală a acestui principiu este să încredințezi stratului probabilistic sarcini în care greșelile sunt recuperabile, să menții mașina de stare deterministică și să lași responsabilitatea echipei. Încrederea se câștigă prin dovezi pe care cineva le poate inspecta și controla, comportându-se identic la fiecare rulare.

Sonar combină revizuirile de pull request conștiente de context cu analiza deterministică și porțile de calitate. Cum arată un proces de verificare multilayer eficient și cum ar trebui să interacționeze diferitele straturi fără a duplica munca sau a copleși dezvoltatorii cu constatări?

Analiza deterministică și porțile de calitate gestionează aspectele care nu sunt negociabile și reprezintă criteriile pe care un merge le blochează. Revizuirea contextuală ia decizii de judecată privind dacă o modificare face ceea ce pretinde, dacă se potrivește în baza de cod și dacă un anumit risc merită atenția unei persoane.

Un perete de constatări este ignorat aproximativ în aceeași proporție ca și absența totală a constărilor. Eliminăm duplicatele între revizori înainte ca ceva să ajungă la autor, renunțăm la candidații pe care nu îi putem verifica și ne concentrăm pe constatări cu semnal puternic. Din perspectiva regulilor, un predicat decide dacă o regulă se aplică diff‑ului curent înainte de rularea oricărui model, astfel că majoritatea regulilor nu costă nimic pentru majoritatea modificărilor. Totul apare în pull request‑ul pe care dezvoltatorul îl are deja deschis.

Pe măsură ce agenții de codare produc tot mai mult cod și pull request‑uri, revizuirea și verificarea software ar putea deveni noul blocaj? Ce părți ale procesului de revizuire ar trebui să fie automatizate și ce decizii ar trebui să rămână în sarcina inginerilor cu experiență?

Revizuirea și verificarea au devenit deja blocajul. De fapt, 2026 State of Code Developer Survey a arătat că echipele raportează că petrec aproximativ un sfert din săptămâna de lucru verificând și corectând output‑ul AI. În acest context, nu este surprinzător că doar 48% dintre dezvoltatori verifică întotdeauna codul generat de AI înainte de a-l comite, deși majoritatea (96%) nu au încredere deplină că este funcțional corect.

Munca care merită automatizată este cea mecanică și neplăcută: gruparea unui eșec CI până la cauza rădăcină pentru a nu face pe nimeni să citească patru mii de linii de jurnal, deciderea dacă o constatare mai este valabilă după un rebase, reproducerea unui eșec, scrierea remedierii evidente. Inginerii ar trebui să păstreze intenția, designul și decizia privind cât de multe dovezi sunt suficiente pentru o anumită modificare. Când un inginer senior petrece o seară citind jurnale pentru a determina care dintre cele nouă eșecuri contează, aceasta este triere, nu judecată, și este exact tipul de muncă pe care ar trebui să o scăpăm de pe umerii lor.

Sistemele de revizuire a codului prin AI pot identifica probleme, propune remedieri și valida acele modificări în cadrul pipeline‑ului de integrare continuă. Cum împiedici un sistem autonom de remediere să introducă regresii sau să se optimizeze strict pentru un build de succes în detrimentul calității globale a software‑ului?

Principalul lucru este să nu tratăm verdele ca criteriu de acceptare, deoarece un build reușit indică doar că testele existente nu au eșuat.

Majoritatea constrângerilor pe care le impunem remedierei noastre se referă la domeniu. Gitar repară CI‑ul care a eșuat și verifică că commit‑ul anterior propriei sale push‑uri era verde înainte de a-și asuma responsabilitatea pentru orice. Se oprește după două commit‑uri ulterioare în loc să continue să lucreze la un build roșu. Când eșecul nu are legătură cu modificarea, un test instabil sau o problemă de infrastructură, se urmează calea de reîncercare în loc de cea de remediere, deoarece „fă testul să nu mai eșueze” este obiectivul pe care un agent capabil ar trebui să-l evite.

După aceea, modificarea trebuie să treacă printr-un strat pe care Gitar nu îl controlează. SonarQube evaluează rezultatul în propriile sale condiții, poarta de calitate este ceea ce determină succesul îmbinării, iar echipa deține acea politică. Verificăm, de asemenea, modificarea în raport cu problema pe care pretinde să o implementeze, menținând extragerea cerințelor separată de judecata finalizării, astfel încât o cerință care a dispărut silențios din tichet să nu poată reapărea ca implementată.

O revizuire eficientă a codului prin AI depinde de înțelegerea convențiilor, dependențelor, arhitecturii și scopului unei modificări propuse dintr-un repository. Ce context are nevoie un reviewer AI pentru a lua decizii utile și cum pot organizațiile să mențină acel context actualizat pe măsură ce sistemele evoluează?

Are nevoie de suficient context pentru a raționa ca un reviewer experimentat, nu doar pentru a citi diff‑ul. Aceasta include scopul modificării, căile de cod relevante și informațiile de tip, dependențele, comportamentul testelor, convențiile repository‑ului și limitele arhitecturale pe care echipa le așteaptă să le respecte modificarea.

Contextul trebuie, de asemenea, să trăiască împreună cu codul. Păstrează regulile și ghidurile de revizuire versionate în repository, actualizează-le când serviciile sau convențiile se schimbă și clarifică responsabilitatea pentru deciziile arhitecturale și de politică. În caz contrar, un reviewer AI poate genera o sugestie individual plausibilă care intră în conflict cu modul în care sistemul mai larg funcționează în realitate.

Analiza deterministică produce rezultate consecvente și auditate, în timp ce revizuirea bazată pe modele de limbaj mari poate varia între rulări. Cum ar trebui întreprinderile să documenteze, să reproducă și să guverneze constatări generate de AI în medii reglementate sau sensibile din punct de vedere al securității?

Traseul de audit ar trebui să afișeze modificarea revizuită, constatarea AI, decizia luată și dovezile independente utilizate pentru a valida rezultatul. Echipele pot folosi AI pentru a accelera revizuirea și remedierea, menținând în același timp aplicarea și deciziile de aprobare ancorate în politici definite și responsabilitatea umană.

Ce metrici ar trebui să folosească liderii de inginerie pentru a determina dacă revizuirea codului prin AI îmbunătățește cu adevărat dezvoltarea software? Ar trebui să prioritizeze timpul de revizuire, defectele scăpate, ratele de fals‑pozitive, eșecurile de integrare continuă, datoria tehnică, încrederea dezvoltatorilor sau altă măsură?

Începe cu rezultatele, nu cu numărul de comentarii produse de un sistem AI. Aș măsura timpul de la pull request la îmbinare, timpul petrecut diagnosticând eșecurile CI, rata la care remedierile trec la prima încercare de validare și frecvența cu care problemele scapă în etape ulterioare sau în producție.

Apoi monitorizează semnalele de calitate, cum ar fi ratele de fals‑pozitive și respingeri, problemele redeschise, regresiile legate de modificări recent îmbinate și feedback‑ul dezvoltatorilor privind dacă constatări sunt acționabile. Amestecul potrivit de metrici variază în funcție de echipă, dar întrebarea rămâne constantă: reducem munca suplimentară și timpul de așteptare al revizuirii fără a scădea standardul pentru software sigur și fiabil?

Privind spre viitor, te aștepți ca dezvoltarea software să devină un ciclu continuu în care agenții generează, revizuiesc, testează și repară codul sub ghiduri deterministe? În acel mediu, cum se vor schimba responsabilitățile și competențele necesare ale inginerilor software umani?

Acest ciclu există deja, iar echipele tind să îl adopte într-o ordine fixă: mai întâi detectarea, apoi remedierea, apoi aprobarea sub condițiile pe care le documentează, apoi îmbinarea. Nimeni nu sare direct la ultima etapă, iar dovezile care îi avansează sunt propria bază de cod, nu un benchmark. Îmbinarea este pasul pe care îl găsesc cel mai interesant, deoarece frecvența conflictelor crește odată cu volumul de commit‑uri, iar volumul este ceea ce toate acestea amplifică.

Competențele care capătă valoare se află în jurul ciclului, nu în interiorul său. Precizia în definirea problemei și a constrângerilor sale contează mai mult când un agent preia descrierea ta literalmente. La fel și decizia privind ce dovezi sunt suficiente pentru a permite trecerea unei modificări, care înainte trăia în mintea oamenilor ca un obicei și acum trebuie să fie documentată ca politică pe care automatizarea o poate aplica. Restul este designul de sisteme: delimitarea lucrărilor automate, existența unui mecanism pe care agentul nu îl controlează pentru a verifica rezultatul și menținerea responsabilității când apar erori. Inginerii vor petrece mai puțin timp producând implementarea și mai mult timp decidând ce ar trebui să existe și ce ar conta ca dovadă că funcționează.

Vă mulțumim pentru interviul excelent, cititorii care doresc să afle mai multe ar trebui să viziteze Sonar.