Gautam Korlam, Sonarin pääinsinööri – Haastattelusarja

Gautam Korlam, Sonarin pääinsinööri, on kokenut ohjelmistokehittäjä ja teknologiaveto, jonka ura on keskittynyt kehittäjäinfrastruktuuriin, koodin laatuun, automaatioon ja tekoälyavusteiseen ohjelmistokehitykseen. Ennen Sonariin siirtymistään hän perusti Gitarin ja toimi CTO:n roolissa rakentaen tekoälyyn perustuvaa alustaa, jonka tarkoitus on automatisoida koodikatselmointi, diagnosoida jatkuvan integraation (CI) epäonnistumiset, tunnistaa perimmäiset syyt ja tuottaa korjauksia. Sonar hankki Gitarin toukokuussa 2026, ja Korlam sekä Gitarin tiimi liittyivät yritykseen jatkaakseen teknologian kehittämistä osana Sonarin laajempaa koodin tarkistusalustaa. Ennen Gitaria Korlam vietti lähes vuosikymmenen Uberissa, aloittaen perustajajärjestelmäinsinöörinä mobiilialustan tiimissä ja edeten pääinsinööriksi. Työnsä aikana hän auttoi rakentamaan ja laajentamaan Uberin keskitettyä kehittäjäinfrastruktuuria, johti merkittäviä monorepo- ja rakennusjärjestelmäaloitteita, kehitti etäkehittäjäympäristöjä ja CI/CD‑työkaluja sekä kokeili avoimen lähdekoodin suuria kielimalleja, kuten StarCoderia, OctoCoderia ja Code Llamaa, parantaakseen tekoälyavusteista koodausta Uberin koodikannassa. Aikaisempi kokemus sisältää insinööritehtäviä Lookoutissa ja tutkimustyötä UC Santa Barbarassa sekä harjoittelujaksoja Microsoftilla ja Oraclella.

Sonar on ohjelmistoyritys, joka keskittyy koodin tarkistukseen, automatisoituun koodikatselmointiin, koodin laatuun ja sovellusturvallisuuteen. Sen lippulaiva SonarQube‑alusta analysoi kehittäjien kirjoittamaa ja tekoälyn tuottamaa koodia tunnistaakseen virheitä, haavoittuvuuksia, ylläpidettävyyteen liittyviä ongelmia ja muita laatuongelmia ennen kuin ne päätyvät tuotantoon, ja se tarjoaa ratkaisuja pilvi‑, itsehallinnoituun että integroituun kehitysympäristöön perustuvissa työnkuluissa. Sonarin mukaan sen teknologiaa käyttää yli 7 miljoonaa kehittäjää ja 22 000 asiakasta, ja se analysoi päivittäin yli 750 miljardia koodiriviä. Gitarin hankinta laajensi tätä lähestymistapaa tekoälyyn perustuvaan koodikatselmointiin ja korjaukseen, yhdistäen SonarQuben tarkistusmoottorin agenttipohjaisiin työkaluihin, jotka pystyvät tarkastelemaan koodia, tutkimaan CI‑epäonnistumisia ja ehdottamaan tai toteuttamaan korjauksia, kun ohjelmistokehitys muuttuu yhä enemmän tekoälyohjatuksi.

Uratasi on kulkenut Uberin mobiili‑ ja kehittäjäinfrastruktuurin rakentamisesta avoimen lähdekoodin suurten kielimallien kouluttamiseen sen koodikannassa, ennen kuin peristit Gitarin ja liityit Sonariin sen hankinnan jälkeen. Miten nämä kokemukset muovasivat uskoasi siihen, että koodin generointi on vain osa haastetta, ja että sen luotettava validointi saattaa olla vaikeampi ongelma?

Uberissa työskentelin järjestelmän osissa, jotka päättävät, kuka saa julkaista: monorepo, build, CI‑jono, testisarja. Muutosten tuottamisen helpottaminen siirtää kaiken paineen siihen koneistoon. Saat enemmän palveluita vuorovaikutukseen tavoilla, joita kukaan ei osannut ennakoida, ja enemmän insinöörejä odottamaan, saako heidän muutoksensa turvallisesti yhdistää.

Myöhemmin työskentelin mallien kouluttamisen parissa omassa koodikannassamme, ja silloin epäsymmetria tuli ilmeiseksi. Malli pystyi tuottamaan uskottavan toteutuksen nopeasti. Sen osoittaminen toimivaksi tuotantoympäristössä, tiimimme käyttämien konventioiden noudattamiseksi eikä kahden palvelun välistä katkaisua aiheuttavaksi, kesti paljon kauemmin, ja suurin osa siitä työstä jäi ihmisille. Gitar syntyi tästä, ja se sopii yhteen sen kanssa, mitä Sonar on tehnyt analyysipuolella jo yli seitsemäntoista vuotta.

Olet väittänyt, että tekoälypohjainen koodikatselmointi tulisi täydentämään determinististä analyysiä eikä korvaamaan sitä. Millaisia ongelmia voidaan parhaiten tunnistaa toistettavalla, sääntöperusteisella analyysillä, ja missä tekoäly tarjoaa kyvykkyyksiä, joita perinteiset tekniikat eivät pysty?

Sääntöperusteinen analyysi on oikea työkalu, kun ominaisuus on päätettävissä suoraan koodista. Saastunut syöte, joka päätyy kohteeseen, null‑dereferenssi polulla, jonka joku jätti huomaamatta, kovakoodattu tunnistetieto, riippuvuus, jossa on tunnettu CVE, tai importti, joka ylittää kerroksen, jota ei pitäisi ylittää. Saat saman vastauksen jokaisella ajokerralla ja voit osoittaa, miksi se laukesi, minkä takia toteutus kuuluu tähän kerrokseen.

Mitä säännöt eivät kata, on tarkoitus. Mikään parseri ei kerro, että käyttäjälle näkyvä merkkijono on epäselvä kääntäjälle, tai että muutos väittää sulkevansa tiketin toteuttaen vain puolet siitä, mitä tiketti pyysi, tai että uusi uudelleenyrittelysilmukka on ristiriidassa palvelun muun takaisinkytkennän kanssa. Malli, joka lukee diffin yhdessä linkitetyn tiketin ja koko koodikannan kontekstin kanssa, nostaa esiin nämä asiat, ja niiden tulisi tulla löydöksinä, jotka henkilö tarkistaa, eikä päätöksinä.

Tekoälyjärjestelmät voivat arvioida liiketoimintalogiikkaa, kehittäjän aikomusta ja arkkitehtonisia kompromisseja, mutta niiden johtopäätökset ovat todennäköisyysperusteisia. Kuinka kehitystiimit voivat hyötyä tästä kontekstuaalisesta päättelystä ilman, että tekoälykatselmuksen tulosta pidetään itsestäänselvästi oikeana?

Tekoälykatselmus ansaitsee paikkansa ongelmissa, jotka perinteiset tarkistukset ohittavat: loogiset virheet, käyttäytyminen, joka ei vastaa ilmoitettua tarkoitusta, muutos, joka näyttää itsessään kelvolliselta mutta on väärä juuri tässä järjestelmässä. Nämä johtopäätökset ovat todennäköisyysperusteisia, joten ne kuuluvat päätöksen syötteeseen eikä päätökseksi itsessään. Tiimit pitävät tätä rajaa yllä pitämällä deterministiset kontrollit ennen yhdistämistä, kuten automaattiset testit, CI‑validointi, tietoturvatarkistukset, politiikkatarkistukset ja ihminen, joka omistaa muutoksen. Tekoäly voi ehdottaa korjauksia tai toteuttaa ne tiimin asettamien suojarajojen sisällä, kunhan muutokset läpäisevät saman tarkistuksen kuin mitä tahansa ihmisen kirjoittama koodi eikä niille myönnetä lyhennystä pelkästään siksi, että ne on koneen tuottamia.

Me vedämme saman rajan myös omassa toteutuksessamme. Malli ehdottaa löydöksiä, ja katselmuksen päätös lasketaan koodissa näiden löydösten tilasta. Ratkaisu toimii samalla tavalla. Kun löydökseen liittyvä koodi on poistunut diffistä, se on deterministinen tarkistus parsattua diffiä vastaan, eikä mallilla ole oikeutta kumota jo korjattua asiaa.

Yleinen versio tästä on antaa todennäköisyyskerrokselle ne tehtävät, joissa virhe on korjattavissa, pitää tilakone deterministisena ja jättää vastuu tiimille. Luottamusta ansaitsee se todiste, jonka joku voi tarkistaa ja joka käyttäytyy samalla tavalla jokaisella ajokerralla.

Sonar yhdistää kontekstitietoiset pull‑request‑katselmukset deterministiseen analyysiin ja laatukäytäviin. Millainen tehokas monikerroksinen tarkistusprosessi näyttää, ja miten eri kerrokset voivat toimia yhdessä ilman, että työtä monistetaan tai kehittäjät hukuttuvat löydöksiin?

Deterministinen analyysi ja laatukäytävät kantavat ne asiat, joista ei voi neuvotella, ja ne ovat se, mikä estää yhdistämisen. Kontekstuaalinen katselmus tekee harkintapäätökset siitä, täyttääkö muutos väitteensä, sopiiko se koodikantaan ja onko riski riittävän merkittävä ihmisen huomion arvoinen.

Löydösten seinä jää huomiotta suunnilleen yhtä usein kuin ei löydöksiä ollenkaan. Poistamme duplikaatit eri katselmoijien välillä ennen kuin mitään saavuttaa tekijän, pudotamme ehdokkaat, joita ei voida varmistaa, ja keskitymme korkean signaalin löydöksiin. Sääntöpuolella predikaatti päättää, sovelletaanko sääntöä nykyiseen diffiin ennen kuin malli ajetaan, joten suurin osa säännöistä ei kuluta resursseja useimmissa muutoksissa. Kaikki tämä ilmenee pull‑requestissa, jonka kehittäjä on jo avannut.

Kun koodin tuottavat agentit luovat yhä enemmän koodia ja pull‑requesteja, voisiko ohjelmistokatselmus ja -tarkistus muuttua uudeksi pullonkaulaksi? Mitkä osat katselmusprosessista tulisi automatisoida, ja mitkä päätökset tulisi jättää kokeneiden insinöörien vastuulle?

Katselmus ja tarkistus ovat jo muuttuneet pullonkaulaksi. Itse asiassa meidän 2026 State of Code -kehittäjäkysely osoitti, että tiimit raportoivat käyttävänsä noin neljännes työviikosta tekoälyn tuottaman koodin tarkistamiseen ja korjaamiseen. Tästä ei ole yllätys, että vain 48 % kehittäjistä tarkistaa aina tekoälyn tuottaman koodin ennen sen sitomista, vaikka suurin osa (96 %) ei täysin luota sen toiminnalliseen oikeellisuuteen.

Automatisoitava työ on mekaanista ja epämiellyttävää: CI‑epäonnistumisen juurisyyn selvittäminen, jotta kukaan ei joudu lukemaan neljää tuhatta lokiriviä, päätöksen tekeminen siitä, koskeeko löydös edelleen uudelleenasennuksen jälkeen, epäonnistumisen toistaminen, ilmiselvän korjauksen kirjoittaminen. Insinöörien tulisi pitää kiinni tarkoituksesta, suunnittelusta ja siitä, kuinka paljon todistusaineistoa tarvitaan tietylle muutokselle. Kun seniori-insinööri viettää illan lokeja lukeen selvittääkseen, mikä yhdeksästä epäonnistumisesta on merkityksellinen, se on triagea, ei harkintaa, ja juuri tällainen työ tulisi ottaa pois heidän harteiltaan.

Tekoälypohjaiset koodikatselmukset voivat tunnistaa ongelmia, ehdottaa korjauksia ja validoida muutokset jatkuvan integraation putkistossa. Kuinka estät autonomisen korjausjärjestelmän aiheuttamasta regressioita tai keskittymistä ainoastaan onnistuneen buildin saavuttamiseen laajemman ohjelmiston laadun kustannuksella?

Tärkeintä on olla käsittelemättä vihreää (green) hyväksymiskriteerinä, koska läpäissevä build kertoo vain, että olemassa olevat testit eivät epäonnistuneet.

Suurin osa rajoituksista, jotka asetamme omaan korjausjärjestelmäämme, koskee laajuutta. Gitar korjaa CI‑virheitä, jotka ovat rikkoneet, ja tarkistaa, että sen omaan pushiin johtava commit oli vihreä ennen kuin se ottaa vastuulleen mitään. Se pysähtyy kahden jälkikommitin jälkeen sen sijaan, että jatkaisi punaisen buildin korjaamista. Kun epäonnistuminen ei liity muutokseen, esimerkiksi heikko testi tai infrastruktuurihäiriö, se ohjataan uudelleenyrittelypolkuun korjauspolun sijaan, koska “pysäytä testin epäonnistuminen” on tavoite, jota kykenevä agentti haluaa vähiten toteuttaa.

Sen jälkeen muutoksen on läpäistävä kerros, jota Gitar ei hallitse. SonarQube arvioi tuloksen omilla ehdoillaan, laatukäytävä on se, jonka perusteella yhdistäminen riippuu, ja tiimi omistaa kyseisen politiikan. Tarkistamme myös muutoksen sen tiketin kanssa, jonka se väittää toteuttavansa, pitäen vaatimusluonnin erillään toteutuspäätöksestä, jotta hiljaisesti tikettiin lisätty vaatimus ei pysty palaamaan toteutetuksi.

Tehokas tekoälykoodikatselmus edellyttää repositorion konventioiden, riippuvuuksien, arkkitehtuurin ja ehdotetun muutoksen tarkoituksen ymmärtämistä. Millainen konteksti tekoälykatselmukselle on tarpeen tehdä hyödyllisiä päätöksiä, ja miten organisaatiot voivat pitää tämän kontekstin ajan tasalla järjestelmiensä kehittyessä?

Sen on oltava riittävän laaja, jotta se pystyy ajattelevan kokeneen katselmoijan tavoin, ei pelkästään riittävä diffin lukemiseen. Tämä sisältää muutoksen tarkoituksen, relevantit koodipolut ja tyyppitiedon, riippuvuudet, testien käyttäytymisen, repositorion konventiot ja arkkitehtoniset rajat, joita tiimi odottaa muutoksen kunnioittavan.

Kontekstin on myös oltava koodin mukana. Pidä säännöt ja katselmusohjeet versionoituna repositoriossa, päivitä ne, kun palvelut tai konventiot muuttuvat, ja tee omistajuus selväksi arkkitehtonisissa ja politiikkapäätöksissä. Muuten tekoälykatselmus voi tuottaa yksilöllisesti järkevän ehdotuksen, joka on ristiriidassa sen kanssa, miten laajempi järjestelmä todellisuudessa toimii.

Deterministinen analyysi tuottaa johdonmukaisia ja auditointikelpoisia tuloksia, kun taas suurten kielimallien pohjainen katselmus voi vaihdella suoritusten välillä. Kuinka yritykset dokumentoivat, toistavat ja hallinnoivat tekoälyn tuottamia löydöksiä säädellyissä tai turvallisuuskriittisissä ympäristöissä?

Auditointijäljen tulee näyttää tarkasteltu muutos, tekoälylöydös, tehty päätös ja itsenäinen todiste, jonka avulla tulos vahvistettiin. Tiimit voivat käyttää tekoälyä katselmuksen ja korjauksen nopeuttamiseen, mutta pitää enforce‑ ja hyväksymispäätökset ankkuroituina määriteltyihin politiikkoihin ja ihmisten vastuuseen.

Mitkä mittarit tulisi insinöörijohtajien käyttää määrittääkseen, parantaako tekoälykoodikatselmus todella ohjelmistokehitystä? Pitäisikö heidän priorisoida katselmusten aika, vuotaneet virheet, vääräpositiivien määrä, jatkuvan integraation epäonnistumiset, tekninen velka, kehittäjien luottamus vai jokin muu mittari?

Aloita tuloksista, ei tekoälyjärjestelmän tuottamien kommenttien määrästä. Mittaisin aikaa pull‑requestista yhdistämiseen, aikaa CI‑epäonnistumisten diagnosointiin, sitä, kuinka usein korjaukset läpäisevät ensimmäisen validointiyrityksen, ja kuinka usein ongelmat päätyvät myöhempiin vaiheisiin tai tuotantoon.

Seuraavaksi tarkkaile laatusignaaleja, kuten vääräpositiivien ja hylkäysprosentteja, uudelleenavattuja tikettejä, äskettäin yhdistettyihin muutoksiin liittyviä regressioita ja kehittäjien palautetta siitä, ovatko löydökset toimivia. Oikea mittariseos vaihtelee tiimin mukaan, mutta kysymys on johdonmukainen: vähennämmekö uudelleentyötä ja katselmusodotusaikaa ilman, että alennamme turvallisen, luotettavan ohjelmiston laatukynnystä?

Kun katsot tulevaisuuteen, odotatko, että ohjelmistokehitys muuttuu jatkuvaksi silmukaksi, jossa agentit tuottavat, tarkistavat, testaavat ja korjaavat koodia determinististen suojarajojen alla? Millä tavoin ihmisten ohjelmistosuunnittelijoiden vastuut ja tarvittavat taidot muuttuvat tällaisessa ympäristössä?

Tuo silmukka on jo olemassa, ja tiimit omaksuvat sen kiinteässä järjestyksessä: ensin havaitseminen, sitten korjaus, sitten hyväksyntä ehtojen mukaisesti, jotka ne kirjoittavat ylös, ja lopuksi yhdistäminen. Kukaan ei hyppää suoraan viimeiseen vaiheeseen, ja edistymisen osoittavat heidän omat koodikannat, ei vertailuarvot. Yhdistäminen on minua eniten kiinnostava vaihe, koska konfliktien tiheys kasvaa commit‑läpäisyn myötä, ja läpäisy on juuri se, mitä kaikki tämä lisää.

Arvokkaiksi nousevat taidot sijaitsevat silmukan ympärillä, eivät sen sisällä. Ongelman ja sen rajoitusten tarkka määrittely on tärkeämpää, kun agentti ottaa kuvauksesi kirjaimellisesti. Samoin se, mitä todisteita pidetään riittävinä muutoksen läpäisemiseksi, oli aiemmin ihmisten mielessä tapana, ja nyt se täytyy kirjata politiikaksi, jonka automaatio voi toteuttaa. Loput ovat järjestelmäsuunnittelua: rajataan, mitä automatisoitu työ voi koskea, varmistetaan, että agentti, jota ei hallita, tarkistaa tuloksen, ja pidetään se jäljitettävänä, kun se menee pieleen. Insinöörit käyttävät vähemmän aikaa toteutuksen tuottamiseen ja enemmän aikaa päättääkseen, mitä tulisi olla olemassa ja mikä toimii todisteena sen toimivuudesta.

Kiitos erinomaisesta haastattelusta, lukijat, jotka haluavat oppia lisää, kannattaa vierailla Sonar.