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

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

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

Ваша карьера привела вас от построения мобильной и инфраструктурной платформы Uber к обучению открытых больших языковых моделей на её кодовой базе, затем к со‑созданию Gitar и присоединению к Sonar после её приобретения. Как эти опыты сформировали ваше убеждение, что генерация кода — лишь часть задачи, а надёжная валидация кода может быть более сложной проблемой?

В Uber я работал над теми частями системы, которые решают, будет ли что‑то доставлено: монорепозиторий, сборка, очередь CI, набор тестов. Упрощение создания изменений перекладывает всю нагрузку на эту инфраструктуру. Появляется больше сервисов, взаимодействующих непредсказуемо, и больше инженеров, ожидающих, безопасно ли их изменение для слияния.

Позже я занимался обучением моделей на нашей собственной кодовой базе, и тогда асимметрия стала очевидной. Модель может быстро сгенерировать правдоподобную реализацию. Доказать, что эта реализация подходит живой продакшн‑системе, соответствует принятым в команде конвенциям и не ломает соседние сервисы, занимает гораздо больше времени, и большая часть этой работы ложится на людей. Gitar возникла из этого, и её подход совпадает с тем, чем Sonar занимается со стороны анализа уже более семнадцати лет.

Вы утверждаете, что AI‑обзор кода должен дополнять детерминированный анализ, а не заменять его. Какие типы проблем лучше выявляются повторяемым, правил‑основанным анализом, а где ИИ может предложить возможности, недоступные традиционным методам?

Правил‑основанный анализ подходит, когда свойство можно решить непосредственно из кода. Попадание загрязнённого ввода в уязвимое место, разыменование нулевого указателя по пропущенному пути, жёстко закодированные учётные данные, зависимость с известной CVE, импорт, нарушающий слой. Вы получаете одинаковый результат при каждом запуске и можете указать причину срабатывания, поэтому принудительное применение правил относится к этому уровню.

То, что правила не покрывают, — это намерение. Ни один парсер не подскажет, что пользовательская строка будет неоднозначна при переводе, или что изменение заявляет о закрытии тикета, реализуя лишь половину требований, или что новый цикл повторных попыток конфликтует с тем, как остальная служба обрабатывает обратное давление. Модель, читающая дифф вместе со связанным тикетом и полным контекстом кодовой базы, поднимет такие вопросы, и они должны появляться как находки, которые проверяет человек, а не как окончательные вердикты.

Системы ИИ могут оценивать бизнес‑логику, намерения разработчиков и архитектурные компромиссы, но их выводы вероятностны. Как команды разработки могут извлечь пользу из такого контекстного рассуждения, не принимая выводы ИИ как безусловно верные?

AI‑обзор занимает своё место в проблемах, которые обычные проверки пропускают: логические ошибки, поведение, не соответствующее заявленному намерению, изменение, которое выглядит корректным в изоляции, но ошибочно для конкретной системы. Эти выводы вероятностны, поэтому они должны входить в состав входных данных для принятия решения, а не заменять само решение. Команды удерживают эту границу, оставляя детерминированные контрольные точки перед слиянием — автоматические тесты, проверку CI, сканирование безопасности, политические проверки и человека, отвечающего за изменение. ИИ может предлагать исправления или выполнять их в рамках установленных ограничений, пока эти изменения проходят ту же проверку, что и код, написанный человеком, без привилегий за то, что их сгенерировал ИИ.

Мы применяем тот же принцип в собственной реализации. Модель предлагает находки, а окончательный вердикт обзора вычисляется в коде на основе состояния этих находок. Разрешение работает аналогично: когда код, связанный с находкой, исчезает из диффа, это детерминированная проверка парсенного диффа, и модель не может «разрешить» то, что уже исправлено.

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

Sonar сочетает контекстно‑aware обзоры pull‑request с детерминированным анализом и quality gates. Как выглядит эффективный многоуровневый процесс проверки, и как разные уровни должны взаимодействовать без дублирования работы и без перегрузки разработчиков находками?

Детерминированный анализ и quality gates охватывают то, что не подлежит обсуждению, и именно на них блокируется слияние. Контекстный обзор берёт на себя суждения о том, делает ли изменение то, что заявлено, вписывается ли оно в кодовую базу и стоит ли данный риск внимания человека.

Стена находок игнорируется примерно так же часто, как и отсутствие находок. Мы дедуплицируем результаты между ревьюерами до того, как они попадают к автору, отбрасываем кандидаты, которые невозможно проверить, и сосредотачиваемся на находках с высоким сигналом. На стороне правил предикат решает, применяется ли правило к текущему диффу до запуска любой модели, поэтому большинство правил не тратят ресурсы на большинство изменений. Всё это отображается в pull‑request, который уже открыт у разработчика.

По мере того как код‑агенты генерируют всё больше кода и pull‑request’ов, может ли процесс обзора и проверки стать новым узким местом? Какие части процесса следует автоматизировать, а какие решения должны оставаться за опытными инженерами?

Обзор и проверка уже стали узким местом. Фактически, наше 2026 State of Code Developer Survey показало, что команды тратят примерно четверть рабочей недели на проверку и исправление вывода ИИ. Поэтому неудивительно, что лишь 48 % разработчиков всегда проверяют сгенерированный ИИ код перед коммитом, хотя большинство (96 %) не полностью доверяют его функциональной корректности.

Автоматизировать стоит механическую и неприятную работу: свести сбой CI к корневой причине, чтобы никто не читал четыре тысячи строк логов, решить, актуальна ли находка после ребейза, воспроизвести сбой, написать очевидное исправление. Инженерам следует оставлять намерения, дизайн и решение о том, сколько доказательств достаточно для конкретного изменения. Когда старший инженер тратит вечер на разбор логов, чтобы понять, какой из девяти сбоев важен, это триаж, а не суждение, и именно такую работу мы должны отнимать у них.

Системы AI‑обзора кода могут выявлять проблемы, предлагать исправления и проверять эти изменения в конвейере CI. Как не допустить, чтобы автономная система ремедиации вводила регрессии или оптимизировалась только под успешный билд, а не под более широкое качество программного обеспечения?

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

Большинство ограничений, которые мы накладываем на собственную ремедиацию, касаются области применения. Gitar исправляет CI, который сломался, и проверяет, что коммит перед её собственным пушем был «зеленым», прежде чем брать на себя ответственность. Она останавливается после двух последующих коммитов, а не продолжает «грызть» красный билд. Когда сбой не связан с изменением — это флейки‑тест или инфраструктурный сбой — он идёт по пути повторных попыток, а не по пути исправления, потому что цель «заставить тест перестать падать» является наименее желаемой для способного агента.

После этого изменение должно пройти слой, который Gitar не контролирует. SonarQube оценивает результат по своим собственным критериям, quality gate определяет возможность слияния, а команда владеет этой политикой. Мы также сверяем изменение с тикетом, который он заявляет, при этом извлечение требований отделено от оценки завершённости, так что требование, тихо исчезнувшее из тикета, не может вернуться как реализованное.

Эффективный AI‑обзор кода требует понимания конвенций репозитория, зависимостей, архитектуры и цели предлагаемого изменения. Какой контекст нужен AI‑ревьюеру для принятия полезных решений, и как организации могут поддерживать актуальность этого контекста по мере эволюции их систем?

Необходимо достаточно контекста, чтобы рассуждать как опытный ревьюер, а не просто прочитать дифф. Это включает цель изменения, релевантные пути кода и типовую информацию, зависимости, поведение тестов, конвенции репозитория и архитектурные границы, которые команда ожидает от изменения.

Контекст также должен жить вместе с кодом. Храните правила и рекомендации обзора в версии репозитория, обновляйте их при изменении сервисов или конвенций и делайте ясным, кто отвечает за архитектурные и политические решения. Иначе AI‑ревьюер может предложить отдельное правдоподобное решение, которое конфликтует с тем, как работает более широкая система.

Детерминированный анализ дает согласованные и проверяемые результаты, тогда как обзор на основе больших языковых моделей может различаться между запусками. Как предприятия должны документировать, воспроизводить и управлять AI‑генерируемыми находками в регулируемых или чувствительных к безопасности средах?

Аудиторский журнал должен фиксировать проверяемое изменение, AI‑находку, принятое решение и независимые доказательства, использованные для валидации результата. Команды могут использовать ИИ для ускорения обзора и ремедиации, сохраняя при этом принудительные и одобрительные решения в рамках определённых политик и человеческой ответственности.

Какие метрики должны использовать лидеры инженерных команд, чтобы определить, действительно ли AI‑обзор кода улучшает процесс разработки? Стоит ли им ориентироваться на время обзора, количество ускользнувших дефектов, уровень ложных срабатываний, сбои CI, технический долг, доверие разработчиков или какие‑то другие показатели?

Начинайте с результатов, а не с количества комментариев, генерируемых ИИ. Я бы измерял время от создания pull‑request до слияния, время, затраченное на диагностику сбоев CI, процент исправлений, прошедших первую проверку, и частоту появления проблем на более поздних этапах или в продакшн.

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

Смотрим вперёд: ожидаете ли вы, что процесс разработки превратится в непрерывный цикл, в котором агенты генерируют, проверяют, тестируют и исправляют код под детерминированными ограничениями? Как в таком окружении изменятся обязанности и необходимые навыки человеческих инженеров?

Этот цикл уже существует, и команды обычно следуют фиксированному порядку: сначала обнаружение, затем ремедиация, затем одобрение по записанным условиям и, наконец, слияние. Никто не прыгает сразу к последнему шагу, а доказательства, которые продвигают их вперёд, берутся из их собственной кодовой базы, а не из внешних бенчмарков. Слияние — самый интересный этап, потому что частота конфликтов растёт с увеличением количества коммитов, а именно это ускоряется благодаря всему новому процессу.

Навыки, которые становятся более ценными, находятся вокруг цикла, а не внутри него. Точность формулировки проблемы и её ограничений важнее, когда агент воспринимает ваше описание буквально. То же самое касается определения, какие доказательства достаточны, чтобы пропустить изменение — раньше это было привычкой в голове людей, теперь это должно быть зафиксировано в политике, которую может применять автоматика. Остальное — проектирование систем: ограничение того, к чему может прикоснуться автоматическая работа, наличие механизма, который не контролирует агент, проверяющего результат, и обеспечение возможности отследить ответственность, когда что‑то идёт не так. Инженеры будут тратить меньше времени на написание реализации и больше — на решение, что должно существовать и какие доказательства подтвердят, что это работает.

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