Бенчмарк CanItDelete выявил: ИИ-модели избегают удаления кода

Исследователи описали системную слабость больших языковых моделей (LLM) при редактировании production-кода: модели избегают удаления кода, которое требуется по условию правки, авторы называют это deletion avoidance («избегание удаления»). Даже когда патч успешно проходит тесты, кодовая база после такой правки часто становится сложнее поддерживать.

На официальном лидерборде SWE-bench Verified авторы проверили пять ведущих моделей: даже на задачах, которые решают все пять, полнота удаления кода (deletion recall) относительно эталонного патча разработчика достигает максимум 71,7%. При этом модели попадают в нужный файл более чем в 92% случаев, когда требуется удаление, но вырезают именно нужную строку менее чем в 52% случаев. Вместо удаления 29,0% проходящих патчей оборачивают целевой код в защитную конструкцию или запасной путь (fallback), этот паттерн авторы назвали Guard-and-Go.

Такие патчи проходят проверку потому, что исходные тесты SWE-bench редко проверяют именно факт удаления кода. Когда авторы дооснастили 34 задачи из SWE-bench Verified тестами, которые проваливаются, если целевой код остался в кодовой базе, суммарная успешность четырёх передовых моделей (как с закрытыми, так и с открытыми весами) упала с 63,2% до 41,9%.

Поскольку в реальных правках удаление обычно сочетается с добавлением кода, авторы собрали отдельный бенчмарк CanItDelete, 200 задач из реальных коммитов, где вся требуемая правка сводится только к удалению, без добавления. Даже без работы по добавлению кода лучшая модель проваливает каждую пятую задачу, а более компактные открытые модели справляются лишь в 18,0% случаев.

Затем авторы провели абляцию модели GPT-5.6 Sol на четырёх последовательно усиливающихся подсказках: успешность почти не менялась, пока модели не давали точные строки для удаления, это почти полностью устраняло неполное удаление, но подняло успешность лишь до 80,5%, потому что модель начинала либо удалять за пределы указанных строк, либо вместо удаления добавлять код.

Наконец, в пилотном исследовании авторы показали возможное решение: обучение модели удалению кода на этапе постобучения (post-training) снижает избегание удаления и одновременно улучшает более широкие показатели редактирования кода, это говорит о том, что проблема связана с недостаточным обучением, а не с принципиальной неспособностью моделей.

Ключевые факты

На SWE-bench Verified пять ведущих моделей достигают максимум 71,7% полноты удаления кода и вырезают точную нужную строку менее чем в 52% случаев
29,0% проходящих тесты патчей не удаляют целевой код, а оборачивают его в защитную конструкцию, паттерн назвали Guard-and-Go
Тесты, специально проверяющие факт удаления (34 задачи), обрушивают суммарную успешность четырёх передовых моделей с 63,2% до 41,9%
Новый бенчмарк CanItDelete из 200 задач только на удаление: лучшая модель проваливает каждую пятую задачу, компактные открытые модели, успешны лишь в 18,0% случаев
Прямая подсказка с точными строками поднимает успех GPT-5.6 Sol лишь до 80,5%; пилотное дообучение на этапе постобучения снижает избегание удаления

Почему это важно

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

Кому это важно

В первую очередь, разработчикам и командам, использующим ИИ-агентов и ассистентов для автоматических правок и рефакторинга production-кода, а также авторам инструментов код-ревью, которым нужно закладывать проверку удаления в процесс приёмки патчей. Значимо это и для лабораторий, создающих модели для кодинга: работа указывает конкретный, измеримый пробел в обучении, который можно закрывать целенаправленно.

Как это применить

Авторы показывают практический рецепт: тестовые наборы для приёмки ИИ-патчей должны отдельно проверять, что предписанный к удалению код действительно удалён, а не обёрнут в guard/fallback, по образцу 34 дооснащённых задач из SWE-bench Verified. При ревью автоматических правок стоит с подозрением относиться к патчам, которые оставляют старый код «на всякий случай». Явное указание точных строк для удаления заметно снижает неполное удаление (хотя и не устраняет проблему целиком), а на уровне обучения моделей пилотное исследование показывает: включение задач на удаление в постобучение снижает deletion avoidance и одновременно улучшает более широкие показатели редактирования кода.

Можно ли доверять

Методология выглядит основательной: измерения проведены на официальном лидерборде SWE-bench Verified по пяти ведущим моделям, эффект перепроверен ретрофит-тестами на 34 задачах, для чистой оценки удаления собран отдельный бенчмарк CanItDelete из 200 задач по реальным коммитам, а вывод о причинах подкреплён абляцией с четырьмя последовательными подсказками и пилотным экспериментом по дообучению. Все ключевые цифры (71,7%, 92%, 52%, 29,0%, 63,2%→41,9%, 18,0%, 80,5%) приведены в самом тексте. Из ограничений: в доступном фрагменте не названы конкретные пять моделей, четыре передовых модели и компактные открытые модели, участвовавшие в тестах, не указаны авторы и организация, а детали метода дообучения в пилотном исследовании не раскрыты.

Риски и подводные камни

Главный риск, ложное чувство надёжности: патч, прошедший тесты, может на деле не выполнять требуемое удаление, а маскировать проблему обёрткой, из-за чего технический долг и мёртвый код накапливаются незаметно для команды. Бенчмарк CanItDelete и абляция ограничены масштабом (200 задач, эксперимент с подсказками, на одной модели, GPT-5.6 Sol), а предложенное решение через постобучение описано только как пилотное исследование, а не как проверенный в промышленном масштабе метод.