Gautam Korlam, główny inżynier w Sonar – seria wywiadów

Gautam Korlam, główny inżynier w Sonar, jest doświadczonym inżynierem oprogramowania i liderem technologicznym, którego kariera koncentrowała się na infrastrukturze deweloperskiej, jakości kodu, automatyzacji oraz wspomaganym przez AI tworzeniu oprogramowania. Przed dołączeniem do Sonar współzałożył Gitar i pełnił funkcję CTO, budując platformę natywną dla AI, zaprojektowaną do automatyzacji przeglądu kodu, diagnozowania awarii ciągłej integracji (CI), identyfikowania przyczyn źródłowych i generowania poprawek. Sonar przejęło Gitar w maju 2026 roku, a Korlam i zespół Gitar dołączyli do firmy, aby kontynuować rozwój technologii w ramach szerszej platformy weryfikacji kodu Sonar. Przed Gitar Korlam spędził prawie dekadę w Uberze, awansując od inżyniera założyciela w zespole platformy mobilnej do głównego inżyniera. W trakcie swojej pracy pomógł zbudować i skalować scentralizowaną infrastrukturę deweloperską Ubera, prowadził duże inicjatywy monorepo i systemu budowania, opracował zdalne środowiska deweloperskie oraz narzędzia CI/CD, a także eksperymentował z otwarto‑źródłowymi dużymi modelami językowymi, takimi jak StarCoder, OctoCoder i Code Llama, aby usprawnić kodowanie wspomagane AI w bazie kodu Ubera. Wcześniejsze doświadczenia obejmują role inżynierskie w Lookout oraz pracę badawczą na UC Santa Barbara, a także staże w Microsoft i Oracle.

Sonar to firma programistyczna skoncentrowana na weryfikacji kodu, automatycznym przeglądzie kodu, jakości kodu i bezpieczeństwie aplikacji. Jej flagowa platforma SonarQube analizuje kod tworzony przez programistów oraz generowany przez AI, aby wykrywać błędy, luki bezpieczeństwa, problemy z utrzymaniem i inne kwestie jakościowe, zanim trafią do produkcji. Oferta obejmuje rozwiązania w chmurze, samodzielnie zarządzane oraz zintegrowane z środowiskami programistycznymi. Sonar twierdzi, że jej technologia jest używana przez ponad 7 milionów programistów i 22 000 klientów oraz że codziennie analizuje ponad 750 miliardów linii kodu. Przejęcie Gitar rozszerzyło to podejście o natywny dla AI przegląd i naprawę kodu, łącząc silnik weryfikacji SonarQube z narzędziami agentowymi zdolnymi do przeglądania kodu, badania awarii CI oraz proponowania lub stosowania poprawek w coraz bardziej AI‑napędzonym procesie tworzenia oprogramowania.

Twoja kariera przeniosła Cię od budowania infrastruktury mobilnej i deweloperskiej Ubera, przez trenowanie otwarto‑źródłowych dużych modeli językowych na jego bazie kodu, po współzałożenie Gitar i dołączenie do Sonar po przejęciu. Jak te doświadczenia ukształtowały Twoje przekonanie, że generowanie kodu to tylko część wyzwania, a wiarygodna weryfikacja może być trudniejszym problemem?

W Uberze pracowałem nad częściami systemu, które decydują, czy cokolwiek zostanie wypuszczone: monorepo, proces budowania, kolejka CI, zestaw testów. Ułatwienie wprowadzania zmian przenosi całe obciążenie na tę maszynerię. Powstaje więcej usług współdziałających w nieprzewidziany sposób i więcej inżynierów czeka, aby dowiedzieć się, czy ich zmiana jest bezpieczna do scalenia.

Później pracowałem nad trenowaniem modeli na naszej własnej bazie kodu, co uwidoczniło asymetrię. Model może szybko wygenerować wiarygodną implementację. Udowodnienie, że implementacja pasuje do działającego systemu produkcyjnego, spełnia konwencje zespołu i nie psuje czegoś w innym serwisie, zajmuje znacznie więcej czasu i większość tej pracy spada na ludzi. Z tego wynikło Gitar, które wpisuje się w to, co Sonar robi od ponad siedemnastu lat po stronie analizy.

Twierdzisz, że przegląd kodu AI powinien uzupełniać deterministyczną analizę, a nie ją zastępować. Jakie rodzaje problemów najlepiej wykrywa powtarzalna, regułowa analiza, a gdzie AI może dostarczyć możliwości, których tradycyjne techniki nie zapewniają?

Analiza oparta na regułach jest właściwym narzędziem, gdy własność jest rozstrzygalna na podstawie samego kodu. Zanieczyszczone wejście docierające do ujścia, dereferencja null w nieprzewidzianej ścieżce, twardo zakodowane poświadczenia, zależność z znanym CVE, import przekraczający warstwę, której nie powinien. Otrzymujesz tę samą odpowiedź przy każdym uruchomieniu i możesz wskazać powód wyzwolenia, dlatego egzekwowanie należy do tej warstwy.

To, czego reguły nie obejmują, to intencja. Żaden parser nie powie Ci, że łańcuch widoczny dla użytkownika będzie dwuznaczny dla tłumacza, że zmiana deklaruje zamknięcie zgłoszenia, a jednocześnie implementuje tylko połowę żądania, lub że nowa pętla ponawiania koliduje z tym, jak reszta usługi radzi sobie z presją zwrotną. Model, który czyta diff wraz z powiązanym zgłoszeniem i pełnym kontekstem kodu, podniesie te kwestie i powinny one pojawić się jako znaleziska, które człowiek sprawdza, a nie jako ostateczne werdykty.

Systemy AI mogą oceniać logikę biznesową, intencje dewelopera i kompromisy architektoniczne, ale ich wnioski są probabilistyczne. Jak zespoły deweloperskie mogą korzystać z takiego rozumowania kontekstowego, nie traktując wyników recenzenta AI jako z natury poprawnych?

Recenzja AI znajduje swoje miejsce przy problemach, które tradycyjne kontrole pomijają: błędy logiki, zachowanie niezgodne z zamierzoną intencją, zmiana, która wygląda poprawnie w izolacji, a jest nieprawidłowa w konkretnym systemie. Te wnioski są probabilistyczne, więc stanowią wejście do decyzji, a nie samą decyzję. Zespoły utrzymują tę granicę, zachowując deterministyczne kontrole przed scalceniem, czyli automatyczne testy, weryfikację CI, skanowanie bezpieczeństwa, kontrole polityk oraz człowieka odpowiedzialnego za zmianę. AI może proponować poprawki lub wprowadzać je w ramach wytyczonych barier, pod warunkiem że zmiany przejdą tę samą weryfikację co kod napisany ręcznie i nie otrzymają przywileju za to, że zostały wygenerowane przez maszynę.

Stosujemy tę samą granicę w naszej własnej implementacji. Model proponuje znaleziska, a werdykt przeglądu jest obliczany w kodzie na podstawie stanu tych znalezisk. Rozwiązanie działa analogicznie. Gdy kod stojący za znaleziskiem znika z diffu, jest to deterministyczna kontrola przeciwko sparsowanemu diffowi i model nie może odwrócić tego, co diff już naprawił.

Ogólna zasada polega na przydzieleniu warstwy probabilistycznej zadaniom, w których błąd jest odzyskiwalny, utrzymaniu deterministycznego stanu maszyny i pozostawieniu odpowiedzialności przy zespole. Zaufanie buduje się na dowodach, które ktoś może sprawdzić i które zachowują się tak samo przy każdym uruchomieniu.

Sonar łączy kontekstowo świadome przeglądy pull requestów z deterministyczną analizą i bramkami jakości. Jak wygląda efektywny, wielowarstwowy proces weryfikacji i jak różne warstwy powinny ze sobą współdziałać, nie dublując pracy ani nie przytłaczając deweloperów znaleziskami?

Deterministyczna analiza i bramki jakości obejmują elementy niepodlegające negocjacjom i to właśnie one blokują scalenie. Przegląd kontekstowy zajmuje się oceną, czy zmiana robi to, co deklaruje, czy pasuje do kodu i czy dany ryzyko jest warte uwagi człowieka.

Ściana znalezisk zostaje zignorowana w przybliżeniu tak często, jak brak jakichkolwiek znalezisk. Dedupujemy wyniki między recenzentami, zanim trafią do autora, odrzucamy kandydatów, których nie możemy zweryfikować, i koncentrujemy się na znaleziskach o wysokim sygnale. Po stronie reguł predykat decyduje, czy reguła ma zastosowanie do bieżącego diffu, zanim uruchomi się jakikolwiek model, więc większość reguł nie kosztuje nic przy większości zmian. Wszystko to wyświetlane jest w pull requeście, który deweloper już ma otwarty.

W miarę jak agenci kodujący generują coraz więcej kodu i pull requestów, czy przegląd i weryfikacja oprogramowania nie staną się nowym wąskim gardłem? Które części procesu przeglądu powinny być automatyzowane, a które decyzje powinny pozostać w rękach doświadczonych inżynierów?

Przegląd i weryfikacja już stały się wąskim gardłem. W rzeczywistości nasz raport State of Code Developer Survey 2026 wykazał, że zespoły spędzają około jedną czwartą tygodnia pracy na sprawdzaniu i naprawianiu wyników AI. Nic więc dziwnego, że tylko 48 % programistów zawsze sprawdza kod generowany przez AI przed jego zatwierdzeniem, mimo że większość (96 %) nie ufa w pełni jego funkcjonalnej poprawności.

Warto automatyzować prace mechaniczne i nieprzyjemne: grupowanie awarii CI do przyczyny źródłowej, aby nikt nie musiał przeglądać czterech tysięcy linii logów, decydowanie, czy znalezisko nadal obowiązuje po rebase, odtwarzanie awarii, pisanie oczywistej poprawki. Inżynierowie powinni zachować kontrolę nad intencją, projektem i decyzją, ile dowodów jest wystarczających dla konkretnej zmiany. Gdy starszy inżynier spędza wieczór na przeglądaniu logów, aby ustalić, która z dziewięciu awarii ma znaczenie, jest to triage, a nie ocena, i właśnie taką pracę powinniśmy im odciążyć.

Systemy przeglądu kodu AI mogą identyfikować problemy, proponować poprawki i weryfikować te zmiany w potoku ciągłej integracji. Jak zapobiec, by autonomiczny system naprawczy nie wprowadzał regresji lub nie optymalizował jedynie pod kątem udanego buildu, a nie szerszej jakości oprogramowania?

Najważniejsze jest odmówienie traktowania zielonego statusu jako jedynego kryterium akceptacji, ponieważ przejście testów jedynie świadczy, że istniejące testy nie zawiodły.

Większość ograniczeń, które nakładamy na własne naprawy, dotyczy zakresu. Gitar naprawia CI, które się zepsuło, i sprawdza, czy commit przed własnym push’em był zielony, zanim weźmie na siebie jakąkolwiek odpowiedzialność. Zatrzymuje się po dwóch kolejnych commitach, zamiast walczyć z czerwonym buildem. Gdy awaria nie ma związku ze zmianą – jest to test flaky lub chwilowy problem infrastruktury – podąża ścieżką ponownej próby, a nie ścieżką naprawy, ponieważ „spraw, by test przestał nie działać” jest celem, którego nie chcemy, aby zdolny agent realizował.

Po tym zmianę musi przejść warstwa, której Gitar nie kontroluje. SonarQube ocenia wynik na własnych warunkach, bramka jakości jest tym, od czego zależy scalenie, a zespół zarządza tą polityką. Sprawdzamy także, czy zmiana odpowiada zgłoszeniu, które ma implementować, przy czym wydobywanie wymagań jest oddzielone od oceny zakończenia, tak aby wymaganie, które cicho zniknęło z ticketa, nie mogło zostać zwrócone jako zrealizowane.

Skuteczny przegląd kodu AI wymaga zrozumienia konwencji repozytorium, zależności, architektury i celu proponowanej zmiany. Jakiego kontekstu potrzebuje recenzent AI, aby podejmować użyteczne decyzje, i jak organizacje mogą utrzymać ten kontekst aktualny w miarę rozwoju systemów?

Potrzebuje wystarczającego kontekstu, aby rozumować jak doświadczony recenzent, nie tylko aby przeczytać diff. Obejmuje to cel zmiany, istotne ścieżki kodu i informacje o typach, zależności, zachowanie testów, konwencje repozytorium oraz granice architektoniczne, które zespół oczekuje, że zmiana będzie respektować.

Kontekst musi także współistnieć z kodem. Trzymaj reguły i wytyczne przeglądu wersjonowane w repozytorium, aktualizuj je, gdy usługi lub konwencje się zmieniają, i jasno określ odpowiedzialność za decyzje architektoniczne i polityczne. W przeciwnym razie recenzent AI może wygenerować indywidualnie sensowną sugestię, która koliduje z rzeczywistym działaniem szerszego systemu.

Deterministyczna analiza dostarcza spójnych i audytowalnych wyników, podczas gdy przegląd oparty na dużych modelach językowych może różnić się między uruchomieniami. Jak przedsiębiorstwa powinny dokumentować, odtwarzać i zarządzać znaleziskami generowanymi przez AI w środowiskach regulowanych lub wrażliwych pod względem bezpieczeństwa?

Ścieżka audytu powinna pokazywać zmianę poddawaną przeglądowi, znalezisko AI, podjętą decyzję oraz niezależne dowody użyte do weryfikacji wyniku. Zespoły mogą wykorzystywać AI do przyspieszania przeglądu i napraw, jednocześnie utrzymując egzekwowanie i decyzje zatwierdzające zakotwiczone w zdefiniowanych politykach i ludzkiej odpowiedzialności.

Jakie metryki powinni stosować liderzy inżynierii, aby określić, czy przegląd kodu AI rzeczywiście usprawnia rozwój oprogramowania? Czy powinni priorytetyzować czas przeglądu, liczbę wyciekłych defektów, wskaźniki fałszywych alarmów, awarie CI, dług techniczny, zaufanie deweloperów czy inne miary?

Zacznij od rezultatów, a nie od liczby komentarzy generowanych przez system AI. Mierzyłbym czas od pull requestu do scalenia, czas spędzony na diagnozowaniu awarii CI, wskaźnik, jak często poprawki przechodzą przy pierwszej próbie weryfikacji, oraz jak często problemy przedostają się do późniejszych etapów lub produkcji.

Następnie obserwuj sygnały jakości, takie jak wskaźniki fałszywych alarmów i odrzuceń, ponowne otwieranie zgłoszeń, regresje powiązane z niedawno scalonymi zmianami oraz opinie deweloperów na temat przydatności znalezisk. Odpowiednia mieszanka metryk zależy od zespołu, ale pytanie pozostaje stałe: czy redukujemy powtórną pracę i czas oczekiwania na przegląd, nie obniżając jednocześnie poprzeczki dla bezpiecznego, niezawodnego oprogramowania?

Patrząc w przyszłość, czy spodziewasz się, że rozwój oprogramowania stanie się ciągłą pętlą, w której agenci generują, przeglądają, testują i naprawiają kod pod deterministycznymi zabezpieczeniami? W takim środowisku, jak zmienią się obowiązki i wymagane umiejętności ludzkich inżynierów oprogramowania?

Ta pętla już istnieje, a zespoły przyjmują ją w ustalonej kolejności: najpierw wykrywanie, potem naprawa, następnie zatwierdzenie według zapisanych warunków, a na końcu scalenie. Nikt nie przechodzi od razu do ostatniego kroku, a dowody, które posuwają ich do przodu, pochodzą z własnej bazy kodu, a nie z benchmarku. Scalenie jest dla mnie najciekawszym etapem, ponieważ częstotliwość konfliktów rośnie wraz ze wzrostem liczby commitów, a to właśnie zwiększa cały proces.

Umiejętności, które zyskują na wartości, znajdują się wokół pętli, a nie w jej wnętrzu. Precyzyjne określanie problemu i jego ograniczeń ma większe znaczenie, gdy agent przyjmuje Twoje opisy dosłownie. To samo dotyczy decydowania, jakie dowody są wystarczające, aby zmiana przeszła – kiedyś było to w głowach ludzi jako nawyk, a teraz musi być zapisane jako polityka, którą może zastosować automatyka. Reszta to projektowanie systemów: wyznaczanie granic, w które automatyczna praca może wchodzić, posiadanie czegoś, czego agent nie kontroluje, aby sprawdzić wynik, oraz utrzymanie możliwości przypisania odpowiedzialności, gdy coś pójdzie nie tak. Inżynierowie spędzą mniej czasu na tworzeniu implementacji, a więcej na decydowaniu, co powinno istnieć i co będzie dowodem, że działa.

Thank you for the great interview, readers who wish to learn more should visit Sonar.