Тимлид оценил рост багов при агентской разработке

Тимлид Игорь Симаков, руководящий двумя продуктовыми командами, опубликовал на Хабре разбор того, как переход на агентскую разработку повлиял на качество кода. Сам он не пишет код руками с марта 2026 года, а его команды — бэкенд, фронтенд и QA — уже полгода работают через агентов. Стек остался классическим: Java и Spring, Kafka, PostgreSQL, Kubernetes, а в качестве агента используется Claude Code с моделью Opus, правила для которого хранятся прямо в репозиториях.

Управление командами Симаков строит через метрики: собранный дашборд показал, что пропуск дефектов на прод значительно вырос, причём рост сопоставим с ростом объёма поставляемого кода. Чтобы разобраться, он проанализировал все баги двух команд за год — 268 штук. Выяснилось, что дефекты не новые и существовали до агентов, но теперь стали заметнее: кода команды приносят втрое больше, и дефектов проскакивает ощутимо больше.

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

Цифры за год показывают масштаб изменений: мерж-реквестов стало почти вдвое больше — с 199 до 351 за квартал, средний размер MR вырос со 160 до 280 строк, а общий объём кода — с 32 до 97 тысяч строк за квартал, то есть втрое. Тестировщиков при этом столько же. Технических багов на проде с конца 2025 года стало вчетверо больше: раньше инженерных дефектов были единицы, теперь за квартал набирается три десятка, отсюда и рост хотфиксов.

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

Находят инженерные дефекты на проде либо алерты, либо люди: мониторинг выявляет 30%, пользователи и соседние команды — 25%, сама команда — 38%. Для сравнения, в разборе 152 серьёзных инцидентов Microsoft Teams (Ghosh et al., SoCC 2022) 55% нашли мониторы и только 6% — сама команда. Руками тестировщики находят то, что видно в интерфейсе, а сложные сценарии с гонками и нагрузкой обычный тестировщик не поймает: out of memory или странный запрос на последнюю страницу пагинации он делать не будет.

В командах выстроен процесс: сначала ADR и согласование контрактов, затем генерация кода и функциональных тестов без моков, проверка тестов мутацией локально в Claude, статические анализаторы, линтеры, правила ArchUnit и тесты на базу данных. На dev-стенде агент сам прогоняет end-to-end сценарии с REST-запросами и доступом на чтение к базе, на stage гоняется нагрузка и анализируются планы запросов через EXPLAIN ANALYZE. При подготовке релиза работают скиллы: собирается тег, подтягиваются задачи, анализируется, какие фича-флаги поставить и какие индексы создать руками перед продом.

Роль тестировщиков меняется: они всё больше становятся инженерами. В первом квартале они отправили 6 мерж-реквестов, в третьем — уже 34, почти все в репозиторий автотестов. Симаков делает вывод, что тестировщик должен развиваться в сторону инженерного тестирования, а не просто увеличивать объём ручных проверок.