Сколько статической структуры требуется кодовым агентам? Исследование детерминированного якорения

Аннотация

Агенты кода на основе LLM осуществляют навигацию по репозиториям с помощью поиска по ключевым словам, но упускают структурные взаимосвязи — такие как графы вызовов, иерархии наследования и зависимости конфигурации, — которые определяют, как реально работает программное обеспечение. Это делает навигацию агентов стохастической и трудно воспроизводимой от запуска к запуску. Мы исследуем, может ли лёгкий статический анализ предоставить детерминированные якоря для таких агентов: стабильные структурные факты, внедрённые в виде комментариев на обычном языке, которые ограничивают вероятностное исследование и делают навигацию более предсказуемой. Отталкиваясь от сильного базового решения, Codex от OpenAI, мы систематически внедряем структурные аннотации различной степени детализации и измеряем их влияние на локализацию, поведение траектории и стабильность от запуска к запуску. Наше исследование выявляет то, что мы называем эффектом детерминированного якорения: статическая структура помогает не столько за счёт того, что делает агентов «умнее», сколько за счёт того, что делает их навигацию дисциплинированной и воспроизводимой. Три наблюдения подтверждают этот вывод: (1) Якорение работает: лёгкая топология вызовов/наследования улучшает локализацию на уровне функций (+2,2 процентных пункта Func@5) и сокращает траектории (на 1,6 раунда взаимодействия); (2) Якорение чувствительно к масштабу: оптимальная степень детализации и направленность зависят от характеристик репозитория, причём более плотная семантика демонстрирует убывающую отдачу, а проекты с большим количеством концентраторов выигрывают от использования только обратных ссылок, которые показывают «кто вызывает меня» без прямых рёбер; (3) Якорение стабилизирует: теги повышают частоту перехода по ссылкам с 0,15–0,18 до 0,21–0,24, примерно вдвое снижают дисперсию между запусками и улучшают одноразовую надёжность (Pass@1 +3,4 процентных пункта) в репозиториях среднего масштаба за счёт примерно на 10% большего количества входных токенов. Эти наблюдения подсказывают практические рекомендации: по умолчанию использовать лёгкую топологию для проектов среднего масштаба, обрезать прямые рёбра в крупных репозиториях и оставлять плотные теги только для случаев с неявными зависимостями.

English

LLM-based code agents navigate repositories through keyword search but miss the structural relationships, such as call graphs, inheritance hierarchies, and configuration dependencies, that define how software actually works. This makes agent navigation stochastic and difficult to reproduce across runs. We investigate whether lightweight static analysis can provide deterministic anchors for these agents: stable structural facts injected as plain-text comments that constrain probabilistic exploration and make navigation more predictable. Starting from a strong baseline, Codex from OpenAI, we systematically inject varying granularities of structural annotations and measure their effects on localization, trajectory behavior, and run-to-run stability. Our study identifies what we call the deterministic anchoring effect: static structure helps less by making agents "smarter" and more by making their navigation disciplined and reproducible. Three observations support this finding: (1) Anchoring works: lightweight call/inheritance topology improves function-level localization (+2.2pp Func@5) and shortens trajectories (-1.6 interaction rounds); (2) Anchoring is scale-sensitive: the optimal granularity and directionality depend on repository characteristics, where denser semantics show diminishing returns and hub-heavy projects benefit from inverse-only links that expose "who-calls-me" without forward edges; (3) Anchoring stabilizes: tags raise link-following rate from 0.15-0.18 to 0.21-0.24, roughly halve run-to-run variance, and improve single-run reliability (Pass@1 +3.4 pp) on medium-scale repositories, at the cost of roughly 10% more input tokens. These observations suggest practical guidelines: default to lightweight topology on medium projects, prune forward edges in large repositories, and reserve dense tags for implicit-dependency cases.