SWE-Explore: AI-агенты находят файл, но теряют строки кода
SWE-Explore отделяет поиск контекста от написания патча и показывает: попасть в правильный файл мало, если агент не поднял нужные строки вовремя.
SWE-Explore: AI-агенты находят файл, но теряют строки кода
SWE-Explore показывает неприятную деталь в работе coding agents: попасть в правильный файл ещё не значит понять задачу. Агент может открыть нужный модуль, пройти рядом с причиной бага и всё равно не поднять строки, без которых патч превращается в угадывание.
SWE-Explore — это benchmark для оценки того, насколько точно AI-агенты находят релевантные участки кода в репозитории до генерации патча. Он измеряет coverage, ranking и context efficiency, а не только финальный pass/fail. Поэтому его лучше читать не как «ещё один лидерборд», а как попытку разобрать ремонт кода на этапы.
В этом и есть ценность работы. SWE-bench и похожие тесты отвечают на вопрос: прошёл ли патч тесты. SWE-Explore спрашивает раньше: видел ли агент те строки, которые вообще давали шанс написать правильный патч.
Что именно измеряет SWE-Explore
В постановке benchmark-а агент получает issue и snapshot репозитория. Его задача — вернуть ранжированный список участков кода: файлы и диапазоны строк. Патч писать не нужно. После этого ответ сравнивается с line-level ground truth, который авторы извлекли из успешных траекторий других агентов.
По arXiv-версии статьи, SWE-Explore покрывает 848 issues, 203 open-source репозитория и 10 языков программирования. Ground truth строится не вручную с нуля: исследователи смотрят, какие строки читали независимые агенты в успешных решениях, выделяют core context и optional context, затем проверяют продвинутые регионы вручную.
Это важное отличие от более грубой локализации. File-level hit говорит: агент нашёл правильный район. Line-level coverage говорит: он действительно вытащил улицу и дом, где лежала причина задачи.
Почему pass/fail скрывает половину проблемы
Обычный end-to-end benchmark смешивает несколько способностей. Агент должен понять issue, найти контекст, локализовать баг, написать патч и пройти тесты. Если итог failed, мы не всегда знаем, где именно всё сломалось. Он не нашёл нужный код? Нашёл, но не понял? Патч был близок, но не прошёл крайний случай?
На Toolarium уже был близкий разбор про repo-level code localization и keyword shortcut: модели иногда выглядят сильнее, чем есть, потому что угадывают файл по словам из issue. SWE-Explore двигает разговор ниже, к строкам. Найти файл мало, если нужный span оказался за пределами line budget.
| Метрика | Что показывает | Почему важна разработчику |
|---|---|---|
| Coverage | Какая доля релевантных строк попала в выбранный контекст. | Если coverage низкий, агент пишет патч по неполной картине. |
| Ranking | Насколько рано нужные строки появляются в ранжированном списке. | В реальном IDE-агенте первые строки получают больше внимания и токенов. |
| Context efficiency | Сколько полезного контекста агент приносит в ограниченный бюджет строк. | Длинный контекст не спасает, если он заполнен шумом. |
| Restricted-context repair | Можно ли починить issue, если фиксированному агенту дать только найденный контекст. | Проверяет, связаны ли метрики поиска с реальным ремонтом кода. |
Как строится line-level ground truth
Авторы берут успешные repair-траектории и извлекают наблюдаемое чтение кода: editor views, shell-команды вроде cat/head/tail/sed, а также search hits из grep. Затем эти сигналы нормализуются в repo-relative line regions. Случаи, которые нельзя уверенно привязать к конкретному файлу и диапазону строк, отбрасываются.
Дальше регионы агрегируются. Core context — это более консервативная часть, которая повторяется в успешных решениях и выглядит как действительно несущая evidence для патча. Optional context сохраняется для диагностики и context-efficiency. Авторы отдельно описывают LLM-assisted refinement и human audit: продвинутый регион должен существовать в snapshot-е, быть релевантным issue и правдоподобно участвовать в успешном решении.
Сама идея хорошо объясняет, почему context compression ломает AI coding agents. Проблема не только в том, что контекст длинный. Проблема в том, что важные строки могут исчезнуть из активного окна или прийти слишком поздно, когда агент уже построил неверную гипотезу.
Что показали результаты
Главный вывод статьи сдержанный: agentic explorers образуют слой выше классических retrieval-методов, но line-level coverage и эффективное ранжирование остаются трудными даже для сильных методов. В таблице результатов при K=5 file-level hit у современных агентов выглядит заметно лучше, чем line-level recall. Например, в официальной таблице для Claude Code HitFile указан как 0.667, а line-level recall — 0.154; для Codex HitFile — 0.649, а line-level recall — 0.194.
Это не значит, что Claude Code, Codex или другие инструменты «не умеют писать код». Это значит, что успешность патча и качество exploration нельзя подменять друг другом. Агент может быть полезен в end-to-end сценарии, но всё равно терять критические строки на этапе выбора контекста.
Соседний тренд мы уже видели в статье про Rubric-Based GRM для SWE agents: одного pass/fail мало, если мы хотим улучшать агентные системы, а не только сортировать их по итоговому проценту. SWE-Explore добавляет к этому промежуточную проверку: насколько хорошо агент нашёл evidence до правки.
Что это меняет для IDE-агентов и автономных правок
Для разработчика вопрос звучит просто: можно ли доверять агенту, который открыл правильный файл, но не прочитал нужный span? В маленькой задаче это может закончиться лишним коммитом. В большом репозитории — правкой рядом с проблемой, которая выглядит убедительно и проходит часть тестов, но ломает архитектурный инвариант.
Практический вывод для создателей IDE-агентов — показывать не только diff, но и evidence path: какие файлы и строки агент считал опорными, в каком порядке он их нашёл, какие альтернативные участки отбросил. Если этот путь пустой или состоит из keyword-hit вокруг issue, reviewer должен насторожиться.
Для команд, которые внедряют coding agents, SWE-Explore полезен как язык требований. Не «агент должен лучше понимать репозиторий», а конкретнее: повысить line-level recall, уменьшить шум в выбранном контексте, поднять нужные regions раньше в ranked output. Такие метрики уже можно тестировать в CI для агентных workflow.
SWE-Explore не заменяет SWE-bench. Он закрывает слепую зону перед патчем. И это правильный поворот: если мы хотим, чтобы AI-агенты не просто угадывали diff, а реально работали с кодовой базой, надо измерять момент, когда они выбирают, что читать.
Источники и дата проверки
Факты, цифры и ссылки проверены 14 июня 2026 года. Репозиторий и датасет SWE-Explore могут обновляться после публикации, поэтому результаты benchmark-а стоит сверять с актуальной версией проекта.
- arXiv: SWE-Explore: Benchmarking How Coding Agents Explore Repositories, submitted 5 июня 2026 года.
- HTML-версия статьи SWE-Explore, использована для методики и описания ground truth.
- GitHub: Qiushao-E/SWE-Explore-Bench, использован для релизной даты, диаграмм, quick start и изображений.
- The Decoder: AI coding agents find the right file but miss the exact lines that matter, использован как исходный news-сигнал.
