ИИ-агенты изменили процесс тестирования и проверки кода в ZeBrains
ZeBrains последовательно переходит на agentic dev подход, при котором ИИ‑агенты координируют и исполняют отдельные этапы рабочего процесса. После того как отдел разработки внедрил этот подход, пришла очередь отдела тестирования.
Раньше каждое изменение перед публикацией проходило проверку только силами людей: разработчики и тимлиды вручную сверяли код с задачей, искали ошибки и следили за соблюдением внутренних стандартов. Это работало, но упиралось в человеческий ресурс — самые опытные и дорогие специалисты компании тратили значительную часть времени на рутинную проверку. Мы решили встроить в этот процесс ИИ-агента, который берёт на себя первый круг проверки качества.
Перед командой стояло несколько связанных проблем:
- Часть багов и несоответствий требованиям задачи обнаруживалась только на этапе код-ревью — когда разработчик уже закоммитил изменения и открыл merge request, а не раньше, например на этапе написания кода или локального тестирования.
- Скорость прохождения кода через все проверки — от готовности до попадания в основную версию продукта — напрямую влияла на то, как быстро фичи и исправления доходили до пользователей.
- Нужно было повысить качество кода на входе в продукт, не увеличивая штат и не замедляя разработку.
Задача звучала так: сократить время и стоимость проверки кода, разгрузить старших специалистов и при этом не потерять, а повысить качество итогового продукта.
Мы внедрили ИИ-агента, который выполняет роль первого проверяющего для каждого изменения кода ещё до того, как его увидит человек. Агент получает на вход исходную постановку задачи и сравнивает её с тем, что реально реализовано в коде. Он проверяет:
- соответствует ли реализация требованиям задачи;
- насколько изменения логично вписываются в архитектуру всего проекта, а не только конкретного файла;
- соблюдены ли внутренние стандарты и договорённости команды по написанию кода.
По результатам проверки агент публикует замечания прямо в merge request — с пометкой критичности по каждому. Дальше подключается человек: сначала разработчик — принимает замечание или оспаривает его с комментарием; затем тимлид — уже на втором круге ревью, когда типовые ошибки закрыты и можно сосредоточиться на архитектурных и продуктовых решениях.
Ключевой эффект — перераспределение работы. Раньше старшие разработчики и тимлиды тратили время на то, чтобы поймать формальные несоответствия и недопонимания в постановке задачи. Теперь этот слой работы полностью взял на себя агент, а люди сосредоточились на том, что действительно требует их опыта: архитектурные решения, продуктовая логика, нестандартные случаи.
Как это устроено? Разработчик открывает merge request в GitLab — дальше ничего вручную запускать не нужно, проверка стартует сама. Агент собирает контекст по задаче: берёт постановку и критерии приёмки из Jira, изменения в коде — из GitLab, а также свод правил команды и описание архитектуры проекта, которые хранятся прямо в репозитории и обновляются вместе с кодом.
Проверка идёт в три этапа:
- Соответствует ли реализация задаче.
- Вписывается ли изменение в архитектуру проекта.
- Соблюдены ли стандарты команды.
Каждый этап агент проходит отдельно, чтобы не смешивать разные виды проверки и не терять фокус.
Результат публикуется прямо в merge request — замечания к конкретным строкам с пометкой, насколько они критичны, и общее резюме: что сделано, что не сделано, что сделано лишнего. Разработчик может исправить замечание или отклонить его с комментарием — так система запоминает, где агент оказался прав, а где ошибся, и постепенно становится точнее без дополнительной настройки вручную.
Несколько merge request проверяются одновременно, поэтому команда не теряет время в очереди — раньше на это уходили часы, а иногда и весь день. Тимлид подключается на втором круге уже с готовым списком замечаний и занимается только тем, что действительно требует его опыта: архитектурными решениями и нестандартными случаями.
Отдельно команда следит за тем, чтобы агент не терял в качестве со временем: при любом обновлении модели или правил его сначала проверяют на наборе реальных задач с уже известными ошибками — и только после этого переводят на боевой режим, без остановки процесса для разработчиков.
- 5 минут — столько проходит от открытия merge request до первого списка замечаний. Раньше код ждал свободного ревьюера часами, иногда до следующего дня.
- 100% изменений проходят три уровня проверки до того, как их увидит человек: соответствие постановке в Jira, вписанность в архитектуру проекта, соблюдение стандартов команды. Раньше глубина ревью зависела от загрузки тимлида.
- 0 строк кода уходит за пределы компании. Модель работает в контуре ZeBrains — то же решение доступно клиентам с требованиями к защите исходников.
- 24/7 — агент проверяет код в ночь перед релизом и в выходные с той же тщательностью, что и в рабочий вторник.
- Тимлиды и старшие разработчики больше не тратят время на первый круг ревью. Они получают merge request с готовым списком отклонений и фокусируются на архитектурой, продуктовой логике, нестандартных случаях.
проекта