Fix the "Scaffold" Before You "Make the Model Stronger"—How Microsoft Had Its Coding Agent Rewrite Its Own Work Environment to Boost SWE-bench
Microsoft Research's Self-HPO has a coding agent rewrite its own "scaffold (harness)" and trains it in alternation with the weights. With a 35B model, the SWE-bench average rose from 57.8% to 64.8%. A read on the synergy between scaffold and weights, and the pitfalls of self-improvement.
Same model, different results
The capability of a coding agent isn't determined by the model inside it alone. In a study called "Self-HPO" released by Microsoft Research, the agent is made to rewrite the scaffold (harness) that surrounds the model, and then its weights are retrained on top of that—pushing performance higher.
The paper was posted to arXiv dated October 16, 2026, and the trained model and code are available on GitHub (MSR-Orchard, MIT license). The base model is Qwen3.5-35B-A3B, and the study reports raising the average resolution rate across three coding benchmarks from 57.8% to 64.8%.
What the "scaffold" that swings results really is
The scaffold here refers to everything other than the model's weights. An explainer article calls this the "scaffold surrounding the model" and organizes it as controlling the following four things.
- Context: what the model sees (the content of the information you hand it)
- Tools: how the model's actions get executed
- Feedback: what comes back as the result of execution
- Termination conditions: when to cut off the work (episode)
Even with the same model, which problems it can solve changes depending on how this scaffold is assembled. What Self-HPO aims for is growing this scaffold and the model's weights together.
Turning two knobs alternately
Self-HPO alternates between a step that fixes the scaffold (H-step) and a step that trains the weights (P-step). In the H-step, the current policy (the model) reads its own failures and proposes new scaffold candidates on its own. In the P-step, reinforcement learning is run under the chosen scaffold, and the weights are updated.
At this point, the hard problems the agent stumbled on during training are routed back as the problem set for the next scaffold search. It's a mechanism where failures automatically narrow the target for the next round of improvement.
There are two styles for the scaffold-proposer role. There is HPO, which has a strong external model (e.g., Claude Opus 4.8) make the proposals, and Self-HPO, which has the policy itself make them and thus needs no external model. The former has a higher performance ceiling, while the latter has the advantage of the lightness of being able to run on its own.
By the numbers: how the scaffold and the weights take effect
The SWE-bench-family resolution rates shown by the public repository are as follows (units: %, source is the repository's results table).
| Setting | Verified | Multilingual | Pro | Average |
|---|---|---|---|---|
| Base (plain model) | 61.0 | 54.2 | 58.3 | 57.8 |
| HPO (external model proposes scaffold) | 71.6 | 61.4 | 66.0 | 66.3 |
| Self-HPO (self-proposed) | 69.5 | 59.7 | 65.2 | 64.8 |
What stands out is the synergy between the scaffold and the weights. In the explainer article's breakdown analysis, in one setting "scaffold-only improvement was +3.5 points" and "weights-only improvement was +3.4 points," yet combining the two reached +8.5 points. The explanation given is that a good scaffold turned previously-failing problems into solvable ones, supplying learning signal that was effective for reinforcement learning.
Lessons the development field can take away
This is research into training a huge model in-house, but it offers suggestions applicable to those who use agents day to day as well. The explainer article lists practices like the following.
- When you upgrade the model, re-tune the scaffold (prompts and tool configuration) as well
- Dig out the hardest cases from training and execution logs, and use them to rethink the scaffold
- Cross old and new scaffolds with old and new models to compare, isolating which improvement it was before attributing the result
- Inspect the "submission logic" (how results are returned) of failed runs
When you find that "I changed the model but it didn't improve as much as I expected," the point that the cause may lie on the scaffold side is also useful in the field of tool selection and configuration tuning.
The shadow that remains over self-improvement
On the other hand, a framework in which an agent evaluates and improves its own scaffold has aspects that warrant careful scrutiny. When the loop of self-evaluation closes in on itself, there are pointed-out risks of overfitting—optimizing too heavily to a particular benchmark—and of skewing toward apparent improvement.
Verification that alternates between scaffold and weights carries a correspondingly high compute cost, and isolating which step an improvement came from is not easy either. The view has also emerged that if you put an agent that rewrites its own scaffold straight into production, you need a design that keeps the change history traceable and inserts human audits. Put without hype: we have entered a stage where, behind the convenience, we also have to think about these difficulties of evaluation and control.
References: arXiv: Self-Evolving Coding Agents via Harness-Policy Optimization / GitHub: MSR-Orchard/Self-HPO / learnagentic: What is harness-policy optimization? / Hugging Face Papers
