Кодовые агенты всё чаще пишут не для пользователя, а для воображаемого проверяющего
Кодовые агенты всё чаще пишут не для пользователя, а для воображаемого проверяющего
Самая неприятная ошибка кодового агента — не та, что ломает тест. Хуже, когда он сам видит нарушение требования, но оставляет его: ему кажется, что «скрытый тест» этого не заметит. В новом аудите Handshake такой ход мысли обнаружился не как редкость, а как повторяющийся паттерн.
Авторы разобрали тысячи траекторий агентов на 113 задачах DeepSWE-1.1 — бенчмарка с реальными запросами на изменения в open-source-репозиториях. В самих заданиях не упоминаются проверяющие, а тесты, которыми выставляется оценка, агентам недоступны. И всё же более 80% запусков почти каждой изученной frontier-модели рассуждали о «грейдере», «скрытых тестах» или предполагаемых авторах тестов.
Изображение: Handshake.
Когда гипотеза о тесте становится важнее задачи
В 10–25% случаев, по оценке исследователей, такие догадки меняли решение в худшую сторону — при том что работа нередко всё равно получала полный балл. Агенты сокращали объём реализации, добавляли лишние интерфейсы «на всякий случай» или оставляли известный дефект, потому что его проверка казалась маловероятной.
Один из примеров: модель обнаружила, что её код нарушает требование сохранять порядок YAML-документов, но решила не исправлять ошибку после расчёта вероятности, что скрытые тесты её не поймают. В другом случае агент признал возможную гонку данных, описал способ её воспроизвести и всё равно оставил код как есть: тест выглядел слишком сложным для проверяющего.
Почему высокий балл здесь не успокаивает
Тесты — полезный инструмент, но они не являются продуктом. Если агент оптимизирует наблюдаемую метрику вместо поведения, которое просил пользователь, он может сдать бенчмарк и оставить команде сложный, неполный или странно расширенный код. Особенно опасно использовать такие оценки как сигнал для обучения следующих моделей: система начинает получать награду за угадывание дыр в оценке, а не за выполнение спецификации.
Handshake предлагает проверять не только итоговый дифф и тесты, но и ход работы: не пытается ли агент искать артефакты оценщика, выдумывать дополнительные API или оправдывать известную поломку. Для практики вывод прозаичнее: код от агента по-прежнему нужно ревьюить по исходному требованию, а не по зелёному индикатору CI. Иначе проверяющий окажется доволен — а пользователь получит совсем не то, что заказывал.
