Девять реальных багов в Kubernetes, один и тот же модельный стек и лимит в пять минут на задачу: такой бенчмарк показал, что AI-агенты уже умеют находить и чинить изолированные ошибки, но заметно буксуют там, где нужно понять последствия для всей системы. Для команд, которые присматриваются к агентам не как к игрушке для демо, а как к рабочему инструменту в большом коде, вывод неприятный, но полезный: проблема не сводится к тому, насколько красиво вы прикрутили поиск по репозиторию.
Об этом, как пишет InfoQ, рассказал автор исследования Брэндон Фоли, опубликовавший результаты на блоге CNCF. В качестве полигона он взял pull request’ы из репозитория Kubernetes: не синтетические задачки для презентации, а реальные баги, которые в проекте действительно исправляли живые контрибьюторы. Каждому агенту давали только описание issue, без описания PR и без diff, чтобы не подсказывать решение в лоб.
В тесте участвовали три конфигурации. Первая работала только через RAG: поиск по коду шел через KAITO RAG Engine на базе Qdrant, с комбинацией BM25 и семантического поиска по эмбеддингам. Вторая была гибридной: сначала обязательный проход через RAG, потом доступ к локальной файловой системе. Третья вообще обходилась без индекса и работала только с локальным клоном репозитория. Во всех случаях использовалась одна и та же модель, Claude Opus 4.6, одинаковый формат ответа и одинаковый тайм-аут в пять минут. Менялся только способ, которым агент видел код.
Быстрее не значит умнее
По скорости и стоимости картина получилась довольно приземленной. RAG-only оказался самым быстрым: в среднем 76 секунд на задачу. Логика простая: агент не тратит время на навигацию по дереву проекта и сразу генерирует ответ по найденным фрагментам. Гибридный режим, наоборот, стал самым медленным: около двух с половиной минут в среднем, потому что обязательный этап поиска через RAG добавляет еще один круг перед тем, как агент начинает локальное исследование.
По деньгам гибрид тоже проиграл. И не потому, что прочитал больше кода, а потому что чаще дергал модель. Для stateless API это важная деталь: каждый новый вызов тащит за собой всю историю диалога, а значит, растут и задержки, и расход токенов. Исследование прямо указывает, что число вызовов модели было главным драйвером и стоимости, и latency. Для бизнеса это почти скучная, но важная новость: дорогим делает не только размер контекста, но и архитектура самого агентного цикла.
Но самое интересное началось там, где скорость перестала быть главным критерием. Основной тип ошибки у агентов был не в том, что они предлагали откровенно неверный патч. Проблема чаще выглядела тоньше и потому опаснее: фикс был неполным. Агент находил «главную» неисправность, правил ее, а затем останавливался, не проверив, какие соседние части системы тоже нужно обновить. Где-то он исправлял один вариант реализации и пропускал второй, где-то закрывал центральный дефект, но не трогал связанную интеграционную логику. В отдельных случаях агент вообще прекращал работу, заметив, что в кодовой базе уже есть частичное исправление.
Если перевести это с языка бенчмарков на язык production-команды, получается неприятный паттерн: AI-агенты неплохо отвечают на вопрос «что здесь сломано?», но заметно хуже справляются с вопросом «что еще придется поменять, чтобы это не сломалось в соседнем модуле». А это уже не косметика. В сложных системах именно поиск полного охвата изменений обычно и съедает львиную долю инженерного времени.
Проблема не только в поиске по коду
Исследование бьет и по популярной идее, что качество автопочинки багов почти целиком упирается в retrieval. Да, стратегия поиска влияла на то, как агент добирался до нужного куска системы. В одном из кейсов принудительное использование RAG даже помогло: агент сначала нашел корректный слой policy evaluation и поэтому сделал более удачный архитектурный выбор. Но после нахождения релевантного кода картина не менялась: рассуждение все равно оставалось локальным. Иначе говоря, retrieval помогает с навигацией, но не покупает понимание системных последствий.
Есть и еще один показательный эпизод. Когда агентам оставляли пространство для архитектурного выбора, они тяготели к созданию новых абстракций вместо повторного использования уже существующих. В одном тесте правильное исправление опиралось на поле RestartCount, но все агенты предпочли добавить новое поле Attempt. Формально поведение становилось корректным, но решение получалось тяжелее и менее аккуратным с точки зрения архитектуры. Для тимлидов это звучит знакомо: код вроде работает, а потом полгода живет как лишняя сущность, которую никто не просил.
Самый практичный вывод исследования, возможно, вообще лежит не в области моделей и не в области RAG. Когда bug report был хорошо специфицирован и сразу называл точный файл, функцию и ожидаемое поведение, все три подхода сходились к высоким результатам, а разница между retrieval-стратегиями почти исчезала. То есть качество человеческого описания задачи оказалось более сильным рычагом, чем выбор между индексом, гибридом и локальным клоном. Для разработчиков это неприятно только в одном смысле: волшебной кнопки снова не будет. Для продактов, платформенных команд и IT-руководителей вывод еще прямее: если хотите получить пользу от агентных инструментов, сначала придется привести в порядок входные артефакты, а уже потом спорить о том, какой движок поиска лучше ранжирует фрагменты кода.
На фоне разговоров о fully autonomous coding этот бенчмарк звучит почти как холодный душ. AI-агенты уже полезны там, где задача четко очерчена и границы исправления понятны заранее. Но как только баг расползается по нескольким слоям системы, главный дефицит возникает не в доступе к коду, а в умении определить истинный объем изменений. Возможно, следующим полем конкуренции станут не более хитрые RAG-обвязки, а навыки и playbook’и, которые учат агента проверять зависимые участки кода. Правда, у больших репозиториев и здесь плохая привычка: любые такие навыки быстро устаревают. Подробнее о самом бенчмарке можно посмотреть в материале .