Простое прохождение тестов не отражает всей картины; кодовая база, сгенерированная искусственным интеллектом, может незаметно деградировать. Большая часть существующих бенчмарков для ИИ-систем, создающих код, фокусируется на одном вопросе: удалось ли агенту произвести код, успешно проходящий текущие проверки? Хотя это полезный критерий, он слишком узок. Разработка программного обеспечения — это итеративный процесс, где требования постоянно меняются, возникают новые граничные случаи, а прежние проектные решения могут стать препятствием для будущей работы. Код, который сегодня проходит все тесты, завтра может значительно замедлить и удорожить изменения, одновременно увеличивая риски. Эта проблема становится всё более актуальной по мере того, как искусственный интеллект увеличивает объёмы генерируемого кода. По мере удешевления генерации кода основной вопрос трансформируется из "может ли агент создать рабочий фрагмент?" в "какую кодовую базу формирует многократное использование агента в долгосрочной перспективе?", отмечает руководитель компании Hypersequent.
Содержание
Новое исследование о деградации кода
Недавнее исследование под названием "SlopCodeBench: Оценка деградации кодирующих агентов в длительных итеративных задачах" (Орлански и соавторы) подошло к этой проблеме значительно ближе, чем большинство других бенчмарков. Вместо оценки разовых решений, оно заставляет ИИ-агентов развивать свой собственный предыдущий код в рамках 20 задач и 93 контрольных точек. На каждой контрольной точке спецификация задачи менялась. При этом агент не начинал с нуля и не получал готового внутреннего плана; ему приходилось учитывать ранее принятые решения. Такая постановка задачи более точно имитирует реальную разработку, поскольку команды программистов постоянно работают с наследием предыдущих решений.
"Зелёные" тесты могут скрывать ухудшение кодовой базы
В дополнение к проверке корректности, в исследовании отслеживались два показателя качества кода. Избыточность (Verbosity) оценивала наличие повторяющегося или дублирующегося кода, а структурная эрозия (Structural erosion) измеряла, насколько сложность кодовой базы концентрируется внутри уже чрезмерно сложных функций. Эти типы ошибок хорошо знакомы любому руководителю инженерного отдела. Система может продолжать успешно проходить тесты, в то время как всё больше логики проталкивается в одни и те же крупные функции, а количество специальных случаев увеличивается. Для внедрения каждой новой функции требуется вносить изменения во всё большее число файлов. Программное обеспечение по-прежнему работает, но становится гораздо сложнее в модификации. Пример поиска кода, использованный в исследовании, хорошо иллюстрирует эту проблему. Вначале система должна была находить код на Python, используя точный текст или регулярные выражения. Позднее ей потребовалось обрабатывать больше языков, понимать структуру кода (например, через построение абстрактного синтаксического дерева) и даже автоматически исправлять ошибки. Если первоначальный дизайн был слишком строгим и содержал ранние необоснованные допущения, он мог пройти первые тесты, но с трудом справлялся бы со сложными, поздними требованиями.
Результаты исследования
Результаты исследования оказались однозначными. Ни один из оценённых ИИ-агентов не смог полностью решить ни одну из задач. Наилучший показатель строгого прохождения составил 17,2 процента, а к последней контрольной точке он упал до 0,5 процента. По мере итераций избыточность кода возросла в 89,8 процента случаев, а структурная эрозия — в 80 процентах. Сравнение с кодом, поддерживаемым людьми, оказалось ещё более показательным. По сравнению с 48 репозиториями на Python, поддерживаемыми людьми, код, сгенерированный агентами, был в 2,2 раза более избыточным и подверженным структурной эрозии. Авторы отслеживали 20 из этих репозиториев в течение времени, и человеческий код оставался относительно стабильным, в то время как код, созданный ИИ-агентами, ухудшался с каждой итерацией. Прохождение тестового набора лишь подтверждает, что последняя версия соответствует известным проверкам, но не сообщает, становится ли код более хрупким или дорогостоящим для расширения.
Значение для обеспечения качества (QA)
Для руководителей отделов обеспечения качества (QA) из исследования вытекают два ключевых вывода. Первый очевиден: код продукта, созданный искусственным интеллектом, может деградировать при многократных изменениях, даже если текущие тесты остаются "зелёными", то есть успешными. Команды могут воспринимать непрерывный успех как доказательство стабильности системы, хотя на самом деле они могут накапливать будущие затраты на исправление регрессий с возрастающей скоростью. Второй вывод касается непосредственно работы QA. Команды обеспечения качества теперь используют ИИ-инструменты для написания и поддержки тестов, особенно для автоматизации функционального тестирования пользовательского интерфейса с помощью таких средств, как Playwright. Эта работа подчиняется той же логике, что и в исследовании: продукт меняется, тест должен меняться, каждая новая функция добавляет новую ветку, новый селектор, новое исключение или новую вспомогательную функцию. Хотя исследование посвящено кодированию в целом, а не конкретно автоматизированным тестовым пакетам, описанный механизм применим и здесь. Тестовый набор также может стать избыточным и структурно слабым при многократных редактированиях с помощью ИИ. Деградацию тестового набора сложнее заметить, чем деградацию продуктового кода. Конвейер сборки может оставаться "зелёным", а сам набор тестов может выглядеть более объёмным на бумаге. Покрытие кода может казаться улучшенным. Между тем, основной актив может деградировать. Это может включать неверные селекторы, слабые проверки, скопированные шаги тестов, чрезмерно большие вспомогательные функции и UI-тесты, которые трудно исправить и легко поставить под сомнение. В то время как нестабильность тестов (flakiness) очевидна, проблемы, такие как неэффективные тесты или очень медленные тесты, могут быть не замечены сразу. Для руководителей QA это меняет характер работы. Обеспечение качества не может ограничиваться валидацией последнего выпуска на соответствие текущим требованиям. Необходимо также отслеживать, не наносит ли непрерывное изменение ущерб как самому продукту, так и системе тестирования, предназначенной для его защиты. Роль руководства QA меняется; обеспечение качества теперь должно выходить за рамки простой проверки последнего выпуска продукта на соответствие текущим требованиям. Руководители QA также должны следить за тем, не оказывает ли непрерывное изменение негативного влияния как на качество продукта, так и на целостность системы тестирования, призванной его защищать.
Простое создание запросов не решит проблему
В исследовании также проверялось, могут ли более качественные запросы (промпты) контролировать деградацию кода. Вначале они помогали, но ненадолго. Запросы, ориентированные на качество, снижали первоначальную избыточность и эрозию. Например, один из анти-мусорных запросов сократил первоначальную избыточность примерно на треть при использовании модели GPT-5.4. Однако изменения были минимальными. Даже более чистые начальные точки кода деградировали примерно с той же скоростью, а более качественный код не приводил к надёжному улучшению показателей прохождения тестов. В некоторых случаях такие запросы даже увеличивали затраты. Многие организации рассматривают промптинг как уровень управления. Хотя это и помогает, этого недостаточно. Если рабочий процесс продолжает требовать от ИИ-агента расширять свой собственный код при меняющихся требованиях, организации всё равно необходимы механизмы контроля, выходящие за рамки простых запросов.
Улучшенный подход к оценке ИИ-помощи в разработке
Для эффективного управления разработкой с помощью ИИ необходимо смотреть дальше быстрых побед. Важно оценивать изменения в коде после нескольких корректировок, а не только после первой правки. Следует внимательно следить за сложными или повторяющимися фрагментами кода. Не стоит путать успех в текущей задаче с уверенностью в долгосрочной стабильности. Простоту поддержки кода необходимо рассматривать как риск релиза, особенно для систем, работающих с критически важными данными, такими как стоимость, идентификаторы пользователей, права доступа, финансовые операции или правила. То же правило применимо и к тестам. Нужно анализировать, как меняется код тестов, сгенерированный ИИ, после нескольких итераций продукта. Стоит обратить внимание на тестовые наборы, которые растут быстрее, чем их реальная ценность, а также на UI-тесты, которые поглощают логику, которую лучше проверять на более низких уровнях. Также следует остерегаться "самовосстанавливающегося" обслуживания, которое незаметно снижает строгость проверок. Более крупный набор тестов автоматически не означает лучшего контроля. Контроль качества должен смещаться вверх по процессу разработки. К моменту, когда функция достигает финальной валидации, часть ущерба уже может быть заложена в путь, который система прошла, чтобы достичь этой точки. QA должно иметь голос на более ранних этапах цикла: в формировании проектных ограничений, стандартов ревью, стратегии регрессионного тестирования и определении приемлемого качества изменений как для продуктового кода, так и для тестового кода. В конечном итоге, прохождение тестов по-прежнему важно, но по мере того, как ИИ увеличивает объём изменений в коде, более значимым становится вопрос о том, делает ли каждое успешное изменение кодовую базу более безопасной для расширения или более опасной для дальнейших правок.
