Coding agents fix more bugs when they ask the repo two questions first

Understand the code before you fix it

Coding agents have an old and very human problem: they start fixing too early. They see a bug report, latch onto familiar words, race through the repository and make a quick edit — in the wrong place, about the wrong thing. Tests fail, steps pile up, tokens burn, and the agent goes in circles.

The authors of Know Before Fix propose a simple but powerful idea: before writing a patch, the agent should first ask the right questions about the codebase and have them answered against the repository's actual files. Not "how would I fix this," but "what am I missing to understand what is even going on."

Out of that grew ACQUIRE, a two-stage pipeline for solving SWE-bench Verified tasks. The idea turned out to be more than elegant. In practice it raises the quality of the fixes, and it does so without a wild jump in cost or time.

The core idea

Large models already reason about code reasonably well. But on real repositories the problem is usually not the logic itself — it is a shortage of facts. A task description rarely contains everything that matters: where the relevant logic actually lives, what hidden dependencies run between modules, what constraints an internal API imposes, what assumptions are baked into the code.

Many existing methods try to treat this with a preliminary pass over the repository. But those passes are still shaped around the fix: find the suspicious files, assemble a summary, highlight the relevant spots. Useful, but it does not answer the key question: what exactly does the agent not understand?

ACQUIRE turns the process toward something closer to how a strong developer works. Understanding first. Editing second.

The ACQUIRE pipeline: the agent first formulates questions and gets them answered against the repository, then a separate agent builds the patch.

The system splits the work into two stages:

The separation matters. It stops the agent from mixing guesses about the cause of the bug with premature edits to the code.

How ACQUIRE works

Inside, ACQUIRE has three roles.

The questions are not improvised. The authors identified four kinds of knowledge gap that most often get in the way of a fix:

It is, in effect, a template for curiosity. Instead of hunting for a "suspicious file," the agent asks things like: how is this mechanism built here? where is the part I need implemented? which contract must not be broken?

One more piece of the design matters. Every question gets its own instance of the answering agent, and they run in parallel. That cuts latency and keeps one search trail from contaminating another. One agent looks for one thing, another for something else.

By default the system asks two questions per task. As the authors later found, that is close to the optimal point.

Why this should work at all

The authors started with an almost magical experiment. They took 116 tasks the baseline agent had failed and handed it one oracle question–answer pair: the question was written with the reference patch in view, and the answer was built from the files the correct fix touched.

The result: 26 of the 116 previously failed tasks were recovered.

This is not the finished system so much as a proof of the idea. But it makes the point well: give the agent the right knowledge before it starts fixing, and it often turns out that it can think just fine — what it lacked was grounding in the repository itself.

The authors then removed the magic and automated the process: the agent generates the questions itself, and the answers come from real search through the code.

What happened on SWE-bench Verified

The main experiment ran on SWE-bench Verified — 500 real GitHub issues where the fix is checked by tests.

Compared with the baseline Mini-SWE-Agent, ACQUIRE delivers:

That is the best result so far among the pre-analysis methods it is compared against.

Accuracy and average cost at different numbers of question–answer pairs: the best balance lands at two questions.

What is interesting here is not only the accuracy but the price of the improvement. Some competing methods help too, but expensively: more traversal, more steps, more time. ACQUIRE's overhead is moderate. With DeepSeek-V3.2, for instance, average cost rises from $0.055 to $0.073 per task, and time from 815 to 1,042 seconds. Noticeable, but not dramatic.

Set against methods that cost 2–14× more, that looks like a very reasonable trade.

Why? Because ACQUIRE does not try to read the whole repository. It gathers narrow, meaningful knowledge that actually helps it decide.

Not just more accurate, but shorter

One of the strongest parts of the paper is its account of how exactly the agent's behavior changes.

With the question–answer block added, the agent makes fewer useless loops. Across the full task set the number of rounds drops by 7.1% on average. On the 44 cases that flipped from failure to success, the reduction is 17.1%.

The composition of trajectory steps on tasks where ACQUIRE turned failure into success: less time spent searching and editing blind.

The authors split each trajectory into four stages: reproduction, localization, fixing, verification. The shift they found is telling:

That looks like a good engineer at work: less blind wandering, more time spent checking deliberately.

More important still, the gathered knowledge actually gets used. About 40% of the steps in successful trajectories tie back to the questions and answers — most visibly in localization and fixing, where knowing the repository is critical.

How far the answers can be trusted

The approach carries an obvious risk: what if the agent invents its own wrong "facts," and another agent then leans on them?

The authors checked this by hand. They went through 232 question–answer pairs. The result is strong: 99.1% of the answers were judged to be supported by the repository. Of those:

That is an important result. It shows that breaking the task into small, concrete questions really does reduce the model's tendency to make things up. Answering a narrow question about code is easier than understanding and fixing everything at once.

There is a catch, though. Even a factually correct answer can pull the focus in the wrong direction. The authors found 22 cases where the baseline agent solved a task and ACQUIRE did not. Inspected by hand, only 5 of those regressions came from genuinely misleading knowledge. The rest happened because the solving agent misused an otherwise useful hint: it generalized too broadly, fixed only part of the problem, or added changes that were not needed.

The conclusion is simple: the bottleneck is no longer the quality of the gathered knowledge so much as how well the agent can argue with it and check it again.

Why two questions beat one or three

The authors tested separately how many question–answer pairs are actually needed.

The answer is very true to life:

More context, in other words, is not always better. Past two questions the familiar long-context problem sets in: information repeats, attention spreads thin, and it gets harder for the agent to pick out what matters.

This is one of the paper's most practical findings. There is no need to bury the model in every reference you can produce. Two good hints beat five mediocre ones.

The most telling example

One case in the paper shows clearly where the strength of the approach lies. In a Sphinx task, the bug looked like a rendering problem with documentation parameters. The baseline agent latched onto words from the report and ran around the files responsible for display. It never opened the right file at all.

The Sphinx case: ACQUIRE finds the root cause through a question about the parsing mechanism rather than through a keyword match.

ACQUIRE went a different way. The questioner asked not "where does the rendering break" but about the mechanism that parses the parameter type. That moved the search toward causes rather than symptoms. The answering agent ended up finding `docfields.py`, where `split` mishandled spaces inside the type's brackets.

From there the solving agent opened the right file immediately, made a targeted edit and closed the task in 52 steps instead of 117.

Which is telling: the problem was never that the agent could not write the code it needed. It was simply looking in the wrong place from the start.

What this means for coding agents

The work matters as more than another tick on SWE-bench. It hits one of the weakest spots in today's agents: they are bad at telling a knowledge gap apart from a reasoning error.

When an agent does not understand a repository, it usually does not say "I am missing facts." It starts improvising. ACQUIRE imposes a useful discipline: name the knowledge gaps first, close them, and only then edit the code.

For the field, that is a meaningful shift:

And that is especially valuable on real codebases, where bugs often sit across more than one file and never on the surface.

Takeaways

ACQUIRE shows something simple: generating a patch is not enough to fix code well. You also have to work out what you do not know about the repository, and go get exactly that knowledge, fast.

The question-and-answer approach produced a consistent gain on two different models, cut the number of wasted steps, and came out markedly cheaper than heavy schemes built on deep upfront traversal. Most important, it changes the agent's working style: less thrashing, more understanding.

The main lesson here sounds almost human. A good coding agent should not only fix. It should first ask the right questions.