AI Dev Podcast #3 / Как сделать Code Review инструмент / Опыт Т-Банка (Рубрика #AI4SDLC)

Послушал свежий выпуск AI Dev Podcast, где мои коллеги из Т-Банка — Надежда Егошина и Георгий Мкртчян — рассказывают ведущим Андрею Дмитриеву (ко-фаундеру jug.ru и автору канала @dmitrievandrey8) и Андрею Буракову (автору канала @another_sa), как у нас сделали AI Code Review. Слушал с особым интересом: тема близкая, да и ребята рассказывают про реальный путь, не сильно приукрашивая. Кстати, это один из доменных агентов, что встроен в общий pipeline разработки и доступен всем командам в компании.

Команда зашла со стороны вопроса «что инженер на самом деле делает на ревью?» и выделила 12 аспектов — архитектура, конкурентность, тестируемость и так далее. Но ценнее другое: главная задача ревьюера — понять, сделал ли человек то, что было в задаче. Поэтому инструмент интегрирован с таск-трекером и Confluence, читает требования, смотрит не на голый дифф, а на изменения в контексте всего репозитория, и в саммари раскладывает задачу на требования: что реализовано, что нет и что сделано «сверх задачи».

Больше всего в этом случае мне нравится, что это отличный пример совместной работы R&D и платформенных команд. Первую версию собрали исследователи: проресёрчили рынок, взяли open-source, сильно переделали — получился сервис, куда вставляешь ссылку на merge request и получаешь комментарии бота. А дальше продукт передали в платформенную команду, которая стала поднимать качество за счёт знания того, как реально устроены процессы ревью в разных командах, и глубокого погружения в домен. По-моему, это правильная модель: R&D быстро проверяет гипотезы, платформа превращает прототип в продукт масштаба всего IT.

Отдельно порадовала инженерная честность в оценке. Контуров два. Offline — собственный бенчмарк: методологию подсмотрели в статье ByteDance (я её в своё время разбирал тут), а сам бенчмарк собрали, пропарсив свой GitLab. Online — лайки и дизлайки на конкретные комментарии и A/B-тесты. И прямой ответ на вопрос «на сколько сократили баги и время ревью»: пока заявить не можем, продукт недавно вышел из прототипа. На фоне общего хайпа такая аккуратность подкупает.

Есть ещё два интересных момента
1️⃣ Доверие как продукт: сейчас инженер делает двойную работу, сначала валидирует ревьюера, потом сам ревьюит MR, и для авторевью у команды жёсткое требование — обязательная валидация человеком. Если слепо аппрувить за ботом, багов станет больше, а не меньше
2️⃣ Интересный тезис Георгия: дообучать модели сейчас смысла нет, они пробовали — улучшения минорные или в минус, а сила в грамотной экосистеме вокруг предобученных LLM. Тезис верен в контексте этой задачи в Т-Банке, но это не универсальное правило (лучше проверять в каждом конкретном случае)

В общем, из подкаста видно, что локальное ускорение этапов сдвигает работу дальше по пайплану
- Ускоряешь генерацию кода — узкое место едет в ревью
- Ускоряешь ревью — нагрузка едет в тестирование
- Ускоряешь тестирование — весело может стать в operations

Ну и тут AI Code Review показан как перестройка всего цикла разработки, где активом остаются контекст, доверие и человек в контуре.

#AI #AI4SDLC #CodeReview #Engineering #Product #Management