Giving coding agents whole-repository maps

Giving coding agents whole-repository maps

Static analysis for the agentic era

Michael Zoubkoff

6 min read

We tested three specialized code-mapping methods with a coding agent. Performance improved but at the cost of more tokens and time. Specialized agent harnesses can help, though not for free.

Why this? Why now?

LLMs have excelled at software engineering tasks.

On DeepSWE, a representational benchmark of software tasks, overall completion rates are trending toward 80%. With that said, the non-deterministic nature of LLMs means success rates can vary wildly across runs.

Modern coding agents typically manage codebase context with a combination of heuristics and general-purpose shell commands like grep and find. To this end, we investigate whether specialized artifacts affect agents' abilities to navigate unfamiliar codebases, make their first edit and, if so, is the benefit enough to offset the added context overhead?

Existing work includes RepoBench, which evaluates repository-level retrieval and code completion using cross-file context. We test something different:

Do deterministic repository maps improve coding agent task performance?

Which representation, if any, is most useful? To this end, we measure

  • task success,
  • token usage and cost,
  • runtime,
  • time to first edit,
  • repository-navigation behavior,
  • artifact usage, and
  • context-management overhead.

Experimental Setup

Using Tree-sitter, we built Cartograph, a tool to parse code in a variety of programming languages into a unified, canonical structure covering symbols, modules, and relationships such as

  • calls,
  • imports,
  • instantiation,
  • inheritance,
  • implementation, and
  • references.

Currently, it supports ingesting TypeScript, JavaScript, Python, Go, and Rust.

Cartograph represents codebases via one of three methods we've named Architecture, Skeleton, or Callgraph.

The tool stores these representations as Markdown files. We include ambiguous relationships and parsing failures as additional information for the agent.

Below you'll see how each output might appear in practice:

1Architecture Index
2Repository / packages / services
3Application
4Shared library
5Test suite
6Directories
7Core logic
8External adapters
9Structural entrypoints
10Command-line entrypoint
11Server entrypoint
12Module dependencies
13Application → core logic
14Core logic → adapters
Cartograph's three methods of mapping a codebase: Architecture, Skeleton, or Callgraph. Open the generated architecture.md, skeleton.md, and callgraph.md examples.

Actual artifacts differ in the information they surface and how that information is exposed.

Architecture and Skeleton provide more human-centric representations of the codebase, focusing on where things are and what exists. Callgraph focuses on how symbols interact, such as which functions call which and the execution path between them.

Information surfacedArchitectureSkeletonCall graph
Component / repository structureIncludedNot includedNot included
Entrypoints / root modulesIncludedNot includedNot included
Module / package dependenciesIncludedNot includedNot included
Function / class / type declarationsNot includedIncludedNot included
Signatures / parameters / return typesNot includedIncludedNot included
Symbol kind / visibilityNot includedIncludedNot included
Inheritance / implementationNot includedIncludedNot included
Direct calleesNot includedNot includedIncluded
Reverse callersNot includedNot includedIncluded
Bounded execution-flow pathsNot includedNot includedIncluded
External / unresolved call edgesNot includedNot includedIncluded
Implementation bodiesNot includedNot includedNot included
Information surfaced by each artifact type.

We intentionally minimize overlap between these artifact types, which makes differences in results easier to attribute to the information each representation provides.

Experiment

To compare how agents complete real, long-horizon software engineering work, we ran a subset of DeepSWE v1.1 tasks three times each. We tracked task correctness alongside tokens spent, runtime, source access, and navigation behavior (ie. which files the agent accessed).

We fixed the model (GPT-5.6-Luna), provider (OpenAI), harness (Pi), thinking level (Max), repository version, and task prompt across conditions. Every condition also retained access to the complete repository source; the only experimental variable was which structural artifact, if any, the agent could access.

We chose 5.6 Luna because it sits close to the efficiency frontier on DeepSWE tasks. Pi is deliberately a simple coding harness: it gives the model the filesystem and editing capabilities needed to complete the task with minimal overhead. This combo of model and harness is also close to coding agents used in practice.

DeepSWE scorev1.1 · 113 tasks
0%20%40%60%80%$12$9$6$3$0most efficient ↗Claude Opus 5 · low · 58.1% · $1.66Claude Opus 5 · medium · 68.9% · $3.29Claude Opus 5 · high · 72.8% · $6.08Claude Opus 5 · xhigh · 73.2% · $9.07Claude Opus 5 · max · 73.6% · $11.84Claude Opus 5max · 73.6% · $11.84GLM 5.3 · max · 69.0% · $3.99GLM 5.3max · 69.0% · $3.99Gemini 3.7 Flash · low · 53.8% · $1.83Gemini 3.7 Flash · medium · 65.5% · $2.03Gemini 3.7 Flash · high · 65.3% · $2.18Gemini 3.7 Flashmedium · 65.5% · $2.03DeepSeek V4 Pro · max · 62.8% · $0.24DeepSeek V4 Promax · 62.8% · $0.24GPT-5.6 Luna · low · 1.5% · $0.07GPT-5.6 Luna · medium · 11.3% · $0.22GPT-5.6 Luna · high · 44.2% · $0.78GPT-5.6 Luna · xhigh · 56.9% · $1.54GPT-5.6 Luna · max · 67.2% · $3.03GPT-5.6 Lunamax · 67.2% · $3.03Average cost per task
GPT-5.6 LunaLines connect reasoning effort levels
DeepSWE score against average cost per task

Agents worked inside disposable sandboxes, with held-out verification performed separately after each run.

Artifacts were exposed as ordinary files, with a pointer added to the system prompt:

The following generated repository-structure aids are available:
 
- Architecture: `.cartograph/architecture.md` is available.
 
Use the available repository information as you judge useful for completing the task.

Agents could inspect the artifact using the same filesystem and CLI tools available for normal source-code navigation, making artifact discovery and usage part of the experiment itself.

Before the full evaluation, we ran a small set of canary tests using a cheaper model to validate the setup and to estimate cost.

Each run had a 90-minute timeout. When the timeout was reached, execution stopped but the verifier still graded the workspace in its current state, meaning a timed-out trial could pass if the agent had already produced a correct solution.

The results should be interpreted as specific to our model-harness pair. Repeating the experiment with other models and harnesses would be needed to establish generality.

Stay in touch

Join our mailing list to receive future posts straight in your inbox.

Results

We summarize the main results across 359 trials below.

  • Baseline
    37.8%34/90
  • Architecture
    36.7%−1.1 pp
  • Skeleton
    40.4%+2.7 pp
  • Call graph
    37.8%±0.0 pp
Experiment pass rate by condition.

Resource usage for each of the conditions can be found below.

30%35%40%45%23M24M25M26M27M28M29MB23.5MM27.7MS26.9MG28.8MMean total tokensPass rate
B BaselineM ArchitectureS SkeletonG Call graphPareto-efficient
Tokens and runtime against pass rate.

Across the first 30 tasks, the baseline is a mean pass rate of 37.8%, compared with 36.7% for Architecture, 40.0% for Skeleton, and 37.8% for Callgraph. Skeleton is nominally the best condition.

Of the 359 graded trials, 216 completed, 134 hit the 90-minute cap, and 9 failed. We exclude runs that failed due to infrastructure issues.

The clearest positive result is time-to-first-read of a file touched by the reference patch, which fell from a median of 10 seconds in the baseline to 5 seconds with Architecture, 5 seconds with Skeleton, and 6 seconds with Callgraph. The difference is statistically significant for all three artifact conditions.

Beyond final task success, we looked at whether agents actually used the artifacts and how their navigation changed. Discovery was not a problem: Architecture and Skeleton were opened in 100% of trials, and Callgraph in 98.9%, usually within 4-5 seconds. However, agents generally read the artifact once and never returned to it.

The artifact conditions also used more tokens without meaningfully changing runtime. Compared with the baseline at 23.6M tokens per trial, Architecture used 27.7M, Skeleton 26.9M, and Callgraph 28.8M. Median within-pair runtime remained effectively 1.0× the baseline across all three conditions.

Finally, we measured the overhead introduced by Cartograph itself, including artifact generation time and size, finding it impacted total runtime only negligibly.

A summary of these results can be seen below.

359 trials
ConditionTotalUncached inCached inOutputReasoning
Baseline23.5M678k22.5M337k303k
Architecture27.7M710k26.7M344k307k
Skeleton26.9M838k25.7M332k295k
Call graph28.8M802k27.6M346k312k
Mean metrics across conditions.

A detailed breakdown of per-task results can be found below.

30 tasks · 359 trials
TaskPooled
abs-module-cache-flags1.00
arcane-drift-detection-baselines1.00
drizzle-orm-window-function-builders1.00
actionlint-action-pinning-lint0.92
abs-stepped-slices0.83
anko-typed-variable-bindings0.83
  • solved
  • not solved
  • cut off at 90 min
  • agent exited non-zero
  • not run
Per-trial results by task and condition.

Discussion

Interestingly, the pass rate ended up being fairly low across every condition. Our experiment differs from the original DeepSWE setup in harness, reasoning effort, timeout policy, and task subset, so it is hard to pinpoint exactly why. GPT-5.6 Luna on Max + Pi also used substantially more tokens than our small-model canary runs, despite a 96% cache hit rate for the experiment.

The more interesting result is that the artifacts seem to do their job: they make initial navigation significantly faster. The problem is that localization (initial navigation) only represents around 0.2% of a full trial. Cutting that time in half is useful, but it has little effect on an hour-long task dominated by understanding the specification, implementing the change, and verifying the work.

The way agents use the artifacts might also explain why the benefit does not carry further. The agents almost always fell back to navigation heuristics after an initial skim of the map. The maps thus seem useful as an initial orientation aid but may not fit with the model's trained instincts.

These results should be interpreted narrowly. So far, only 30 of 112 tasks have been tested, and only one model-harness combination has been run. The experiment is therefore better viewed as a comparison between conditions under one fixed setup, rather than a general claim about structural artifacts across coding agents.

However, the results have actually increased my confidence that opinionated harnesses can help agents. They clearly improve localization, and the Skeleton artifact improves upon the baseline by 2.7 percentage points.

Future

For future work, benchmarking SOTA models would show whether stronger models benefit more from having a deterministically generated artifact they can use as an anchor. Testing different harnesses would also reveal how much artifact usage depends on the agent harness.

Additionally, since agents rely heavily on heuristics when exploring codebases, testing the maps over much longer runtimes, potentially without a time limit, could reveal whether their value becomes more significant on longer-horizon tasks.


Last updated:

If this sparked an idea for your roadmap, let's talk.

Rubric is an applied AI lab helping teams build and ship intelligent products.