Гаутам Корлам, головний інженер у Sonar — серія інтерв’ю

Gautam Korlam, головний інженер у Sonar, є досвідченим інженером‑програмістом і технологічним лідером, чия кар’єра зосереджена на інфраструктурі розробників, якості коду, автоматизації та AI‑підтримуваній розробці ПЗ. Перш ніж приєднатися до Sonar, він співзаснував Gitar і працював CTO, створюючи AI‑нативну платформу, призначену для автоматизації перегляду коду, діагностики збоїв безперервної інтеграції (CI), виявлення причин та генерації виправлень. Sonar придбала Gitar у травні 2026 р., і Корлам разом із командою Gitar приєдналися до компанії, щоб продовжити розробку технології в рамках ширшої платформи верифікації коду Sonar. До Gitar Корлам провів майже десятиліття в Uber, піднімаючись від інженера‑засновника команди мобільної платформи до головного інженера. Під час роботи він допомагав будувати та масштабувати централізовану інфраструктуру розробників Uber, керував великими ініціативами щодо монорепозиторію та системи збірки, розробляв віддалені середовища розробників і інструменти CI/CD, а також експериментував з відкритими великими мовними моделями, такими як StarCoder, OctoCoder та Code Llama, щоб покращити AI‑підтримуване кодування у кодовій базі Uber. Раніше він працював інженером у Lookout та займався дослідженнями в UC Santa Barbara, а також проходив стажування в Microsoft та Oracle.

Sonar — це компанія, що зосереджена на верифікації коду, автоматизованому перегляді коду, якості коду та безпеці застосунків. Її головна платформа SonarQube аналізує код, написаний розробниками, і AI‑згенерований код, щоб виявляти помилки, уразливості, проблеми підтримуваності та інші питання якості ще до виходу в продакшн, пропонуючи рішення для хмари, самостійного розгортання та інтеграції в середовища розробки. Sonar стверджує, що її технологія використовується понад 7 мільйонами розробників і 22 000 клієнтів, а також аналізує понад 750 млрд рядків коду щодня. Придбання Gitar розширило цей підхід, додавши AI‑нативний перегляд коду та виправлення, поєднавши движок верифікації SonarQube з агентськими інструментами, здатними переглядати код, досліджувати збої CI та пропонувати або застосовувати виправлення в умовах, коли розробка все більше керується AI.

Ваша кар’єра пройшла шлях від створення мобільної та інфраструктурної платформи Uber до навчання відкритих великих мовних моделей на її кодовій базі, після чого ви співзаснували Gitar і приєдналися до Sonar після її придбання. Як ці досвіди сформували вашу віру в те, що генерування коду — лише частина виклику, а надійна його валідація може бути складнішою проблемою?

У Uber я працював над частинами системи, які вирішують, чи хтось може випускати зміни: монорепозиторій, збірка, черга CI, тестовий набір. Спрощення процесу створення змін переносить весь тиск на цю інфраструктуру. З’являються нові сервіси, взаємодії яких ніхто не передбачав, і більше інженерів чекають, чи їхня зміна безпечна для злиття.

Пізніше я працював над навчанням моделей на нашій власній кодовій базі, і саме тоді асиметрія стала очевидною. Модель могла швидко згенерувати правдоподібну реалізацію. Показати, що ця реалізація підходить живій продакшн‑системі, відповідає конвенціям команди і не ламає інші сервіси, займало набагато більше часу, і більша частина цієї роботи падала на людей. Gitar виникла саме з цього, і вона узгоджується з тим, що Sonar робить у сфері аналізу вже понад сімнадцять років.

Ви стверджували, що AI‑перегляд коду має доповнювати детерміністичний аналіз, а не заміняти його. Які типи проблем найкраще виявляються за допомогою повторюваного, правил‑базованого аналізу, а де AI може надати можливості, недоступні традиційним методам?

Правил‑базований аналіз — правильний інструмент, коли властивість можна визначити безпосередньо з коду. Забруднений вхід, що потрапляє у «sink», null‑розіменування на шляху, який хтось пропустив, жорстко закодовані облікові дані, залежність з відомою CVE, імпорт, що порушує шар. Ви отримуєте однакову відповідь при кожному запуску і можете вказати причину спрацювання, тому саме на цьому рівні розташовується примусове застосування.

Те, чого правила не охоплюють, — це намір. Жоден парсер не підкаже, що рядок, орієнтований на користувача, буде неоднозначним для перекладача, або що зміна стверджує закрити тикет, реалізуючи лише половину вимог, або що новий цикл повторних спроб конфліктує з тим, як інша частина сервісу обробляє зворотний тиск. Модель, яка читає diff разом із пов’язаним тикетом і контекстом усієї кодової бази, підніме такі питання, і вони мають з’явитися як знахідки, які перевіряє людина, а не як остаточні рішення.

AI‑системи можуть оцінювати бізнес‑логіку, наміри розробників та архітектурні компроміси, але їхні висновки є ймовірнісними. Як команди розробки можуть скористатися цим контекстуальним міркуванням, не сприймаючи вихід AI‑рецензента як беззаперечно правильний?

AI‑перегляд заслуговує на місце в тих проблемах, які традиційні перевірки пропускають: логічні помилки, поведінка, що не відповідає заявленому наміру, зміна, яка виглядає коректною самостійно, але неправильна для конкретної системи. Ці висновки ймовірні, тому вони мають входити до вхідних даних рішення, а не бути самим рішенням. Команди підтримують цю межу, залишаючи детерміновані контролі перед злиттям — автоматичні тести, валідацію CI, сканування безпеки, політики та людину, відповідальну за зміну. AI може пропонувати виправлення або впроваджувати їх у межах встановлених командою захисних бар’єрів, за умови, що ці зміни проходять ту ж верифікацію, що й код, написаний людиною, і не отримують «знижки» за те, що їх згенерував машинний алгоритм.

Ми застосовуємо ту саму межу у власній реалізації. Модель пропонує знахідки, а вердикт перегляду обчислюється в коді на основі стану цих знахідок. Розв’язання працює аналогічно. Коли код, що стоїть за знахідкою, зникає з diff, це детермінована перевірка парсованого diff, і модель не має права «розв’язати» те, що вже виправлено.

Загальна ідея полягає в тому, щоб передати ймовірнісному шару завдання, де помилка може бути виправлена, залишити стан машини детермінованим і залишити відповідальність за результат команді. Довіру заробляє доказ, який можна інспектувати та контролювати, і який поводиться однаково при кожному запуску.

Sonar поєднує контекстно‑обізнаний перегляд pull‑request з детермінованим аналізом та quality gates. Яким виглядає ефективний багатошаровий процес верифікації, і як різні шари мають взаємодіяти, не дублюючи роботу та не перевантажуючи розробників знахідками?

Детермінований аналіз і quality gates охоплюють ті питання, які не підлягають обговоренню, і саме на них блокуються злиття. Контекстуальний перегляд бере на себе судження щодо того, чи зміна робить те, що обіцяє, чи підходить вона до кодової бази, і чи варто даний ризик уваги людини.

Стіна знахідок ігнорується приблизно так само часто, як і відсутність знахідок. Ми дедуплікуємо їх між рецензентами ще до того, як вони доходять до автора, відкидаємо кандидатів, які не можуть бути верифіковані, і зосереджуємось на знахідках з високим сигналом. На рівні правил предикат вирішує, чи застосовується правило до поточного diff, ще до запуску будь‑якої моделі, тому більшість правил не вимагає ресурсів на більшості змін. Усе це відображається у pull‑request, який розробник вже має відкритим.

Оскільки агенти‑кодери генерують все більше коду та pull‑request’ів, чи може процес перегляду та верифікації стати новим вузьким місцем? Які частини процесу перегляду варто автоматизувати, а які рішення мають залишатися за досвідченими інженерами?

Перегляд і верифікація вже стали вузьким місцем. Насправді, наш 2026 State of Code Developer Survey показав, що команди витрачають приблизно чверть робочого тижня на перевірку та виправлення виходу AI. Тому не дивно, що лише 48 % розробників завжди перевіряють AI‑згенерований код перед комітом, хоча більшість (96 %) не довіряє повністю його функціональній правильності.

Те, що варто автоматизувати, — це механічна та неприємна робота: групування збою CI до кореневої причини, щоб ніхто не читав чотири тисячі рядків логів, визначення, чи застосовується знахідка після ребейзу, відтворення збою, написання очевидного виправлення. Інженери мають залишатися відповідальними за наміри, дизайн і рішення, скільки доказів достатньо для конкретної зміни. Коли старший інженер проводить вечір, читаючи логи, щоб зрозуміти, який із дев’яти збоїв важливий, це триаж, а не судження, і саме таку роботу слід відв’язати від них.

Системи AI‑перегляду коду можуть виявляти проблеми, пропонувати виправлення та валідувати ці зміни у конвеєрі безперервної інтеграції. Як запобігти тому, щоб автономна система ремедіації не вводила регресії або не оптимізувалась лише під успішну збірку, а не під загальну якість ПЗ?

Головне — відмовитися від трактування «зелений» як критерію прийняття, оскільки успішна збірка лише свідчить, що існуючі тести не зазнали провалу.

Більшість обмежень, які ми накладаємо на власну ремедіацію, стосуються області застосування. Gitar виправляє CI, який зламався, і перевіряє, що коміт перед її власним пушем був «зелений», перш ніж брати на себе відповідальність. Вона зупиняється після двох наступних комітів, а не продовжує працювати над червоною збіркою. Коли збій не має нічого спільного зі зміною — це «flaky» тест або інфраструктурна помилка — він йде по шляху повторної спроби, а не виправлення, бо «зупинити тест» не є ціллю, яку варто ставити перед здатним агентом.

Після цього зміна має пройти шар, який Gitar не контролює. SonarQube оцінює результат за власними критеріями, quality gate — це те, від чого залежить злиття, і команда володіє цією політикою. Ми також перевіряємо зміну щодо тикету, який вона стверджує реалізувати, при цьому виділення вимог відокремлено від оцінки завершеності, тому вимога, яка тихо залишилася в тикеті, не може повернутись як реалізована.

Ефективний AI‑перегляд коду потребує розуміння конвенцій репозиторію, залежностей, архітектури та мети запропонованої зміни. Якого контексту потребує AI‑рецензент, щоб приймати корисні рішення, і як організації можуть підтримувати актуальність цього контексту у міру еволюції своїх систем?

Йому потрібен достатній контекст, щоб мислити, як досвідчений рецензент, а не лише читати diff. Це включає мету зміни, релевантні шляхи коду та типову інформацію, залежності, поведінку тестів, конвенції репозиторію та архітектурні межі, які команда очікує, що зміна буде поважати.

Контекст також має існувати разом з кодом. Тримайте правила та рекомендації перегляду у версії репозиторію, оновлюйте їх, коли змінюються сервіси чи конвенції, і чітко визначайте відповідальність за архітектурні та політичні рішення. Інакше AI‑рецензент може створити окремо правдоподібну пропозицію, яка конфліктує з тим, як працює ширша система.

Детерміністичний аналіз дає послідовні та аудиторські результати, тоді як перегляд на базі великих мовних моделей може змінюватись між запусками. Як підприємства повинні документувати, відтворювати та керувати AI‑згенерованими знахідками в регульованих або безпечно‑чутливих середовищах?

Аудиторський журнал має показувати зміну, що переглядається, AI‑знахідку, прийняте рішення та незалежні докази, використані для валідації результату. Команди можуть використовувати AI для прискорення перегляду та виправлень, залишаючи примусове застосування та затвердження в межах визначених політик і людської відповідальності.

Які метрики мають використовувати лідери інженерії, щоб визначити, чи AI‑перегляд коду дійсно покращує розробку ПЗ? Чи варто їм пріоритетизувати час перегляду, кількість пропущених дефектів, рівень хибнопозитивних спрацьовувань, збої CI, технічний борг, довіру розробників чи інший показник?

Починайте з результатів, а не з кількості коментарів, які генерує AI‑система. Я б вимірював час від створення pull‑request до злиття, час, витрачений на діагностику збоїв CI, частку виправлень, які проходять першу валідацію, і частоту, з якою проблеми потрапляють у пізні етапи або продакшн.

Потім слід спостерігати за сигналами якості: рівень хибнопозитивних та відхилених знахідок, повторно відкриті тикети, регресії, пов’язані з нещодавно злитими змінами, і зворотний зв’язок розробників щодо того, чи є знахідки дієвими. Правильний набір метрик варіюється в залежності від команди, але питання залишається постійним: чи зменшуємо ми переробку та час очікування перегляду, не знижуючи планку безпечного, надійного ПЗ?

Дивлячись у майбутнє, чи очікуєте ви, що розробка ПЗ стане безперервним циклом, у якому агенти генерують, переглядають, тестують і виправляють код під детермінованими захисними бар’єрами? Яким чином у такому середовищі зміняться обов’язки та потрібні навички людських інженерів?

Такий цикл вже існує, і команди зазвичай впроваджують його у фіксованому порядку: спочатку виявлення, потім ремедіація, потім затвердження за умовами, які вони прописують, і нарешті злиття. Ніхто не переходить одразу до останнього кроку, а доказом, що їх рухає, є їхня власна кодова база, а не якийсь бенчмарк. Злиття — це крок, який мене найбільше цікавить, бо частота конфліктів зростає разом із швидкістю комітів, а саме це збільшує вся ця система.

Навички, що набувають цінність, розташовані навколо циклу, а не всередині нього. Точність у формулюванні проблеми та її обмежень важливі, коли агент бере ваш опис буквально. Так само важливо визначити, які докази достатньо, щоб пропустити зміну, що раніше існувало в головах людей як звичка, а тепер має бути задокументовано як політика, яку може застосовувати автоматизація. Решта — це дизайн системи: обмеження того, що автоматизована робота може торкатися, наявність механізму, який не контролює агент, для перевірки результату, і забезпечення його атрибутивності у випадку помилки. Інженери будуть менше часу витрачати на створення реалізації і більше — на визначення того, що має існувати, і що вважається доказом його працездатності.

Дякуємо за чудове інтерв’ю, читачі, які хочуть дізнатися більше, мають відвідати Sonar.