Structured GitHub fix histories lift SWE-Agent by 4.65% on SWE-bench

Once LLMs got good at writing code, a layer of autonomous SWE agents grew up around them: systems that can open a repository, run the tests, localize a bug and prepare a patch. But these agents have an unfortunate habit of working as if they had never seen a bug like this before. Human developers almost never fix hard problems from scratch: they go to GitHub, look for similar issues and PRs, read the discussion, check which hypotheses were tested, which edits worked and how they were validated. That is the "open world" of experience — vast, useful, and extremely awkward for a machine to use.

The authors of MemGovern: Enhancing Code Agents through Learning from Governed Human Experiences propose a simple answer: turn the scattered traces of human development into a "memory" the agent can work with as sensibly as a real engineer would.

Why GitHub experience is so hard to feed to an agent

The problem is not a shortage of data — GitHub is full of fixed bugs. The difficulty is that this experience is unstructured. A single thread mixes library versions, log fragments, release-date chatter, incidental edits made along the way, emotional replies and clarifications that matter to people but get in the way of extracting the technical substance. On top of that, different repositories describe the same thing in different words, with different module names and different code style. Naive retrieval therefore tends to hand the agent either noise or details so local that they do not transfer to the project at hand.

MemGovern starts exactly there: instead of heroically trying to understand all of GitHub, learn to turn it into compact, comparable units of experience.

Experience cards: how human stories get governed

At the core of MemGovern is a process called experience governance. It selects suitable repositories and specific fix cases, then converts them into standardized experience cards. The important idea inside those cards: separate what you search by from what you apply.

The index layer records a normalized description of the problem and the diagnostic signals: the exception type, the characteristic error fragment, general component tags — the kind of features that can be matched across projects. The solution layer stores the transferable logic: the root cause, the fix strategy and a short summary of the patch. That makes it easier for the agent to carry over the meaning rather than copy a chunk of code: what exactly was broken, and what fixed it.

To keep the cards from becoming one more source of hallucination, the authors add checklist-based quality control and a refinement loop: if a card describes the cause or the strategy vaguely, it goes back for revision. The result is a set of 135,000 cards.

Not just RAG: the agent learns to search like an engineer

The second key element is agentic experience search. Ordinary RAG works like this: build a query, pull the top-k chunks, drop them into the context. Debugging does not work that way. When a developer looks for a similar bug, it takes several passes: refine the symptoms, discard irrelevant branches, open a couple of promising discussions and only then extract a workable strategy from them.

MemGovern reproduces that style with two operations. The agent first searches the index layer (symptoms and signals), then selectively opens cards to surface the solution layer. If the candidates are weak, it reformulates the query and tries again. This mode helps it pull out not a surface match on words but a precedent that actually fits logically.

What this buys in practice

The authors plug MemGovern into SWE-Agent as a plug-in and test it on SWE-bench Verified, one of the most visible benchmarks for automatic bug fixing in real repositories. The result: +4.65% on the share of solved tasks on average. For benchmarks like this that is a noticeable gain, because every few percent usually costs either a stronger LLM or heavy pipeline tuning.

The effect shows up clearly in the walkthrough of agent behavior: with no experience to draw on, the agent may pick a defensive workaround that breaks the API contract just to make the tests pass. With MemGovern it leans more often on human logic it has already seen and makes a semantically correct edit.

An interesting detail: the quality of the memory matters more than its raw volume. The authors show separately that simply feeding the agent unprocessed discussions is worse than giving it less material in structured form. Raw threads pull it off course easily — unrelated changes in a PR, for example, push the agent into an incomplete patch. Governed experience does the opposite: it foregrounds the key logic.

Finally, the authors study how memory size and retrieval depth (top-k) affect the result: an important engineering piece, because an LLM's context window is finite and too many cards can blur the agent's focus.

What to take away from MemGovern

The work highlights a shift in thinking: progress in coding agents depends not only on smarter LLMs but on how we package external experience. MemGovern shows that GitHub can be turned into a memory layer — and that search should be a process, not a single query.

No, this is not a magic button that fixes every bug. But the idea works: give agents access to collective engineering memory in a form that helps them think instead of clogging their context.

💾 Code