Агентному ИИ нужно больше тестировщиков, а не меньше

Агентный ИИ меняет процесс выпуска программного обеспечения. Ассистенты составляют запросы на слияние, агенты запускают миграции, а боты для проверки кода объявляют изменения безопасными, пока человек еще не успел допить кофе. В отрасли это часто представляют как путь к сокращению числа специалистов по качеству. Но это представление ошибочно. Чем большую часть кодовой базы создают машины, тем ценнее становится не способность генерировать код, а умение независимо его проверять.

Опрос разработчиков Stack Overflow за 2025 год — Stack Overflow Developer Survey — показал, что 84% респондентов уже используют инструменты ИИ в разработке или планируют начать их использовать, а 51% профессиональных разработчиков прибегают к ним ежедневно. Доля положительно настроенных респондентов снизилась до 60%; при этом разработчиков, активно не доверяющих точности ответов ИИ (46%), больше, чем тех, кто ей доверяет (33%). Главной причиной недовольства, которую назвали 66% опрошенных, стали решения, которые почти верны, но все же не совсем правильны. В исследовании DORA за 2025 год сообщалось, что ИИ используют 90% специалистов по разработке программного обеспечения; более 80% из них отметили, что ИИ повысил их продуктивность, однако лишь 24% сообщили о значительном или очень высоком доверии к нему. Именно в таких условиях, когда ИИ полезен, но ему не доверяют, работа тестировщика расширяется, а не сокращается.

Скорость — не доказательство

Я работаю инженером по качеству программного обеспечения и занимаюсь агентным тестированием и контрольными этапами CI для кода, созданного ИИ. В нашей команде мы внедрили средство проверки запросов на слияние и генератор тестовых сценариев. Оба инструмента только готовят черновики. Ни один из них не проверяет собственную работу. Это правило важно, потому что агенты говорят уверенно. Но уверенность не означает точность.

Мы убедились в этом дорогой ценой. Во время пилотного проекта с инструментом проверки запросов на слияние, созданным с помощью ИИ, одно изменение прошло CI менее чем за 4 минуты. Два дня спустя на связанной с ним панели отображались невозможные значения температуры. В одном из путей выполнения кода перепутали коэффициенты пересчета из градусов Цельсия в градусы Фаренгейта, а набор тестов этот путь не проверял. Сборка прошла успешно. Продукт работал неправильно. Зеленый статус CI, за которым не стоит проверка сложных случаев, — это театр.

Этот случай — часть более широкой закономерности. В отчете CodeRabbit «Состояние генерации кода ИИ и человеком» проанализировали 470 запросов на слияние из открытых репозиториев GitHub (320 были созданы совместно с ИИ, 150 — только людьми). Изменения, созданные с помощью ИИ, приводили примерно в 1,7 раза к большему числу проблем в целом; ошибки логики и корректности встречались на 75% чаще, а число проблем безопасности было выше вплоть до 2,74 раза. В отчете Veracode за 2026 год «Отчет о безопасности кода, созданного с помощью GenAI» модели проверили на выполнении задач, связанных с безопасностью. Средняя доля успешно пройденных проверок безопасности составила 56% — лишь немногим больше 55% в предыдущем отчете; при этом примерно в 44% задач по генерации кода с помощью ИИ появлялась известная уязвимость. Синтаксические ошибки почти перестали быть проблемой. Но безопасное и корректное поведение — все еще проблема. Тестировщики не позволяют путать одно с другим.

Вымышленные зависимости — проблема тестирования

Генерация кода приводит и к появлению вымышленных пакетов. В исследовании USENIX Security 2025 «У нас для вас есть пакет!» оценили галлюцинации пакетов в ответах 16 больших языковых моделей, генерирующих код, на 576 000 примерах. Коммерческие модели в среднем выдумывали пакеты как минимум в 5,2% случаев; средний показатель моделей с открытым исходным кодом составил 21,7%, при этом было сгенерировано 205 474 уникальных вымышленных названия. Постоянное появление таких фантомных пакетов создает благоприятные условия для атак с регистрацией вымышленных пакетов: злоумышленники регистрируют придуманное название и ждут, пока разработчик или агент установит этот пакет.

Проверка происхождения зависимостей должна быть таким же обязательным этапом, как и функциональные тесты. Если агент выдумывает пакет NuGet или npm, слияние должно блокироваться еще до обсуждения того, насколько тщательно были написаны модульные тесты. Проверка происхождения — не необязательная мера предосторожности. Это контрольный этап качества для изменений, созданных ИИ.

Контрольные этапы, рассчитанные на работу с агентами

Когда мы примерно за две недели с помощью автоматизации с поддержкой ИИ обновили .NET 8 до .NET 10 во всей организации, я отвечал за контроль качества. Скорость действительно была высокой. Но так же необходимы были проверки, которые не принимают на веру сводку агента. Для измененного кода я использую следующие контрольные этапы:

• Целевые показатели мутационного тестирования в диапазоне от 60% до 70% для затронутой логики, чтобы набор тестов обнаруживал реальные мутации, а не просто охватывал строки кода
• Тесты на основе свойств для логики с высоким риском, поведение которой невозможно достаточно точно определить одними лишь примерами
• Проверки происхождения зависимостей для защиты от атак с регистрацией вымышленных пакетов и галлюцинаций пакетов
• Показатели дублирования и интенсивности изменений, выявляющие хаотичное копирование и вставку кода агентами
• Независимая проверка утверждений агента, например «миграция завершена», поскольку любое утверждение остается гипотезой, пока не появятся подтверждающие данные

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

Ничто из этого не заменяет тестирование API, проверку аутентификации, дымовое тестирование или автоматизацию тестирования пользовательского интерфейса. FlaUI и PowerShell по-прежнему выявляют проблемы, которые не находят API-тесты. Упаковка с помощью NuGet, MSI и MSM все так же требует проверки установки и сценария установки без участия пользователя. Агентные процессы увеличивают объем работы. Но они не отменяют эти практики.

Тестировщиков нужно больше, но их работа меняется

Опасение состоит в том, что агенты будут писать тесты, а люди станут не нужны. Агенты могут создавать тестовые сценарии, но не должны сами проверять их. Среди респондентов Stack Overflow, планирующих в будущем использовать ИИ для тестирования, недоверие к людям по-прежнему занимает центральное место: главной причиной обратиться за помощью к другому человеку было недоверие к ответам ИИ. Это чутьё — сильная сторона профессии.

Здесь важно нанимать и поддерживать людей, пришедших в профессию нетрадиционным путём. Я перешёл в сферу контроля качества после карьеры в операционной работе в HR и работе с данными, в мае 2024 года получил степень магистра информационных систем в UMBC, а теперь посвящаю рабочие дни тому, чтобы сделать практичным применение контрольных рубежей для агентных систем. Агентный ИИ не будет ждать, пока у всех появится одинаковое образование и опыт. Ему нужно больше людей, умеющих выстраивать доказательную базу, а не меньше тех, кто не глядя одобряет успешно прошедшие сборки.

Вопрос о продукте прост. Если агенты выпускают изменения быстрее, чем вы успеваете продумывать их проверку, это не повышает производительность. Это лишь откладывает инцидент. Вкладывайтесь в тестировщиков, которые с подозрением относятся к каждому утверждению агента, встраивают мутационное тестирование и отслеживание происхождения в CI, а также сохраняют независимость суждений именно там, где модель наиболее убедительна и наименее надёжна. Агентному ИИ нужно больше тестировщиков, а не меньше.