Агентская разработка: почему удвоение объема кода привело к росту багов в технических дефектах

# Трансформация качества при внедрении ИИ-агентов в разработку

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

Рост объема кода и сложность инженерных задач

Главным наблюдением становится экспоненциальный рост количества поставляемого кода при относительно стабильном количестве сотрудников. За год количество мерж-реквестов увеличилось почти вдвое, со 199 до 351 за квартал, а средний размер каждого запроса вырос с 160 до 280 строк кода. В совокупности объем поставляемого кода вырос втрое: с 32 тысяч строк до 97 тысяч в квартал.

Парадокс заключается в том, что количество тестировщиков оставалось неизменным. Изначально следовало ожидать пропорционального увеличения штата QA для покрытия растущих объемов. Анализ показал, что функциональные дефекты (ошибки, влияющие на логику работы продукта и видимые пользователю) были успешно отлавливались благодаря существующей системе e2e-тестирования и ручного контроля. Процент их пропуски на продакшн не изменился значительно.

Однако ситуация кардинально меняется в плоскости инженерных, или «подкапотных», проблем. Технические дефекты, которые раньше возникали редко, теперь составляют основную долю инцидентов. За квартал количество таких багов, обнаруживаемых на продакшн, выросло вчетверо, набрав три десятка новых случая за этот период. Это связано с тем, что агенты, как и люди, сталкиваются со сложностью систем, но объем кода создает больше точек потенциальной нестабильности.

Что такое инженерные дефекты? Это ошибки, которые не видны при обычном тестировании нажимаемых кнопок. Сюда относятся проблемы с контрактами между сервисами, нарушения обратной совместимости при миграции баз данных, блокировки таблиц из-за плохо прописанных индексов, ошибки обработки нагрузок или гонки данных (конкурентные апдейты), приводящие к потере информации.

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

Эволюция роли тестировщика и новые методы валидации

Ключевым фактором, определяющим успешность релизов в новой парадигме, стало переосмысление роли тестировщика. Традиционный QA, занимающийся ручным прохождением сценариев, переквалифицируется в инженера тестирования и разработчика автотестов. В рассматриваемом кейсе количество мерж-реквестов от тестировщиков выросло с 6 в первом квартале до 34 в третьем, причем почти все они касались репозиториев автотестов.

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

1. Генерация и мутация тестов: К сгенерированному агентом коду обязательно создаются функциональные тесты без использования моков (имитаций зависимостей). Затем эти тесты прогоняются через агент под мутациями (с намеренными ошибками), чтобы убедиться, что тесты действительно проверяют реальную логику, а не просто успешный запуск. 2. Статический анализ и правила: Используются линтеры, анализаторы кода (ArchUnit) и платформенные правила для выявления архитектурных противоречий и нарушений стандартов. 3. Автоматизированное E2E тестирование: На стенде развития агент самостоятельно выполняет энд-ту-энд сценарии, имитируя работу пользователей. Это включает проверку обратимости действий и базовых краевых случаев. 4. Проверка нагрузок: Агент способен генерировать профиль нагрузки под нефункциональные требования, проверяя план запросов через EXPLAIN ANALYZE, выявляя узкие места в базе данных или блокировки потоков.

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

Будущее команд и доверие к пайплайну

Анализ инцидентов Microsoft Teams показывает, что разработчики находят только 6% серьезных ошибок, в то время как мониторинг и пользователи играют решающую роль. В командах, использующих агентов, распределение иное: пользователи и поддержка находят 25%, алерты — 30%, а сама команда — 38%. Это свидетельствует о том, что даже с мощными инструментами, «живые» данные и внешние факторы остаются критически важными.

Возникает вопрос о будущем ролевых моделей. Если агенты могут писать код, тестировать его и даже проводить часть архитектурного дизайна, границы между ролями разработчика, тестировщика и инженера размываются. Команды могут трансформироваться в небольшие группы, отвечающие за полный цикл от идеи до внедрения (от discovery до delivery), минимизируя потери на коммуникацию.

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

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