Когда тесты молчат: как ИИ-агент чинит баги

Автоматическое исправление багов силами LLM давно перестало быть экзотикой: модель умеет читать код, предлагать правки и даже запускать тесты. Но в реальных репозиториях всё ломается о неприятную деталь — проверять «починилось или нет» часто нечем. Если тестов нет, они слабые или не покрывают нужный юзкейс, система может сгенерировать патч, который формально зелёный, но проблему по сути не решает. В итоге получается косметический ремонт вместо настоящей починки.

Авторы работы InfCode: Adversarial Iterative Refinement of Tests and Patches for Reliable Software Issue Resolution смотрят на это по-новому: надёжность упирается в качество сигналов верификации. Если тесты не ловят дефект, даже очень умная LLM будет оптимизировать решение под неверную цель. Поэтому InfCode заставляет тесты и патчи «соревноваться» и постепенно усиливать друг друга.

Идея: патч и тест в одном цикле, но с элементом противостояния

В InfCode используется мультиагентная система из трёх ролей. Первый агент пишет и усиливает тесты, второй — предлагает исправления кода, а третий выступает в роли редактора и выбирает самый надёжный вариант из нескольких кандидатов.

Ключевой механизм — итеративное уточнение. Сначала агент для тестирования пытается воспроизвести баг: добавляет или правит тест так, чтобы ошибка проявилась. Затем агент для кода пишет патч, чтобы тесты проходили. Когда патч проходит текущий набор проверок, «соперник» возвращается и пытается сделать тесты строже: добавить крайние случаи, закрыть лазейки, повысить точность соответствия описанию задачи. Патчу снова приходится адаптироваться. Так система не довольствуется первой удачной заплаткой и старается дожать решение до более устойчивого.

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

Почему без отбора патчей всё равно легко ошибиться

Даже при хорошем цикле «тест ↔ код» можно получить несколько решений: часть будет не совсем устойчивой, часть — переобученной под конкретный тест, часть — случайно проходящей из‑за слабого покрытия. Поэтому в InfCode есть отдельная стадия отбора: агент Selector собирает все получившиеся кандидаты и оценивает их более строго — с учётом выполнения, совместимости с репозиторием и признаков переоптимизации. Судя по экспериментам авторов, именно этот отбор даёт очень заметный вклад в итоговое качество.

Что показали эксперименты на SWE-bench

Чтобы измерять прогресс честно, авторы используют бенчмарки семейства SWE-bench. В них задача формулируется как реальный issue из репозитория, а успех определяется тем, проходит ли официальная проверка исправления.

На SWE-bench Lite (300 задач) InfCode с моделью DeepSeek-V3 показывает лучший результат среди самых ильных подходов: около 40% решённых задач. Интересный момент — InfCode решает много «уникальных» задач, которые не решают другие методы.

На более строгом SWE-bench Verified авторы запускают InfCode с Claude 4.5 Sonnet и получают 79.4% — на момент отчёта это первое место в лидерборде.

Ожидание vs реальность

Отдельно авторы смотрят, как агенты пользуются инструментами: чаще всего вызывается bash (запуск тестов и команд), затем редактор, потом поиск. Bash может падать из‑за странных или отсутствующих команд, а редактор — из‑за строгих требований к точному совпадению фрагментов при замене. В целом частоты ошибок невысокие, но видно, где система чаще всего падает.

Что из этого следует

InfCode наглядно показывает, что в фиксах кода LLM упирается не только в «умение писать патчи», но и в качество обратной связи. Если тесты слабые, можно получить иллюзию успеха. Подход авторов ценен тем, что он делает тесты активным участником процесса и превращает верификацию в динамическую игру: патч становится лучше ровно потому, что тесты не дают ему расслабиться. А финальный отбор помогает не принять первый «зелёный» сигнал тестов за истину.

Ограничения тоже честно обозначены: агент для тестов может увлечься и начать генерировать проверки, которые формально ломают текущий патч, но хуже соответствуют смыслу issue. Это тонкая деталь: усиливать тесты нужно так, чтобы они оставались верными постановке задачи.

💾 Код