Как мы сократили код-ревью с двух суток до пятнадцати минут: кейс мультиагентной системы
Кейс CTO AlpinaGPT Сергея Андриянова: как из боли с код-ревью в аутсорс-команде вырос продукт Evolver, и почему мы сознательно отказались от автономных агентов в проде.
В конце мая мы собирали внутреннюю мастер-встречу по AI-трансформации, и один из докладов оказался настолько содержательным, что я не могу удержаться и не пересказать его. Выступал Сергей Андриянов — наш CTO в AlpinaGPT и одновременно основатель аутсорс-компании WebRegul, которой уже больше пятнадцати лет. Сергей рассказал, как они с командой автоматизировали код-ревью через мультиагентную систему: время ожидания упало с двух суток до нескольких часов, на рутинных мердж-реквестах — до пятнадцати минут, и они освободили примерно сто часов работы команды в месяц.
Меня зовут Жемал Хамидун, я CPO AlpinaGPT, Head of AI Alpina Digital и автор тг-канала «Готовим ИИшницу».
Эта статья будет полезна для CTO, тимлидов и продактов, которые думают о том, чтобы внедрить ИИ в работу команды разработки. По ходу — собственные комментарии как Head of AI: где этот опыт ложится в общую картину рынка, а где это редкая практика, на которую стоит обратить внимание.
С чего всё началось: рост команды в три раза и ревью на двое суток
Контекст у Сергея был типичный для растущей аутсорс-разработки. По его словам: «Два года назад мы в компании столкнулись с довольно-таки быстрым ростом. Разработчиков стало много, выросли буквально в три раза за один год, и процессы очень сильно поменялись. И после этого код-ревью из полезной практики местами начал превращаться в ад».
Симптомы знакомы всем, кто проходил рост команды. Ревью висели по двое суток. Разработчики жаловались, что не успевают делать свою работу — приходится отвлекаться на проверку чужих мердж-реквестов. Часто это были блокирующие задачи или срочные фиксы: код-ревьюер должен бросить свою работу, потерять контекст, проверить чужой код, а потом возвращаться к своей задаче. Сергей просто свёл статистику и посчитал: «Уходит порядка ста часов в месяц на одну команду на ревью».
Поверх этого была ещё одна проблема, о которой редко говорят. Не всегда есть свободный разработчик, который глубоко погружён в нужный сервис. Иногда на ревью попадает человек из другой команды, и у него два варианта: либо потратить очень много времени, чтобы прогрузиться — понять задачу, изучить текущий код, разобрать архитектурное решение, — либо посмотреть код формально, не вникая. Первое стоит времени, второе подрывает смысл самого ревью.
Цифру про сто часов в месяц я хочу подсветить отдельно. Это две с половиной недели работы одного опытного разработчика. На одной команде. Если в компании несколько команд — это уже легко уходит в несколько ставок senior-разработчиков, заплаченных только за ревью. И до тех пор, пока эта цифра не посчитана в часах конкретных людей, у CTO нет повода что-то менять. Так что первый практический вывод, ещё до всякой технологии: считайте часы.
Первая версия за две недели на Claude Code — и почему она провалилась
Дальше — то, что мне особенно нравится в выступлении: Сергей не пошёл «пилить стартап», а провёл эксперимент внутри своей компании. По его словам: «То, что продукт вышел, это уже такой побочный эффект».
Первая мысль очевидная: «Окей, есть чат GPT, давайте кинем туда дифф изменений и получим ревью». Сергей сразу обозначил, почему это не работает: «Код — это только выглядит как текст. На самом деле это связи: меняешь одну функцию, может сломаться двадцать других мест, о которых ты не особо помнишь, особенно если ты только пришёл на проект. Чтобы делать ревью нормально, системе нужна карта всего проекта, не просто видеть открытый файл, а реально понимать, как устроен весь проект».
Первую версию Сергей собрал за пару недель «вот прям очень тупо на Claude-коде». Иерархическая память, накапливаемое знание о команде, расширение памяти, знание о проекте и его особенностях — всё в полуручном режиме. Запустил на одном проекте, после первичного сопротивления получил хорошую обратную связь, ребята начали просить агента на другие проекты.
Дальше упёрлись в узкое место: один большой агент-универсал плохо масштабируется. Это известная проблема — чем шире задача LLM, тем хуже результат. Так появилась вторая версия: уже командой, с детерминированным флоу и простой системой инициализации проектов. С ней выиграли грант Фонда содействия инновациям и пошли строить полноценную, третью, продакшн-версию.
Третья версия — это и есть текущий продукт. Она строится в три прохода. Сначала система разбирает код как структуру: где функции, где классы, и собирает всё в RAG и в документацию именно для агентов. Потом — учит систему понимать код по смыслу, чтобы можно было найти, где какая логика, не зная имён функций. И в конце строится граф связей: кто кого вызывает, что от чего зависит. После этого, когда приходит новый дифф, система за секунды понимает, что изменилось и что может пострадать — включая те места, про которые никто не помнит и которые не покрыты тестами.
Три агента вместо одного: библиотекарь, исследователь, ревьюер
Главное архитектурное решение Сергей формулирует так: «Это не один большой совокупный агент-универсал, который пытается делать всё сразу. Три специализированных агента, у которых своя зона ответственности».
Первый — агент-библиотекарь. Он знает аналитику и всю документацию по задаче. Сходит в YouTrack, Jira или другой трекер, прочитает задачу, изучит ТЗ, пройдёт по всем ссылкам, прочитает комментарии, где команда обсуждала решение. Дальше он умеет проверять не только код, но и то, для чего этот код предназначен — включая узкие места и граничные кейсы, которые часто сложно выявить на этапе тестирования. По словам Сергея, многие логические баги теперь возвращаются ещё до ухода в тестирование.
Второй — агент-исследователь. Он знает кодовую базу: где какая функция, кого вызывает, какие зависимости. Это тот самый граф связей, который строится при инициализации проекта.
Третий — собственно ревьюер. Он уже, зная архитектуру проекта, принятые в нём решения и даже текущий техдолг, пишет замечания по коду, привязывает их к строкам, отмечает как в Git, так и в трекере.
Почему такая раскладка работает лучше одного большого агента — Сергей объяснил через простую аналогию: «Так же, как и в реальной команде, мы не нанимаем одного человека на всё». Узкоспециализированные агенты дают на порядок лучшее качество, чем один универсал, который пытается одновременно читать тикет, разбирать кодовую базу и писать замечания. Чем шире задача LLM, тем хуже результат.
Отдельно оговорю: за словами «три агента» стоит не тройка промптов, вызванных по очереди. У каждого агента своя память, свой набор инструментов, свои границы того, что он может и не может делать, свои проверки того, что вернул LLM, и своя логика поведения при ошибке. Плюс инфраструктура вокруг: разбор кода в структуру и RAG по документации, граф связей между функциями, интеграции с трекером и Git, слой безопасности вокруг закрытых данных. Сергей с командой довёл систему до продакшена только на третьей итерации и потратил на это в сумме больше года — первые две версии закономерно провалились там, где казалось «и так сойдёт». Собрать такое «за выходные силами одного разработчика» не выйдет: это уровень отдельной продуктовой команды с инженером по данным, ML-инженером и разработчиком инфраструктуры.
Плюс агент-консультант: ИИ для аналитиков, тестировщиков и онбординга
Дальше Сергей подсветил то, что я считаю критически важным для CTO, которые думают про внедрение ИИ. Тройка агентов решает только задачу ревью. Но в команде, кроме разработчиков, есть ещё аналитики, тестировщики и новички. И они тоже хотят инструмент.
Поэтому в системе есть второй ключевой агент — консультант. Он знает всё про проект: архитектуру, документацию, кодовую базу — даже если это десятки микросервисов, — все принятые паттерны. И с ним можно разговаривать на человеческом языке.
Что это меняет на практике. Аналитик, который пишет новую фичу и хочет узнать, как сейчас реализована смежная функциональность, раньше шёл «мучить разработчиков» — потому что в документации не хватало технических подробностей. Теперь он задаёт вопрос агенту, и тот объясняет за минуты. Тестировщик в сложных кейсах раньше тоже ждал, пока разработчик отвлечётся, теперь спрашивает консультанта — и тот знает всю систему, может подсказать в том числе то, на что тестировщик мог бы не обратить внимания. И третье — онбординг новых сотрудников: «Новичок может задать кучу вопросов агенту, а команду уже беспокоит только по сложным вопросам».
На уровне Head of AI это самый недооценённый эффект ИИ в командах разработки. Метрики прироста производительности конкретного разработчика — это видимая часть. Невидимая — это десятки часов в неделю, которые сеньоры тратили на ответы на вопросы коллег из других ролей. ИИ-консультант снимает большую часть этой нагрузки без потери качества — если он реально знает проект.
Контр-хайповое решение: 70 процентов workflow, 30 процентов автономных агентов
Прежде чем разбирать эту пропорцию — короткое определение, потому что слова «workflow» и «автономный агент» часто путают. Workflow — это заранее прописанный сценарий: система идёт по фиксированным шагам «сначала библиотекарь, потом исследователь, потом ревьюер», а LLM работает внутри детерминированного каркаса. Разработчик решает за неё, что и в каком порядке делать. Автономный агент — наоборот: получает задачу и набор инструментов, дальше сам выбирает, что вызывать, в какой последовательности и когда остановиться. Первый предсказуем и дешевле в эксплуатации, второй гибче, но заметно дороже и менее стабилен.
Дальше Сергей подсветил решение, которое в текущей хайповой повестке звучит почти ересью. Сейчас в мире разработки модно делать всё через автономных агентов: «прописать задачу, прописать инструменты, действуй — он сам разберётся». Сергей с этим спорит.
По его словам: «Скажу не очень популярную вещь. Для большинства задач, на мой взгляд, это плохой способ, особенно для продакшен. Почему? Автономный агент непредсказуемый. Сегодня сделал ревью так, завтра так, сегодня за тридцать секунд, завтра за четыре минуты. Потом решил одно и то же перепроверить три раза. Чаще ошибается, идёт не в ту сторону. Страдает при большом контексте, путается в инструментах. Он дорогой. Каждый лишний вызов LLM — это деньги. Он плохо отлаживается».
Конкретная пропорция в текущей версии: «В нашей системе сейчас в третьей версии примерно семьдесят процентов — это workflow и только тридцать процентов самостоятельные агенты, которые вызываются внутри него. Мы сознательно так сделали на основе опыта и шишек, набитых на первых двух версиях. Это решение экономит и деньги, и делает систему предсказуемой уже для продакшена, а не только для внутреннего пилота в компании».
Это не локальное наблюдение Сергея, а индустриальный консенсус, который выкристаллизовался к 2025–2026 годам. Anthropic в своём программном посте «Building Effective Agents» разделяют эти подходы прямо: «Workflows are systems where LLMs and tools are orchestrated through predefined code paths» — это про детерминированный пайплайн. И «Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage» — это про автономию. Их же вывод: «Workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale».
Для код-ревью первое явно лучше: задача хорошо определена, цена ошибки высокая, нужна повторяемость. Для исследовательских задач — наоборот, разумнее давать автономию. И главный практический вывод: если на старте проекта вы по умолчанию строите автономного агента, потому что «так модно», — скорее всего, через полгода вы будете переписывать его на workflow.
Что сознательно НЕ автоматизировали
Второе важное решение — какие задачи команда сознательно оставила за человеком. Ревью кода у Сергея делится на три уровня. Механическое и логическое: форматирование, типовые ошибки, нейминг, правильно ли в принципе решена задача. По его оценке, это шестьдесят-семьдесят процентов работы. Эту часть отдали ИИ практически полностью. Архитектурное ревью: нужно ли вынести модуль в сервис, как правильно положить зону ответственности. Тут ИИ может помочь — выдать совет или указать на что-то, — но решение остаётся за человеком.
Кроме этого, Сергей сознательно не пошёл в автоматическое написание кода. Цитата: «Сознательно не пошли. Доверие хрупкое. Велик риск ошибки. Один раз советует плохое решение — потом половину проекта переписывать. После этого команда не доверяет системе вообще. Плюс, опять же, у нас коммерческие продукты, и доверять их было бы нечестно перед клиентом, поэтому никаких автоматизированных исправлений мы умышленно и сознательно не делали в нашей системе и сознательно не собираемся делать».
Этот тезис подтверждается индустриальными данными. В DORA Report 2024 — годовом отчёте Google Cloud о состоянии DevOps — больше 75 процентов разработчиков используют ИИ для ежедневных задач, но при этом около 39 процентов не доверяют коду, сгенерированному ИИ. Парадокс DORA: рост adoption ИИ-инструментов сопровождается оценочным снижением throughput поставки примерно на 1,5 процента и стабильности — примерно на 7 процентов. То есть бездумная автоматизация написания кода в командах разработки даёт обратный эффект.
Принцип «доверие хрупкое» здесь — это не консервативная позиция, а просто грамотная работа с риском. ИИ хорошо закрывает повторяемую низкорисковую часть. На высокорисковой части он работает как советчик, а не как автор. И это та граница, которую сейчас часто пытаются стереть в погоне за «полностью автономной командой разработки» — и потом оплачивают эту попытку годами рефакторингов.
Как внедряли в команду — четыре этапа без бунта
Самая полезная для меня часть выступления — это не технология, а методология внедрения. Я часто вижу проекты, где техническая часть готова за квартал, а культурная — буксует год. У Сергея получилось за полтора-два месяца, и без бунта.
Сначала контекст: когда Сергей пришёл к команде и сказал «я тут сделал штуку для ревью, она будет вас проверять», — он встретил сопротивление и недоверие. По его словам: «Кто-то боялся, что на него переложат ответственность за ошибки. Кто-то боялся, что это только усложнит и удлинит путь. Кого-то просто терзала профессиональная гордость — дословно: чего это меня будет какая-то железная башка проверять?». И это, говорит он, одна из самых больших проблем при любом внедрении.
Дальше — четыре этапа. Первые две недели агент работает в фоне, но замечания никто не обязан исполнять. Просто пишет, смотрите, нравится — учитывайте, не нравится — игнорируйте. Это снимает страх: нет обязательств, человек сам видит, полезно или нет. Второй этап — две-три недели полноценного использования, обязательств всё ещё нет, но активно собирается фидбэк. Каждую неделю — разбор ошибок и правки. По словам Сергея, точность ревью за этот период выросла с семидесяти до девяноста процентов. И ребята из сопротивляющихся стали союзниками — сами стали просить внедрить агента на другие проекты.
Третий этап, три-четыре недели — агент становится обязательным шагом ПЕРЕД ревью человеком. Прежде чем отправить старшему, дождись агента, исправь или аргументируй. Старшему попадает уже максимально чистый код. И четвёртый этап — полная интеграция: агент-первая линия не принял — мердж-реквест не идёт дальше. Простые задачи могут уходить вообще без человеческого ревью. Сложные и опасные проходят дополнительно, но уже подготовленными.
Параллельно — отдельный список того, что Сергей сознательно НЕ делал. Не наказывал за ошибки, которые нашёл агент. Наоборот: это нормально, что ошибку нашёл кто-то, кроме автора. Главное, что её исправили до прода, а ещё лучше — до тестирования. Не запрещал разработчикам отменять вердикт агента: старший разработчик или архитектор всегда главнее, и даже автор мердж-реквеста может полноценно оспаривать решение. И не заставлял пользоваться сразу. Первые шесть недель — «поиграйтесь, это не задержка, это инвестиция в доверие».
Этот сценарий внедрения, на мой взгляд, переносится почти на любую ИИ-инициативу в команде. Главный механизм здесь — поэтапное снятие ответственности и постепенное наращивание обязательств. Если попытаться сэкономить эти полтора месяца и сразу сделать агента обязательным — получите тот самый бунт, на который многие компании потом списывают «провал ИИ-внедрения».
Пять граблей, на которые наступают другие
Сергей отдельно собрал пять типовых ошибок других команд, которые он наблюдал за полтора года общения с CTO и продакт-менеджерами, внедряющими ИИ. Я перенесу их сюда практически дословно, потому что повторяемость этих ошибок я тоже вижу регулярно в работе с клиентами AlpinaGPT.
-
«Дадим свободу, и он сам разберётся». Не разберётся. Автономный агент в проде — это головная боль, страх и бессонные ночи. Лучше начинать с предсказуемых процессов и узких задач, постепенно расширять, а не делать сразу супер-агента, который пытается заменить человека.
-
«Сначала технология, потом разберёмся». Без буфера привыкания команды любая фича рискует умереть в шкафу — даже хорошая технически.
-
«Метрики посчитаем потом». Тогда есть риск вбухать кучу денег и потом думать, что в итоге сэкономили. Сначала замерить, понять, сколько часов уходит на это сейчас, в цифрах. Реально ли надо это автоматизировать, стоит ли оно того.
-
«Заменим разрабов на ИИ». На взгляд Сергея — плохая идея. ИИ не отвечает за ошибки: «Извините, я сгаллюционировал». Сложные задачи всё равно лягут на мидлов и сеньоров. Джуниоров теоретически заменить можно, но «джуниоры — это ваша инвестиция, ваш путь к сеньорам через несколько лет. Если сэкономить сейчас, можно получить дыру в команде в будущем».
-
«У нас закрытые данные, нам не пойдёт». Для этого существуют on-prem-решения, закрытые контуры и обезличивание. Это требование к выбору инструмента, а не повод не внедрять.
Если у вашей компании задача шире одного процесса ревью — развернуть корпоративную ИИ-платформу с on-prem, где Claude, GPT и Gemini подключены через единый юридический договор, с базой знаний компании, ролевым доступом для разных отделов и контролем безопасности данных, — этим мы занимаемся в AlpinaGPT. Запишитесь на бесплатный разбор с нашей командой. За 45 минут мы оценим уровень зрелости ваших команд по внедрению ИИ, определим, в какие отделы и под какие задачи он пойдёт первым и даст максимальную экономию, спроектируем on-prem-развёртывание под ваши требования безопасности и соберём дорожную карту на ближайшие 90 дней с прогнозом сэкономленных часов и рублей. По итогам у вас на руках готовый план — с чем идти в совет директоров или что запускать со следующей недели.
А как у вас в команде сейчас устроено код-ревью? Замеряли ли, сколько часов в месяц уходит на проверку чужих мердж-реквестов? Напишите в комментариях — какой из принципов Сергея вам ближе всего и что бы вы попробовали в первую очередь. Самые интересные кейсы разберу лично.
Больше кейсов и разборов внедрений ИИ — в Телеграм-канале «Дело в промпте». Заходите, если хочется быть в курсе.
Источники
Автор: AlpinaDigitalRU