What coding agents transfer across domains is discipline, not code

Coding agents share one weakness: they write code well, but they keep repeating the same mistakes, like an intern who rediscovers every time that running the tests before committing is a good idea. Over the past year researchers have been busy teaching these systems to use memory — to store the moves that worked and the ones that didn't, then lean on them in new tasks. Almost always, though, that memory lives in a narrow sandbox: tasks from one benchmark, one class of problem, one "ecosystem."

When borrowed experience helps an agent

The authors of Memory Transfer Learning: How Memories are Transferred Across Domains in Coding Agents propose stepping out of that local frame. Their idea is simple and ambitious: if different programming tasks share the same infrastructure anyway — languages, the shell, testing, API contracts, repository layout — why shouldn't an agent carry experience across domains? Take a lesson learned on a competitive programming problem, say, and use it to fix a bug in a real repository.

And the paper shows this is not a pretty metaphor but a mechanism that works. On average, transferring memory between different types of coding task is worth +3.7% in quality. By the standards of mature benchmarks that is already a visible gain — especially when it comes not from further training the model but from how it uses experience it already has.

What is new here

The paper's central claim is almost counterintuitive: a coding agent benefits from remembering not only "how to solve a task like this one" but how to act correctly in a computing environment at all. The value of memory, in other words, lies less in ready-made algorithms than in procedural experience.

The authors call their approach Memory Transfer Learning (MTL). Unlike ordinary memory-based agents, which accumulate memories inside a single domain, MTL builds one memory out of heterogeneous tasks — from function-level code generation to repository-level fixes to replicating ML experiments.

This matters for two reasons. First, the industry is heading toward general-purpose agents that have to fix bugs, run pipelines, find their way around someone else's repository and not break on the infrastructure. Second, scaling models keeps getting more expensive, which makes any gain that comes from better use of inference-time experience especially valuable.

How the memory is built

The authors did not settle on a single format for "memories." They tested four at once, from the rawest to the most abstract.

The four formats:

Trajectory — a nearly raw trace of the agent's actions: commands, code, environment output.

Workflow — a distillation of the trajectory: the goal and the sequence of meaningful steps.

Summary — a short account of the task, the actions, and the reasons for success or failure.

Insight — the most generalized form: a principle that may prove useful in future tasks, unattached to specific files or details.

This is a well-chosen experimental design, because it tests not merely whether memory works but which memory transfers better. And the answer is arguably the paper's main one: the more abstract the memory, the more useful it is for cross-domain transfer.

How they tested it

The experimental work is solid. The authors ran the agent across six benchmarks covering different classes of coding task:

So one set holds competitive programming problems, real repository work, and ML and research tasks. For each domain the agent first solved the tasks, and memory was then built offline from the resulting trajectories. At test time on any one benchmark, the agent was fed memory collected from all the others.

Technically the retrieval is plain: tasks and memory items are embedded, and the three most relevant memories are picked by cosine similarity. It does not look like a clever retrieval system — which is exactly why the results are interesting. The effect comes from the principle itself, not from elaborate engineering.

The numbers

The headline result: MTL does improve quality on average across the six benchmarks. The best format is Insight. In the main setup on GPT-5-mini, mean Pass@3 rose from 0.523 to 0.560 — precisely those 3.7%.

The clearest gains came on tasks where algorithms alone are not enough and discipline in handling the environment counts: ReplicationBench and MLGym-Bench picked up substantial bonuses. SWE-Bench Verified gains too, which is telling — that is no longer toy function generation but real bug fixes in repositories.

The authors also checked transfer on other models — DeepSeek V3.2 and Qwen3-Coder. The effect holds, though it is weaker: +2.6% and +1.8% on average. That matters: this looks less like a trick tuned to one model than a more general property of agent memory.

Why memory helps: meta-knowledge, not code

The paper's strongest idea is probably this: what transfers is mostly not the substance of a code pattern but a way of behaving.

The authors went through the cases where the zero-shot agent failed and the MTL agent passed, and classified what the memory contributed. The bulk of the gain turned out to come not from "recalled the right algorithm" but from more mundane, critically important things:

This closely resembles the way engineering experience works in a person. A senior developer often wins not by knowing more algorithms but by having a better feel for process: where to check a contract, where not to attempt a risky refactor, when to reproduce a bug before fixing it.

In that sense the paper takes a real step toward a more realistic picture of coding agents: their bottleneck is not always a "shortage of intelligence," it is often a shortage of procedural discipline.

Why abstraction decides everything

The most elegant result in the paper is the link it demonstrates between a memory's level of abstraction and how well it transfers. Raw trajectories often turn out to be too specific: file names, commands, quirks of the environment and library versions are baked into them. Experience like that easily becomes a trap.

If the agent sees that in another task it helped to rewrite a file through a heredoc and run one particular command, it may apply the same pattern mechanically in a new environment and break everything. An abstract insight like "check the evaluation format first, then make minimal changes and validate the result quickly" transfers far better.

The authors visualize this with t-SNE and also measure it: as abstraction rises, memories become less tied to a particular benchmark and mix more across domains. That is the signature of generalization.

Put briefly: bad memory for transfer is a log of actions; good memory is a rule of behavior.

Where the system still gets it wrong

Cross-domain memory does not always help, of course. Sometimes it produces negative transfer, where borrowed experience anchors the solution in the wrong place.

The authors work through three main failure modes:

One telling case: memory from an R task pushes the agent into needlessly overwriting files in a C++ project. In another, the sound advice to "check quickly that everything runs" is distorted into a justification for a shallow smoke test in place of real work on quality.

A useful reminder: memory is not magic. If retrieval is weak and adaptation to the new task is shallow, the agent will not learn — it will hallucinate by analogy.

The more memory the better, but it is not that simple

Another practical finding: MTL scales. The larger the memory and the more domains it draws on, the better the odds of pulling out useful meta-knowledge.

That is interesting against the common skepticism about memory systems — the claim that it all ends in noise. Here the authors show that in their setup, at least, more diversity helps rather than hurts. For coding agents, a broad base of procedural patterns does appear to be worth something.

Curiously, more sophisticated retrieval strategies did not beat plain embedding-based search. Neither LLM reranking nor rewriting the memory to fit the task produced a better result. The likely explanation is that in agentic settings it is hard to know in advance which piece of experience will matter at the next step. Static reranking loses there to crude but robust semantic similarity.

Why this matters for the industry

The paper has a practical point. Software engineering agents get talked about as the developer's future general-purpose assistant. For now many of them remain "strong interns": capable of some things, easily lost outside the familiar format.

This work suggests a more realistic path. Instead of an endless race for a still bigger model, you can teach an agent to accumulate and reuse experience systematically — not within a narrow specialty but across different tasks. These are, in effect, the building blocks of engineering intuition.

The emphasis on meta-knowledge matters most of all. If future agents really do work in production environments, solving the task is not enough: they also have to avoid wrecking the repository, avoid breaking contracts, validate changes properly and handle their tools sensibly. That is precisely the experience that transfers best.

The takeaway

Memory Transfer Learning overturns nothing in model architecture; it is a careful and very substantive paper about which memory is worth giving agents. The authors show three key things.

First, memory from other domains genuinely helps: coding agents gain when they can draw on more than local experience. Second, what transfers is mostly not code as such but procedural engineering wisdom — how to explore, edit, test and not break the environment. Third, the higher the level of abstraction, the more useful the memory: insights work better than raw traces.

The practical lesson runs like this: if we want genuinely general coding agents, they need to be taught not merely to remember the past but to extract generalized rules of behavior from it. Not "which command did I run back then" but "which principle worked back then."

And that may be a far more important step toward reliable agents than another jump in model size.