Ridwan Alam

Writing

This Coding AI Redesigns Its Own Workshop, Then Trains Inside It

A simple breakdown of the paper “Self-Evolving Coding Agents via Harness-Policy Optimization”: a coding model that rewrites its own harness, trains inside it, and gains more than either fix alone.

Oct 23, 2026
  • AI Engineering
  • AI Agents
  • Reinforcement Learning
Read on Medium
Part I / The Problem
01

Fixed the Bug, Scored Zero

A simple breakdown of the paper “Self-Evolving Coding Agents via Harness-Policy Optimization” by Zhepei Wei, Wenlin Yao, Baolin Peng, Danqing Wang, Qianhui Wu, Hao Cheng, Yu Meng and Jianfeng Gao (Microsoft Research, University of Virginia, Carnegie Mellon University). arXiv preprint, October 2026.

During one test run, an AI coding agent successfully fixed a real bug: it edited the right file and 99 existing tests passed. Then it scored zero. When it was time to hand in its work, it submitted a written summary of the fix instead of the actual code changes, and the surrounding system accepted that mistake.

Same model, same task, but a different surrounding system. This time the system noticed the submission contained zero code changes and sent the agent back. The agent wrote out its patch, checked it, and submitted it successfully. That gap between what a model can do and what actually reaches the grader is what this paper investigates.

Its most striking result: when a model improves itself and its surroundings in turns, the combined gain on the main benchmark reaches 8.5 points, larger than the two gains measured separately (3.5 + 3.4 = 6.9 points).

The whole idea
Self-HPO: the model improves its harness and itself, in turns

After: the Self-HPO loop

H-step
fix the harness

P-step
train the model

Before

Fixed harness
fixed model
61.0%

+8.5 points
69.5%

After: the Self-HPO loop

H-step
fix the harness

P-step
train the model

Before

Fixed harness
fixed model
61.0%

+8.5 points
69.5%

Scores on SWE-Bench Verified. The model designs its own harness. Average across three benchmarks: 57.8% → 64.8%. Qwen3.5-35B-A3B, 3B active parameters.
02

What Is a Harness?

An AI coding agent consists of two primary parts.

  • The policy is the large language model that decides what to do next. In this research it is Qwen3.5-35B-A3B, an open model with 35 billion parameters, of which 3 billion are active at any given time.
  • The harness is everything surrounding the model. It decides what the model sees, runs the model’s commands, feeds back the results, and decides when an attempt ends and what counts as the final answer.
Think of a carpenter working inside a workshop. The carpenter is the policy. The workshop is the harness: everything laid out on the bench, the tools within reach, and the inspector at the door who decides whether what you hand over counts as a finished chair. A skilled carpenter in a badly set-up workshop still ships bad chairs, or, as in the story above, hands the inspector a description of a chair while the inspector signs off anyway.

In this paper each task is a real GitHub issue. The agent works inside a sandboxed copy of the code repository, runs shell commands, and finishes by submitting a patch: a set of code changes. An automatic verifier runs the tests and returns 1 for resolved or 0 for not.

The starting harness is mini-SWE-agent (SWE stands for software engineering): a minimal loop that asks the model for a command, runs it, shows the output and repeats. The authors’ core observation is that the same model can succeed or fail on the same problem depending entirely on its harness.

Policy + harness
How a coding agent works

patch

Harness = the workshop

commands and results

Policy (LLM) = the carpenter
picks the next command

Sandbox copy of the repo

Submit rule
what counts as the final answer?

GitHub issue
the task

Verifier runs tests
1 = resolved, 0 = not

patch

Harness = the workshop

commands and results

Policy (LLM) = the carpenter
picks the next command

Sandbox copy of the repo

Submit rule
what counts as the final answer?

GitHub issue
the task

Verifier runs tests
1 = resolved, 0 = not

Same model, different harness, different result. The base model scores 61.0% on SWE-Bench Verified with the starting harness and 64.5% with an evolved one.
03

Improving One Side at a Time Hits a Ceiling

Researchers usually improve coding agents with one of two methods, and both eventually run into limits.

  • Harness optimization keeps the AI model unchanged and searches for better prompts, workflows or supporting code. It improves how the model is guided, but it cannot make the underlying model any smarter.
  • Policy optimization keeps the supporting code fixed and trains the model itself, typically with reinforcement learning. The model attempts coding tasks, receives a reward whenever its solution passes the tests, and gradually learns to repeat what worked. But it can only improve actions its fixed setup lets it try in the first place.

The two approaches also chase each other: a setup optimized for an older model may not address the weaknesses of a newer one. The paper shows these limits on SWE-Bench Verified, a benchmark of 500 reviewed GitHub issues where the score is the percentage of tasks resolved:

  • The basic agent setup resolves 61.0% of tasks.
  • Harness optimization alone reaches 65.2%. The first round of tuning jumps to 64.3%, but a second round adds less than a point. On a multi-language benchmark, that extra round actually lowers the score from 55.0% to 54.3%.
  • Policy-only training with reinforcement learning reaches 67.5%. Late in training, up to 17% of practice groups fail to produce a single successful attempt, leaving the learning algorithm with no positive feedback to learn from.
  • The model’s score shifts with its setup. The final trained model scores 64.4% with the original harness, 68.1% with a harness tuned for an earlier version of itself, and 69.5% with a harness tuned for its final version.
One side at a time
One side at a time stalls, but the target keeps moving
SWE-Bench Verified, resolve rate (%)BaseHarness onlyPolicy onlyBoth727068666462605856SWE-Bench Verified, resolve rate (%)BaseHarness onlyPolicy onlyBoth727068666462605856
Same final model, three harnesses (%)OriginalTuned for older modelRe-tuned for it727068666462605856Same final model, three harnesses (%)OriginalTuned for older modelRe-tuned for it727068666462605856
Top: “Both” is Self-HPO. Bottom: the final trained model under its original harness, a harness tuned for its earlier version, and one re-tuned for it. Bars start at 55% to show the gaps. A harness tuned for yesterday’s model leaves points on the table: each side changes what the other should fix.
04

Why the Obvious Fixes Do Not Work

The paper tests several shortcuts. Each helps a little, but none matches improving both sides together.

  • Only tune the harness. The self-harness baseline, where the model rewrites its own harness but is never retrained, reaches 65.2% on SWE-Bench Verified. On SWE-Bench Multilingual (300 tasks across nine non-Python languages) it beats the base agent by a mere 0.1 points.
  • Only train the model. Reinforcement learning with verifiable rewards (RLVR), using the test suite as the reward, reaches 67.5%, but it can only learn from the actions its fixed harness allows.
  • Copy a stronger model. Supervised fine-tuning, training the model to imitate example solutions from a stronger model like Opus 4.8, reaches 65.0% on Verified. Outside its training domain it does worse than doing nothing: 49.6% against the base 54.2% on Multilingual, and 49.1% against 58.3% on SWE-Bench Pro (642 tasks across more languages and types of work).
  • Learn only from your own successes. Swapping reinforcement learning for rejection-sampling fine-tuning, which keeps only the model’s own successful attempts, scores 70.5% against 71.6% with reinforcement learning in the paper’s external-designer setup.
  • Keep searching on the same tasks. Reusing the first batch of search tasks instead of refreshing it scores 70.1% against 71.6%.
Part II / The Proposal
05

Self Harness-Policy Optimization

Self Harness-Policy Optimization (Self-HPO) alternates two steps, and the model being trained also acts as the designer that redesigns its own harness.

H
H-step: improve the harness while the model stays frozen. The current model runs on a search set of tasks, reads its own failed attempts and proposes a change to the harness: either the prompt or the harness’s actual Python code. It generates six candidates per round, each building on the best previous version, and scores them all on the same search set to keep the top performer. The designer instructions require it to preserve everything the previous harness did, add exactly one new mechanism, and keep reference answers or task-specific facts out of the agent’s context.
P
P-step: train the model while the harness stays frozen. The model is trained with reinforcement learning under the new harness for 50 updates across 2,484 training tasks. The reward is 1 if the tests pass and 0 otherwise. The algorithm combines Group Relative Policy Optimization (GRPO), where a task is tried several times and the model is pushed toward attempts that beat the group average, with Balanced Adaptive Rollout (BAR): eight attempts are drawn per task and four are kept, so each group holds between 25% and 75% successes and the comparisons stay meaningful.

The handoff: tasks no attempt solved during the P-step become the next search set, and the newly trained model becomes the next harness designer. The first search set is 300 random training tasks. The loop finishes when the set of hard tasks stops changing, which in the paper happened after two rounds.

In workshop terms, the carpenter studies the chairs they ruined, rearranges the workshop, practises working in it, and then uses the chairs they still cannot make as the starting point for the next redesign.
The loop
Self-HPO: one model, two alternating steps

new designer
+ new tasks

best harness

P-step: train the model
(harness frozen)

RL: GRPO + BAR
50 updates on 2,484 tasks

Reward: 1 if tests
pass, else 0

Updated model
= next harness designer

Never-solved tasks
= next search set

H-step: improve the harness
(model frozen)

Run model + harness
on the search set

Model reads its own
failed attempts

Propose 6 harness edits
code or prompt

Keep the best scorer
on the search set

new designer
+ new tasks

best harness

P-step: train the model
(harness frozen)

RL: GRPO + BAR
50 updates on 2,484 tasks

Reward: 1 if tests
pass, else 0

Updated model
= next harness designer

Never-solved tasks
= next search set

H-step: improve the harness
(model frozen)

Run model + harness
on the search set

Model reads its own
failed attempts

Propose 6 harness edits
code or prompt

Keep the best scorer
on the search set

Each round, the model fixes its workshop, trains in it, then aims the next fix at what it still can’t solve. The paper runs two rounds.
06

What Do the Harness Changes Look Like?

The paper shows an evolved harness from the second round of the external-designer setup. It adds four code-based checks around the original loop:

1
Budget valve. Near the step or time limit, the system warns the model and asks for a best-effort submission instead of finishing with nothing.
2
Empty-patch guard. If the submission is empty, the system sends it back once and reminds the model to register new files with git add -N so they appear in the patch.
3
Contract check. The system holds the first real submission and asks the model to verify its function names and signatures against the repository’s existing tests.
4
Patch fallback. If the submitted patch fails to apply cleanly, the system submits the sandbox’s own record of changes instead.
07

How It Is Used: The Two Modes

The same loop runs in two setups. The only difference is which model redesigns the harness.

  • Self-improving mode (Self-HPO): the model being trained is its own harness designer, with no outside model at any point. It reaches 69.5% on SWE-Bench Verified and a 64.8% average across all three benchmarks.
  • External-designer mode (HPO): a stronger fixed model, Opus 4.8, proposes the harness changes while Qwen3.5-35B-A3B is the model being trained. It reaches 71.6% on Verified and a 66.3% average.

In both setups the two-sided loop beats the best one-sided method in that same setup: RLVR at 67.5% in self-improving mode, and Meta-Harness (Opus 4.8 tuning the harness for a frozen model) at 69.1% in external mode.

Both outputs are also useful on their own. The final evolved harness lifts the original untrained model from 61.0% to 64.5%, and the final trained model under the original harness reaches 64.4%. Together they reach 69.5%.

Two modes
Two modes, same loop

External designer: HPO

Harness designer:
Opus 4.8, stronger and fixed

Trained with RL each round
Qwen3.5-35B-A3B

SWE-Verified 71.6%
3-benchmark average 66.3%

Best one-sided rival: Meta-Harness
69.1% (average 63.5%)

Self-improving: Self-HPO

Harness designer:
the model being trained

Trained with RL each round
Qwen3.5-35B-A3B

SWE-Verified 69.5%
3-benchmark average 64.8%

Best one-sided rival: RLVR
67.5% (average 61.9%)

External designer: HPO

Harness designer:
Opus 4.8, stronger and fixed

Trained with RL each round
Qwen3.5-35B-A3B

SWE-Verified 71.6%
3-benchmark average 66.3%

Best one-sided rival: Meta-Harness
69.1% (average 63.5%)

Self-improving: Self-HPO

Harness designer:
the model being trained

Trained with RL each round
Qwen3.5-35B-A3B

SWE-Verified 69.5%
3-benchmark average 64.8%

Best one-sided rival: RLVR
67.5% (average 61.9%)

A stronger designer adds 2.1 points on SWE-Verified. But the self-improving loop still beats every one-sided method in its own setup.
Part III / The Evidence
08

The Performance Numbers

All results are averages of three evaluation runs on real benchmark tasks: measured performance, not projections.

#8209;Verified#8209;Multi#8209;Pro
Benchmark Base Policy only (RLVR) Harness only (Self-Harness) Self-HPO Gain vs RLVR’s gain
SWESWE-Verified 61.0 67.5 65.2 69.5 1.3×
SWESWE-Multi 54.2 56.3 54.3 59.7 2.6×
SWESWE-Pro 58.3 61.8 60.7 65.2 2.0×
Average 57.8 61.9 60.1 64.8 1.7×

Resolve rate in %. The last column is Self-HPO’s gain over Base divided by RLVR’s gain over Base, computed from the paper’s Table 1. For example, SWE-Pro: +6.9 against +3.5 = 2.0×. The biggest multipliers are on the benchmarks outside the Python training data.

  • Main results. Self-HPO raises the average resolve rate across the three benchmarks from 57.8% to 64.8%. On SWE-Bench Verified it rises from 61.0% to 69.5%, beating policy-only reinforcement learning by 2.0 points and harness-only tuning by 4.3 points.
  • Strong cross-domain performance. All training and harness search used only Python tasks, yet Self-HPO gains 5.5 points on SWE-Bench Multilingual (54.2% to 59.7%) and 6.9 points on SWE-Bench Pro (58.3% to 65.2%). That is roughly two to two and a half times what policy-only reinforcement learning gains on the same benchmarks.
  • Greater reliability and a higher ceiling. pass@k is the probability of at least one success in k attempts. With 8 attempts per task, pass@8 rises from 80.0% to 84.8%.
  • Better training feedback. In the final training step, the share of practice groups with zero successful attempts drops to 6.5% over the last ten updates. Standard reinforcement learning stays stuck at 11% to 17%.
  • Competing with much larger models. 69.5% on SWE-Bench Verified puts this model, with 3 billion active parameters, close to leaderboard entries like Gemini 3 Pro (69.6%) and DeepSeek-V3.2 (70.0%). The comparison is not like for like, since those models use the standard mini-SWE-agent setup and Self-HPO uses its own evolved one, but it shows how competitive the smaller model becomes.

Single-attempt success, split by how the base agent did on each task:

Tasks the base agent… Change
solved inconsistently +17.2 points
usually solved +12.9 points
never solved +6.1 points
always solved −2.2 points
09

Important Things to Keep in Mind

Caveats
  • One model and one starting setup. Every experiment uses Qwen3.5-35B-A3B and mini-SWE-agent. The study does not test whether the loop works as well for other models or frameworks.
  • Only two rounds. The paper stops after two rounds of the loop. It is unclear how long the gains would continue or where they would plateau.
  • Small differences fall within normal variation. Standard deviations across runs reach 1.4 to 1.9 points in places, so smaller step-by-step gains, like 68.6% to 69.5%, are within run-to-run noise. The overall gains are well beyond that margin.
  • Not every task improved. On tasks the base agent solved every time, single-attempt success dropped by 2.2 points.
  • The harness changes focus on handing work in. The evolved checks mostly stop good code edits from being lost at submission time through empty or malformed patches. That is a real benefit, but it is about submitting work properly rather than writing better code.
  • Harness checks can raise false alarms. In one case study, a prompt reminder flagged unrelated keywords from the task description, creating a false positive.
  • The leaderboard comparison is not direct. Competitors on the leaderboard use the standard setup; Self-HPO uses its own evolved one.
  • Some ablations used an external designer. The tests comparing training approaches and search-set strategies used Opus 4.8 as the designer, not the pure self-improving mode.
  • Total compute is not reported. Training ran on a single node with eight B200 GPUs, but the paper does not give the time or total compute for a full loop.
  • It is a preprint. Posted on arXiv in October 2026, it has not yet been peer-reviewed.
10

Conclusion

An AI agent is both a core model and the system around it, and the two constantly shape each other. Improve only the system and you stay limited by the model. Improve only the model and you stay limited by what the system lets it attempt. Improving both in turns, aimed at the remaining failures, lets the overall gain exceed the sum of its parts.

The most unusual part is who does the redesigning. The model examines its own failures and rewrites the code of its own working environment, with no stronger outside model to guide it.

The paper leaves agent builders with a pointed question: if the harness and the model reinforce each other this strongly, why are we still optimizing only one side at a time?