Training agents on five atomic skills lifts coding scores by 18.7%

The authors propose that we stop training AI agents on composite tasks alone and teach them atomic skills instead — small, checkable, reusable building blocks of software development.

When coding agents are taught to reason step by step instead of "fixing bugs"

Coding agents have a persistent problem: models fit benchmarks well enough, but shift the framing of a task slightly and nothing works. An agent closes SWE-bench-style tickets and then gets lost in a refactor. It writes good patches and reproduces bugs badly. It passes tests confidently and cannot really review someone else's PR.

The authors of Scaling Coding Agents via Atomic Skills offer a surprisingly sane idea: stop training agents only on "big" composite tasks and teach them atomic skills instead — small, checkable, reusable building blocks of software development. Not "fix this bug", but "find the right files", "make a targeted edit", "generate unit tests that actually catch something", "reproduce the issue", "review this code".

On paper this sounds close to obvious. In practice it is a fairly radical shift in how we scale coding agents at all. And judging by the results, a useful one.

What's wrong with the current approach

Most of today's LLM coding agents are trained on composite tasks: bug fixing, terminal-based development, ML engineering, security. That is convenient, because success has a clear final shape — the tests pass or they don't, the task is solved or it isn't.

But this kind of training has an unpleasant side effect: the agent starts fitting one specific type of task rather than acquiring transferable engineering ability. Optimize a model on bug fixing long enough and there is no guarantee it gets better at refactoring or code review. It may simply learn to recognize the patterns of that one benchmark.

The authors call this the "black box" effect: the model is rewarded only for the final result, never for the intermediate steps. What it learns is heuristics rather than a more general skill of engineering reasoning.

If AI agents are meant to work in real repositories and not only on polished benchmarks, they need generalization. Real development tasks are endlessly varied, and building a fresh reinforcement learning setup with a sensible reward function for each one is expensive and often simply impossible.

Five atomic skills as the basis of engineering work

Instead of training on monolithic tasks, the authors isolate five fundamental skills:

Code localization — given a problem description, find which files need to change at all.

Code editing — make the required change to the code.

Unit test generation — write tests that actually catch bugs.

Bug reproduction — reproduce the bug with a minimal script or sequence of commands.

Code review — judge whether a PR really solves the stated problem.

The claim is that this is not a grab bag of "a bit of everything" but a set of basis vectors for engineering work. More complex scenarios can be assembled from them. Bug fixing, for instance, is almost always a combination of localization, reproduction, editing and verification. Refactoring draws on editing and code review. Security work can require reproduction and testing.

The authors set strict requirements for every skill: it must be minimal, precisely specifiable and independently checkable. That is the crux. If a skill cannot be scored automatically and reliably, RL turns into chaos fast.

How they train it

First the model gets a light supervised fine-tune on atomic-skill data only — no composite tasks. That is the starting point. Then comes joint reinforcement learning: one agent, one shared policy, one mixed task buffer with episodes from all five skills shuffled together.

This is not five separate models, and not five skill-specific heads. That is the whole point: the authors want shared representations to emerge inside the model for understanding code, navigating a repository, running tools, interpreting results and making decisions.

Technically the agent works in a sandbox, can call bash and can edit files through a simple tool along the lines of str_replace. The narrow action set is a feature, not a bug: less noise in the action space, easier to stabilize RL.

Optimization uses GRPO — Group-based Relative Policy Optimization. Instead of relying on absolute reward values, the model compares several samples against each other within a group. That helps, because different skills have different reward scales and different noise levels. Relative comparison makes training less brittle.

How the rewards are built — and why that may be the strongest part of the work

The most interesting thing in the paper is how carefully the authors thought through their execution-grounded rewards.

For code localization, reward is given if the model exactly guessed the set of files the developers actually changed. The criterion is strict: full match or nothing. Debatable, but understandable — a reward like that does not get diluted by partial hits.

For code editing it is even more direct: a patch counts as correct if the unit and regression tests pass.

For unit test generation the scheme is a good one: the generated tests must pass against the correct implementation and fail against deliberately broken versions of the function. The buggy variants are created separately and filtered so that they are genuinely meaningful. This is far better than simply measuring coverage.

For issue reproduction the agent has to produce a script that reproduces the error before the patch and stops reproducing it after. What gets checked is the causal link.

For code review the agent is handed a PR and has to return a binary verdict — does it solve the problem or not. Reward depends on matching the correctness labels.

This construction matters because it shows the authors did not merely say "let's break tasks into pieces"; they built the scalable RL infrastructure that such a breakdown requires.

What it looks like in practice

The paper's headline result reads well: joint RL on atomic skills improves both the skills themselves and transfer to unseen composite tasks. The average gain across 5 atomic skills and 5 composite tasks is 18.7%.

The tables tell a consistent story. After RL the model improves on all five atomic skills. For example:

— localization: 0.665 → 0.712

— editing: 0.458 → 0.611

— issue reproduction: 0.542 → 0.605

— unit test generation: 0.359 → 0.472

— code review: 0.563 → 0.622

What matters more is that the gains carry over to OOD benchmarks that were never used as RL targets: SWE-bench Verified, multilingual bug fixing, Terminal-Bench, refactoring, security.

That is the paper's central argument. If the improvements stayed inside the training distribution, this would be one more variation on multi-task RL. Instead the authors show that training on the building blocks genuinely helps on new and harder tasks.

Why joint training beats specialization

One section of the paper compares joint RL against narrower variants: RL on code editing tasks only, or on SWE-bench Verified only.

Intuitively you would expect single-task RL to deliver a sharper gain on at least its own target, and joint training to suffer from interference. The authors report the opposite: no obvious trade-offs show up. All five atomic skills rise together, and transfer to composite tasks is better and steadier in the joint setting.

This is one of the paper's most intriguing findings. It hints at positive transfer between skills: a model that reproduces issues better probably becomes better at editing code; a model that writes good tests gets a better grip on the behavioral invariants of code; a model that has practiced review understands better what counts as a correct change in the first place.

Specialization still has its uses, of course. The authors say plainly that RL directly on a specific benchmark can deliver a comparable result. But if the goal is a more general agent rather than one leaderboard, joint atomic training looks stronger.

Training dynamics: a rare case where the curves actually explain something

The paper includes useful training curves. They show that the atomic skills improve roughly monotonically over the course of reinforcement learning. And the composite OOD scores climb along with them.

That matters, because agentic RL usually behaves differently: something spikes and then degrades, or one ability grows at another's expense. Here the authors see relatively stable joint improvement.

They also analyze the number of interaction steps with the environment. For some skills it rises together with quality. That looks like an agent that has stopped guessing and started exploring the repository actively and using its tools more deliberately.

Why this work reaches beyond coding agents

The paper takes aim at one of the central problems of agentic AI as a whole: how to train for transferable abilities rather than for passing specific tests.

With coding agents this is especially visible, because software development decomposes naturally into repeatable operations. But the idea may reach further. Any complex agentic activity — research, analytics, GUI work, enterprise automation — most likely also consists of a set of atomic skills that lend themselves to verifiable RL far better than "the whole big task".

If that logic holds, what we are looking at is not one more paper about software engineering benchmarks but a more general recipe for scaling agentic models: look for the right set of elementary, measurable abilities rather than for the next benchmark.

But there are limits

For all its merits, this work should not be read as the final answer.

First, the set of five skills is still the authors' own pick. It looks reasonable, but it does not cover all of engineering practice: there is no architectural design here, no dependency work, no migrations, no performance tuning, no planning of multi-step tasks.

Second, some of the reward functions are rigid and arguably questionable. Localization demands an exact match on the set of files, even though real development admits alternative routes to a solution. A binary verdict for review also simplifies reality.

Third, all of this runs on a large model and serious infrastructure: tens of thousands of sandboxes, prebuilt Docker images, a Kubernetes cluster. For labs and large companies that is realistic; for most teams it is not, yet.

Even with those caveats, the idea itself holds up.

The takeaway

Scaling Coding Agents via Atomic Skills is one of those papers whose main contribution is not a new architecture but a change of paradigm. The authors propose looking at a coding agent not as a machine for passing the next composite benchmark, but as a system that should be taught the skills all engineering work is assembled from.

And the results support that view: joint RL across five atomic abilities raises quality not only on those abilities but on harder, previously unseen tasks — from bug fixing to security and refactoring.

The main conclusion is simple: if you want a general coding agent, drilling it on bug fixing alone is probably the wrong move. Better to teach it first to find, reproduce, test, edit and judge code well.

For AI development, this is one of the most practical ideas to come along in a while.