A single jump tool beats a full search toolkit at issue localization

If you have ever opened a large repository hunting for a bug, you know the feeling: hundreds of files, a tangle of non-obvious connections, and an issue description that explains almost nothing. An LLM faces the same problem, only harder — it physically cannot hold the whole project in context. So today's software engineering agents are forced to work iteratively: read a fragment of the docs and the code, draw a conclusion, call a tool, read again, and so on.

The authors of One Tool Is Enough argue that to find the right files and functions, an agent does not need an assortment of search tools. One is enough — as long as it is the right one.

Following the execution path

Most RAG setups are built around retrieving the relevant classes, methods and imports. That sounds reasonable, but there is a hidden problem: such a toolset maps poorly onto how code actually runs. At runtime there is no "class search" — there are calls, references and jumps to definitions. And every extra tool means another call format, more parameter errors, and a better chance the agent goes off the rails somewhere.

RepoNavigator bets on a single action: jump, a move to where a class, method or variable is defined. The tool is implemented through a language server (the paper uses Pyright) that parses the code statically and accounts for scopes, imports and even type inference in order to return the correct definition.

An easier task than fixing the bug, and more useful than it looks

The authors deliberately do not teach the model to fix bugs outright. That is expensive and hard to verify: a single issue can have many correct patches, and reliable evaluation means running tests in Docker for every repository. Instead they take the stage that is almost always the bottleneck — issue localization, working out which files and functions the problem actually touches.

The reasoning is pragmatic: if localization is accurate, the work that follows — by another agent or by a human — gets an order of magnitude easier, because the search space collapses.

How the agent learns to walk through code

RepoNavigator is not trained by distilling from closed models but directly: the authors take a pretrained model (Qwen2.5 at several sizes in the experiments) and fine-tune it with reinforcement learning under the RLVR scheme, using a variant of GRPO. The reward is built so that the agent gains not only from landing on the right files and functions (measured by Dice/IoU) but also from calling the tool correctly. That detail matters: an agent that knows the answer but keeps breaking the call format is useless in a real pipeline.

The ablations show that the hybrid reward (localization quality plus tool-calling success) trains the model noticeably better than a reward for the final outcome alone.

What the benchmarks show

On SWE-bench-Verified, RepoNavigator after RL posts a sharp gain: on the headline metrics (Sample-F1 and IoU) the 7B version beats 14B baselines, the 14B beats 32B competitors, and in several comparisons the 32B comes out ahead of closed models.

Generalization is checked separately on SWE-bench-Pro (a dataset released after Qwen2.5, which lowers the risk of contamination). The picture holds: the approach is robust, and RL helps again.

One interesting observation: the more jump calls the agent is allowed, the more steadily quality rises — both before RL and after it.

Why one tool sometimes beats a toolbox

The authors are not merely fond of minimalism; they test it. They bolt the tools from earlier work — class search, function search, structure browsing — onto jump and watch what happens. The result is close to provocative: jump alone works best, and the extra tools either do nothing or actively hurt.

The explanation is mundane. First, call chains break probabilistically: if each call succeeds with probability p, a few steps in a row quickly erode overall reliability. Second, jump naturally constrains the agent's reachable scope — it moves along real dependencies and execution paths instead of scanning the whole repository. That raises the odds of crossing the exact piece of code it was looking for.

What this changes

The main takeaway is this: in repository search it pays less to elaborate the toolset than to pick the tool that matches the nature of code, and then teach the model to use it through RL. And "fewer tools, more control" may turn out to be especially valuable when the goal is a reliable agent rather than a demo that survives a couple of runs.