Gautam Korlam, hlavní inženýr ve společnosti Sonar – série rozhovorů

Gautam Korlam, hlavní inženýr ve společnosti Sonar, je veterán softwarového inženýrství a technologický lídr, jehož kariéra se soustředila na infrastrukturu vývojářů, kvalitu kódu, automatizaci a AI‑asistovaný vývoj softwaru. Před nástupem do Sonaru spoluzaložil Gitar a působil jako CTO, kde vybudoval platformu nativní pro AI určenou k automatizaci revize kódu, diagnostice selhání kontinuální integrace (CI), identifikaci příčin a generování oprav. Sonar v květnu 2026 odkoupil Gitar, přičemž Korlam a tým Gitar se připojili k firmě, aby pokračovali ve vývoji technologie jako součást širší platformy pro ověřování kódu Sonaru. Před Gitarem strávil Korlam téměř deset let v Uberu, kde postupoval od zakládajícího inženýra v týmu mobilní platformy po hlavního inženýra. Během svého působení pomáhal budovat a škálovat centralizovanou infrastrukturu vývojářů Uberu, vedl významné iniciativy monorepo a build‑systémů, vyvíjel vzdálená vývojářská prostředí a nástroje CI/CD a experimentoval s open‑source velkými jazykovými modely jako StarCoder, OctoCoder a Code Llama s cílem zlepšit AI‑asistované programování v kódu Uberu. Jeho dřívější zkušenosti zahrnují inženýrské role ve společnosti Lookout a výzkumnou činnost na UC Santa Barbara, stejně jako stáže u Microsoftu a Oracle.

Sonar je softwarová společnost zaměřená na ověřování kódu, automatizovanou revizi kódu, kvalitu kódu a bezpečnost aplikací. Její vlajková platforma SonarQube analyzuje kód napsaný vývojáři i generovaný AI, aby identifikovala chyby, zranitelnosti, problémy udržovatelnosti a další problémy kvality ještě před nasazením do produkce, přičemž nabízí řešení pro cloud, samostatně spravované prostředí i workflow integrovaných vývojových prostředí. Sonar uvádí, že její technologie používá více než 7 milionů vývojářů a 22 000 zákazníků a denně analyzuje více než 750 miliard řádků kódu. Akvizice Gitar rozšířila tento přístup o AI‑nativní revizi kódu a opravy, kombinující ověřovací engine SonarQube s agentními nástroji schopnými revidovat kód, zkoumat selhání CI a navrhovat či aplikovat opravy, jak se vývoj softwaru stále více řídí AI.

Vaše kariéra vás zavedla od budování mobilní a vývojářské infrastruktury v Uberu po trénování open‑source velkých jazykových modelů na jeho kódu, než jste spoluzaložil Gitar a po akvizici se připojil k Sonaru. Jak tyto zkušenosti formovaly vaše přesvědčení, že generování kódu je jen částí výzvy a že spolehlivé ověření může být těžší problém?

V Uberu jsem pracoval na částech systému, které rozhodují, zda něco bude nasazeno: monorepo, build, fronta CI, testovací sada. Zjednodušení tvorby změn přenáší veškerý tlak na tuto infrastrukturu. Dostáváte více služeb, které spolu interagují nečekanými způsoby, a více inženýrů čekajících, jestli je jejich změna bezpečná ke sloučení.

Později jsem pracoval na trénování modelů na našem vlastním kódu, kde se asymetrie stala zřejmou. Model dokáže rychle vytvořit věrohodnou implementaci. Prokázat, že implementace zapadá do živého produkčního systému, dodržuje konvence, které tým skutečně používá, a neporuší něco v jiných dvou službách, trvá mnohem déle a většina této práce končí u lidí. Gitar z toho vzešel a ladí s tím, co Sonar dělá z analytické stránky už více než sedmnáct let.

Argumentujete, že AI revize kódu by měla doplňovat deterministickou analýzu, nikoli ji nahrazovat. Jaké typy problémů jsou nejlépe odhaleny opakovatelnou, pravidly řízenou analýzou, a kde může AI nabídnout schopnosti, které tradiční techniky nemohou?

Pravidly řízená analýza je vhodná, když je vlastnost rozhodnutelná přímo z kódu. Kontaminovaný vstup dosahující sinku, nulová dereference na cestě, kterou někdo přehlédl, pevně zakódované pověření, závislost s známou CVE, import, který překračuje vrstvu, kterou by neměl. Dostanete stejnou odpověď při každém spuštění a můžete ukázat důvod, proč se spustila, což je důvod, proč by se vynucení mělo nacházet na této úrovni.

Co pravidla nepokrývají, je záměr. Žádný parser vám neřekne, že uživatelský řetězec bude nejasný pro překladatele, nebo že změna tvrdí, že uzavře tiket, zatímco implementuje jen polovinu požadavků, nebo že nová smyčka opakování koliduje se způsobem, jakým zbytek služby zvládá zpětný tlak. Model, který čte diff spolu s připojeným problémem a kontextem celého kódu, tyto věci vyzdvihne a měly by se objevit jako nálezy, které člověk zkontroluje, spíše než jako rozhodnutí.

Systémy AI dokážou posoudit obchodní logiku, záměr vývojáře a architektonické kompromisy, ale jejich závěry jsou pravděpodobnostní. Jak mohou vývojové týmy těžit z tohoto kontextového uvažování, aniž by považovaly výstup AI recenzenta za inherentně správný?

AI revize si zaslouží místo u problémů, které konvenční kontroly přehlížejí: logické chyby, chování neodpovídající deklarovanému záměru, změna, která vypadá v pořádku samostatně, ale je špatná pro konkrétní systém. Tyto závěry jsou pravděpodobnostní, takže patří do vstupu pro rozhodnutí, nikoli jako samotné rozhodnutí. Týmy udržují tuto hranici tím, že zachovávají deterministické kontroly před sloučením, což zahrnuje automatizované testy, validaci CI, skenování bezpečnosti, kontrolu politik a člověka, který změnu vlastní. AI může navrhovat opravy nebo je implementovat v rámci omezení nastavených týmem, pokud tyto změny projdou stejnou verifikací jako cokoli, co napsal člověk, a nebudou mít výhodu jen proto, že jsou generovány strojem.

Stejnou hranici uplatňujeme i v naší vlastní implementaci. Model navrhuje nálezy a výsledek revize je vypočítán v kódu ze stavu těchto nálezů. Řešení funguje stejným způsobem. Když kód za nálezem zmizí z diffu, jedná se o deterministickou kontrolu vůči parsovanému diffu a model nemá povoleno zrušit řešení toho, co diff již opravil.

Obecně jde o to, aby pravděpodobnostní vrstva dostala úkoly, kde je chyba opravitelna, udržet stavový stroj deterministický a zodpovědnost nechat na týmu. Důvěru získává důkaz, že někdo může kontrolovat a inspektovat chování, které je stejné při každém běhu.

Sonar kombinuje kontextově uvědomělé revize pull requestů s deterministickou analýzou a quality gates. Jak vypadá efektivní vícevrstvá verifikační proces a jak by měly různé vrstvy spolupracovat, aniž by duplikovaly práci nebo zahlcovaly vývojáře nálezy?

Deterministická analýza a quality gates nesou věci, které nejsou předmětem vyjednávání, a jsou tím, co blokuje sloučení. Kontextová revize přebírá rozhodovací úkony, zda změna dělá to, co slibuje, zda zapadá do kódu a zda je dané riziko dostatečně podstatné pro pozornost člověka.

Zeď nálezů je ignorována zhruba stejně často jako absence nálezů. Provádíme deduplikaci napříč recenzenty dříve, než se něco dostane k autorovi, odhazujeme kandidáty, které nelze ověřit, a soustředíme se na nálezy s vysokým signálem. Na straně pravidel predikát rozhoduje, zda se pravidlo vztahuje na aktuální diff před spuštěním jakéhokoli modelu, takže většina pravidel nic nestojí u většiny změn. Vše se zobrazí v pull requestu, který vývojář již má otevřený.

Jak kódovací agenti vytvářejí více kódu a pull requestů, může se revize a verifikace softwaru stát novou úzkou hrudkou? Které části revizního procesu by měly být automatizovány a které rozhodnutí by měla zůstat na zkušených inženýrech?

Revize a verifikace se již staly úzkou hrudkou. Ve skutečnosti naše průzkum vývojářů State of Code 2026 zjistil, že týmy uvádějí, že stráví přibližně čtvrtinu pracovního týdne kontrolou a opravou výstupů AI. Není tedy překvapením, že jen 48 % vývojářů vždy kontroluje AI‑generovaný kód před jeho odesláním, přestože většina (96 %) plně nedůvěřuje jeho funkční správnosti.

Práce, která stojí za automatizaci, je mechanická a nepříjemná: seskupování selhání CI k hlavní příčině, aby nikdo nečetl čtyřtisíc řádků logů, rozhodování, zda nález stále platí po rebase, reprodukce selhání, psaní zřejmé opravy. Inženýři by měli zachovat záměr, design a rozhodnutí, kolik důkazů stačí pro konkrétní změnu. Když seniorní inženýr stráví večer čtením logů, aby zjistil, který z devíti selhání je podstatný, jde o triáž, nikoli o úsudek, a právě taková práce by jim měla být ušetřena.

Systémy AI revize kódu mohou identifikovat problémy, navrhovat opravy a ověřovat tyto změny vůči pipeline kontinuální integrace. Jak zabráníte autonomnímu systému oprav, aby zaváděl regresy nebo optimalizoval úzce pro úspěšný build místo širší kvality softwaru?

Hlavní věc je odmítnout považovat zelenou (úspěšný build) za kritérium přijetí, protože úspěšný build jen říká, že existující testy neuspěly.

Většina omezení, která klademe na vlastní opravy, se týká rozsahu. Gitar opravuje CI, které selhalo, a kontroluje, že commit před jeho vlastním pushnutím byl zelený, než si přisvojí jakoukoli odpovědnost. Zastaví se po dvou následných commitech místo toho, aby se neustále zabýval červeným buildem. Když selhání nemá nic společného se změnou, jde o flákající test nebo infra výpadek, který jde po cestě opakování místo cesty opravy, protože „zastavit selhání testu“ je cíl, který chcete, aby schopný agent nesledoval.

Poté musí změna projít vrstvou, kterou Gitar neovládá. SonarQube vyhodnocuje výsledek podle svých podmínek, quality gate je to, na čem sloučení závisí, a tým vlastní tuto politiku. Také kontrolujeme změnu vůči problému, který má implementovat, přičemž extrakce požadavků je oddělena od rozhodnutí o dokončení, takže požadavek, který tiše opustil tiket, se nemůže vrátit jako implementovaný.

Efektivní AI revize kódu závisí na pochopení konvencí, závislostí, architektury a účelu navrhované změny v repozitáři. Jaký kontext potřebuje AI recenzent k tomu, aby učinil užitečná rozhodnutí, a jak mohou organizace udržet tento kontext přesný, když se jejich systémy vyvíjejí?

Potřebuje dostatek kontextu k uvažování jako zkušený recenzent, ne jen k přečtení diffu. To zahrnuje účel změny, relevantní cesty kódu a typové informace, závislosti, chování testů, konvence repozitáře a architektonické hranice, které tým očekává, že změna bude respektovat.

Kontext také musí žít spolu s kódem. Uchovávejte pravidla a pokyny pro revizi verzované v repozitáři, aktualizujte je, když se služby nebo konvence mění, a jasně definujte odpovědnost za architektonická a politická rozhodnutí. Jinak může AI recenzent vytvořit samostatně věrohodný návrh, který je v rozporu s tím, jak celkový systém skutečně funguje.

Deterministická analýza poskytuje konzistentní a auditovatelné výsledky, zatímco revize založená na velkých jazykových modelech může mezi běhy kolísat. Jak by podniky měly dokumentovat, reprodukovat a řídit AI‑generované nálezy v regulovaných nebo bezpečnostně citlivých prostředích?

Auditní stopa by měla ukazovat revizi změny, AI nález, přijaté rozhodnutí a nezávislé důkazy použité k ověření výsledku. Týmy mohou využívat AI k urychlení revize a oprav, přičemž zachovávají vynucování a rozhodnutí o schválení ukotvená v definovaných politikách a lidské odpovědnosti.

Jaké metriky by měli vedoucí inženýrství používat k určení, zda AI revize kódu skutečně zlepšuje vývoj softwaru? Měly by upřednostňovat čas revize, uniklé chyby, míru falešných poplachů, selhání kontinuální integrace, technický dluh, důvěru vývojářů nebo jiné ukazatele?

Začněte s výsledky, ne s počtem komentářů, které AI systém vytvoří. Měřil bych čas od pull requestu po sloučení, čas strávený diagnostikou selhání CI, míru, s jakou opravy projdou při prvním pokusu o validaci, a jak často problémy uniknou do pozdějších fází nebo do produkce.

Poté sledujte ukazatele kvality, jako jsou míry falešných poplachů a odmítnutí, znovuotevřené problémy, regresy spojené s nedávno sloučenými změnami a zpětnou vazbu vývojářů, zda jsou nálezy použitelné. Správná kombinace metrik se liší podle týmu, ale otázka zůstává stejná: snižujeme přepracování a čekací dobu na revizi, aniž bychom snižovali laťku pro bezpečný, spolehlivý software?

Do budoucna očekáváte, že vývoj softwaru se stane kontinuální smyčkou, ve které agenti generují, revidují, testují a opravují kód pod deterministickými zábranami? Jak se v takovém prostředí změní odpovědnosti a požadované dovednosti lidských softwarových inženýrů?

Tato smyčka již existuje a týmy ji obvykle přijímají ve stanoveném pořadí: nejprve detekce, pak oprava, následně schválení za podmínek, které si zapíší, a nakonec sloučení. Nikdo nepřeskočí rovnou na poslední krok a důkazem, který je posouvá vpřed, je jejich vlastní kódová základna, nikoli benchmark. Sloučení je krok, který mě nejvíce zajímá, protože frekvence konfliktů roste s objemem commitů a právě tento objem vše zvyšuje.

Dovednosti, které získávají na hodnotě, se nacházejí kolem smyčky, nikoli uvnitř ní. Být přesný ohledně problému a jeho omezení má větší význam, když agent doslovně vezme váš popis. Stejně tak rozhodování, jaký důkaz je dostatečný k povolení změny, což dříve žilo v hlavách lidí jako zvyk, a nyní musí být zaznamenáno jako politika, kterou může automatizace aplikovat. Zbytek je návrh systémů: ohraničení toho, co může automatizovaná práce zasáhnout, mít něco, co agent neovládá, kontrolovat výsledek, a zachovat odpovědnost, když se něco pokazí. Inženýři budou trávit méně času vytvářením implementace a více času rozhodováním, co by mělo existovat a co bude považováno za důkaz, že to funguje.

Děkujeme za skvělý rozhovor, čtenáři, kteří se chtějí dozvědět více, by měli navštívit Sonar.