Мой блог
Агентская разработка и качество кода: результаты шести месяцев без ручного написания программ
Полный переход IT-команд на автономное написание кода с помощью нейросетей существенно меняет объемы поставок и структуру дефектов. Опыт внедрения AI-ассистентов показывает, что ключевым фактором становится не скорость генерации, а надежность инженерной проверки. Практический разбор показывает, как агентская разработка и качество кода взаимосвязаны при кратной трансформации процессов контроля.
В материале тимлида Игоря Симакова обобщены результаты шести месяцев работы двух продуктовых команд в режиме полного отказа от ручной написания кода. Инженеры бэкенда, фронтенда и специалисты QA перешли на управление AI-агентами. Стандартный стек сервисов включает Java, Spring, Kafka, PostgreSQL и Kubernetes, а в качестве основного инструмента генерации применяется Claude Code на базе модели Opus с правилами, зафиксированными непосредственно в репозиториях.
Влияние автономных агентов на объемы кода и частоту релизов
Штат тестирования из трех человек (один гибридный специалист, один ручной тестировщик и один автоматизатор) остался неизменным, однако объемы производимой разработки выросли в несколько раз. Анализ сведений за годовой период показал следующие изменения показателей:
- Количество мерж-реквестов увеличилось со 199 до 351 за квартал;
- Средний объем одного мерж-реквеста вырос со 160 до 280 строк кода;
- Суммарный объем поставляемого кода поднялся с 32 тысяч до 97 тысяч строк в квартал.
Сопоставление данных подтверждает: производительность выросла ровно в три раза. Однако вместе с ростом объема поставляемого функционала проявился пропорциональный рост количества пропускаемых ошибок на продуктовые контуры.
Категории дефектов: что выявляется до продуктовой среды, а что попадает в релиз
Детальный разбор 268 багов, зафиксированных за год работы двух команд, показал, что характер возникающих ошибок не изменился по сравнению с периодом ручной разработки. Основная проблема заключается в их частоте, вызванной возросшим объемом релизов. По типу проявления дефекты четко разделяются на две категории:
- Функциональные дефекты: ошибки в пользовательской логике и интерфейсе. Процесс их перехвата остался эффективным — благодаря автотестам на Playwright и ручным проверкам на прод уходит лишь каждый шестой баг (около 16,7%).
- Технические (инженерные) дефекты: нештатное поведение подкапотных систем. Процент пропуска на прод составляет 66,7% (два дефекта из трех). Их количество выросло с единичных случаев до трех десятков за квартал.
Ключевыми источниками инженерных сбоев стали несогласованность внешних контрактов, ошибки соседних сервисов при троттлинге, некорректная обработка таймаутов, пиковые нагрузки на открытые API, некорректные трансферы данных между базами, отсутствие обратной совместимости при миграциях и состояние гонки при параллельных обновлениях записей.
Причины неэффективности расширения штата ручного тестирования
Простая наймовая компенсация через увеличение количества тестировщиков не дает нужного эффекта. Специалисты по ручному тестированию проверяют стандартные пользовательские сценарии и базовые граничные условия. Они физически не способны воспроизвести гонки потоков, утечки памяти (Out of Memory) или сбои при сложной пагинации под высокой нагрузкой.
В материале приводится ссылка на концепцию из книги «Angry Tests» Егора Бугаенко, где подчеркивается необходимость создания разрушительных и агрессивных тестовых сценариев. Однако на практике классическое QA сосредоточено на подтверждении работоспособности заявленного функционала, что оставляет техническую часть уязвимой.
Кто фиксирует сбои на продуктовых серверах
Распределение источников обнаружения технических проблем на продуктовом контуре в рассматриваемых командах выглядит следующим образом:
- 38% дефектов выявляет сама команда через внутренний анализ логов и метрик;
- 30% неисправностей фиксируется автоматическими алертами и системами мониторинга;
- 25% багов поступает от пользователей и смежных команд.
Для сравнения в первоисточнике приводится исследование Microsoft Teams (Ghosh et al., SoCC 2022) по анализу 152 тяжелых инцидентов. Там 55% проблем находили автоматические мониторы и только 6% выявляла непосредственно команда разработки.
Многоэтапный конвейер проверки и валидации кода нейросети
Чтобы минимизировать попадание инженерных багов в релиз, была сформирована новая последовательность контроля, сочетающая автоматизированные проверки и участие агента на всех стадиях CI/CD.
Предварительное проектирование и генерация сплошных интеграционных тестов
Процесс начинается с формирования документа ADR (Architecture Decision Record) и согласования межсервисных контрактов. После этого нейросеть создает основной код вместе с детальными интеграционными тестами без использования моков. Для проверки качества самих тестов применяется мутационное тестирование: Claude искусственно вносит дефекты в сформированный код, проверяя, падают ли созданные тесты.
Автоматизированный анализ и прогон сценариев на тестовых окружениях
Кодовая база проходит через статические анализаторы, линтеры, правила ArchUnit и автоматические тесты структуры БД. После завершения этапа код-ревью агент разворачивает изменения на dev-стенде. Нейросеть самостоятельно выполняет REST-запросы, проверяет состояние базы данных на чтение и валидирует сохранение обратной совместимости.
Нагрузочное тестирование и канареечное развертывание
На stage-стенде с обезличенными данными Claude запускает нагрузочные профили и анализирует планы выполнения SQL-запросов через EXPLAIN ANALYZE. Это позволяет заранее определить узкие места: блокировки таблиц, недостаток потоков или неоптимизированные индексы. Выкатка в продуктивную среду производится канареечным методом под контролем агента, отслеживающего метрики в Grafana, логи Kubernetes и сетевой трафик.
Изменение роли инженеров и перспективная трансформация команд
Внедрение генеративных инструментов меняет обязанности инженеров по качеству. В рассматриваемом примере активность специалистов QA в репозиториях автотестов выросла с 6 мерж-реквестов в первом квартале до 34 в третьем. Тестировщики переходят от проверки UI к проектированию тестовых сред и системных сценариев.
Тенденция перекликается с практикой компании «Авито», где происходит постепенное сокращение узких специализаций и переход к компактным командам полного цикла (от discovery до delivery). Разработчики перестают быть просто авторами строк кода и становятся архитекторами автоматизированных пайплайнов проверки, в которых AI-агент берет на себя исполнение, а человек задает правила, анализаторы и ограничения.
