Как измеряют понимание репозитория у AI-агентов

Почему результата недостаточно

Традиционные оценки агентных систем обычно строятся вокруг конечной задачи. Агент получает описание проблемы, вносит изменения в код и проходит проверку.

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

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

Во всех этих случаях задача может быть формально выполнена.

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

Исследование репозитория как отдельный этап

Материалы Sourcegraph, OpenHands, Aider и исследовательские работы показывают схожую картину. Перед изменением кода агент обычно выполняет серию исследовательских действий.

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

При этом сама способность находить нужные части проекта становится важной частью решения задачи.

Если агент неправильно определил границы проблемы, дальнейшее качество генерации кода уже не имеет большого значения.

Именно поэтому в новых работах появляется идея оценивать исследование репозитория отдельно от итогового результата.

Что именно предлагается измерять

Судя по исследованию, внимание смещается от вопроса «решил ли агент задачу» к вопросу «как он нашёл решение».

Одним из примеров является направление Repository Exploration, где оценивается способность агента исследовать кодовую базу и находить релевантные участки проекта.

Вместо анализа готового патча исследователей начинает интересовать:

• какие файлы агент выбрал для изучения;

• насколько быстро он нашёл релевантный код;

• какие зависимости обнаружил;

• какие части репозитория проигнорировал;

• насколько эффективно использовал ограниченный контекст.

В такой постановке навигация по репозиторию становится самостоятельным объектом измерения.

Почему это связано с архитектурным пониманием

Большая часть современных агентных систем не читает весь репозиторий целиком.

В исследовании неоднократно встречается другой подход: агент строит промежуточную модель проекта через repository maps, dependency graph, поиск по символам и файлы памяти вроде AGENTS.md или CLAUDE.md.

После этого он использует полученную структуру для дальнейшей навигации.

Получается, что архитектурное понимание проявляется не только в итоговом коде, но и в процессе исследования системы.

Если агент умеет правильно определять связанные модули, понимать направление зависимостей и находить ключевые точки системы, это может говорить о более глубоком понимании проекта, чем просто успешное прохождение тестов.

Именно эту гипотезу пытаются проверить новые исследования.

Repository Exploration против классического Retrieval

Интересно, что новые работы не ограничиваются улучшением поиска по коду.

Традиционный retrieval предполагает поиск релевантных фрагментов на основе запроса. Агент получает найденные результаты и использует их при решении задачи.

В исследованиях Repository Exploration появляется более активная модель поведения. Агент не просто получает найденный контекст, а самостоятельно исследует репозиторий, задавая последовательность шагов.

Он может:

• искать связанные сущности;

• переходить между символами;

• анализировать зависимости;

• уточнять область поиска;

• проверять дополнительные гипотезы.

Такой подход ближе к исследовательской работе разработчика, который постепенно строит представление о системе.

При этом сами источники не утверждают, что исследовательский подход всегда лучше. В исследовании отмечается компромисс между качеством понимания и стоимостью работы. Более глубокое исследование требует дополнительного времени, вычислений и токенов.

Какие ограничения остаются

Несмотря на интерес к новой метрике, исследование не говорит о существовании общепринятого стандарта оценки.

Напротив, речь идёт о формирующемся направлении.

Сохраняется несколько открытых вопросов.

Во-первых, неочевидно, как именно измерять качество исследования репозитория. Агент может прийти к правильному решению разными маршрутами.

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

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

Поэтому речь пока идёт не о замене существующих бенчмарков, а о появлении дополнительного измерения качества агентных систем.

Что меняется в понимании способности агента

Если смотреть на тенденции, описанные в исследовании, постепенно меняется сама трактовка понятия «понимание проекта».

Раньше главным доказательством понимания считался рабочий результат.

Теперь появляется более осторожный взгляд. Успешное выполнение задачи может быть следствием хорошей навигации по репозиторию, а может оказаться результатом удачного поиска локального паттерна. Эти ситуации внешне выглядят одинаково, но отражают разные уровни понимания системы.

Именно поэтому способность исследовать кодовую базу начинает рассматриваться как самостоятельный объект анализа.

Вывод

Исследования 2025–2026 годов не предлагают отказаться от оценки качества кода или успешности выполнения задач. Однако они указывают на ограниченность такого подхода как единственного критерия.

На фоне роста размеров репозиториев и усложнения агентных систем всё больше внимания уделяется тому, как агент изучает проект до внесения изменений. Способность находить релевантные участки кода, строить карту зависимостей и ориентироваться в структуре системы постепенно становится отдельным направлением оценки.

Пока нельзя говорить о сформировавшемся стандарте или едином подходе. Но исследование показывает, что для части сообщества вопрос «как агент исследует репозиторий» становится не менее важным, чем вопрос «какой код он написал в итоге».