Giving coding agents a map of the code saves tokens, but not always success

The question behind the paper

Most AI coding agents still approach a software project the way a new hire with no onboarding might: they open raw files, search for keywords and run commands in a terminal. In other words, they treat code mostly as text. A paper posted on arxiv.org asks whether that is the best way to work, or whether agents should get a more structured view of a repository first.

The authors treat the form of that view as a design choice, like any other setting in an agent. They look at how it changes four things: how the agent searches, whether it completes the task, how many tokens it spends, and how long it takes. Tokens are the small chunks of text an AI model reads and writes, and they are what you typically pay for. Latency is simply the waiting time.

Five maps, one test agent

The team built five workflows, and each gives the agent a repository map it can query while it works. Two of the names are technical, so here is what they mean:

• Abstract syntax trees: a breakdown of code into its grammatical structure, rather than plain text.
• Call graphs: a diagram of which pieces of code call which other pieces.
• Module dependencies: a view of which parts of the project rely on which others.
• Documentation-enriched search: search that also draws on the project's written documentation.
• Hybrid: all of the above combined.

The test agent was Claude Code running Haiku 4.5, compared against a baseline that used only the usual raw tools. It was tried on four kinds of work: locating faults (LinuxFLBench), generating and repairing code in large repositories (SWE-bench Pro), writing tests (SWT-bench), and fixing security problems (SecBench).

Where the maps helped

The clearest win came in fault localization, which means working out where in a large codebase a bug lives. On LinuxFLBench, all five workflows beat the baseline on recall@10, a score for how well the right location shows up among the agent's top ten candidates. They scored 0.757 to 0.829, against 0.717 for the baseline. They also cut token use by 25-39%.

On SWE-bench Pro, the maps mostly saved money rather than raising success. Resolution stayed close to the baseline, at 44.3-50.6% compared with 49.0%, while token use dropped 17-26%. Some workflows landed a bit below the baseline and some above it, so this is not evidence that they solve more problems.

On SecBench, the Callgraph workflow had the best patch-resolution rate in this sample, 34.3% against 28.9%, and used fewer tokens. The authors stress that the result is specific to the sample they tested.

Where they did not

The picture changes when the hard step is writing rather than finding. On SWT-bench, which tests whether an agent can write a test that reproduces a bug, Hybrid and Docs reached the highest rates in this sample, 47.8% and 47.2% against 44.7%. But every workflow used more tokens and took longer than the baseline.

Speed was a problem elsewhere too. On SecBench, every workflow increased latency, even the one that scored best on success and token use. A map can save tokens and still make the agent wait longer, probably because querying it adds extra steps. The paper does not say exactly why, so that is only a guess.

The authors' summary is that these maps change what the agent looks at and how much it spends, but the benefits depend on the task. They do not apply across the board.

What to take from it, and what to be careful about

The practical lesson is about matching the tool to the bottleneck. When an agent mostly struggles to find the right place in a big project, a map appears to help it search more cheaply and sometimes more accurately. When the struggle is producing a good patch or test, the map does less, and may add cost.

There are limits to how far this goes. The study used one agent setup, with a single model, so the results may not carry over to other agents or models. The authors also describe some results as being 'in this sample,' which signals caution about small differences. Gaps such as 49.0% versus 50.6% should not be read as proof that one approach wins.

This is a research paper from a preprint server, which means it has not necessarily gone through formal peer review. It is still a useful reminder that agent performance depends on more than the model itself. What the agent is shown, and how, is part of the system too.