Harness Learning: Only the Program Grows While Weights Stay Frozen
A 4B model writes better agent code than its 35B teacher. And it isn't solving tasks directly—its entire job is modifying another piece of code. A new paper from CMU and Johns Hopkins (arXiv 2609.35738) calls this Harness Learning: train a model specialized in revising an agent's program, and use the task score of the revised program as the reward signal. Throughout the entire test process, all model parameters stay frozen; only the program changes.
What a harness is
A language model agent is really two things combined: the model, plus the *harness*—the executable program that organizes model calls, tool use, and information flow. The same model paired with different harnesses behaves like a completely different agent: search-then-answer, decompose-then-dispatch, or compute-while-self-checking—all decided in the program.
These programs are task-sensitive. Maze and sudoku tasks want different organization; single-hop and multi-hop QA need different retrieval orchestration. So the harness needs adjusting based on feedback from the current task. Prior automated approaches (the automated workflow-design family) mostly *search on the spot*: given a task, try various structures live and pick the best. This paper takes a different angle—make "revising harnesses" itself a learnable capability.
Meta-learning, but for programs
The key move is an analogy: harness revision plays the role that weight updates play in gradient descent.
Traditional meta-learning trains a model to adapt quickly to new tasks with a few gradient steps. Here instead: train a proposer model that, facing a new task, can propose a few harness revisions to adapt quickly. Inputs: task description, current program, and an execution report from the previous version. Output: a revised program. Reward: the program's score on new problems. Training uses GRPO, starting with supervised cold-start on the 35B teacher's revision data, then reinforced with RL.
At test time, the trick: proposer and solver parameters are all frozen. The proposer reads the task, proposes a revision, runs it, inspects feedback, proposes again—five, ten rounds—and the program grows round by round while neither model's weights move at all. What "the ability to revise harnesses entered the model weights" means is precisely this: the capability is trained in, and at test time it is cashed out as program edits.
The numbers
In Reasoning Gym experiments, the proposer was tested on 21 task families never seen in training; its revised harnesses averaged above its 35B teacher—with a caveat: that's the average under single-step revision, not a win on every task. The QA results are more granular: a proposer trained only on HotpotQA still works when dropped onto MuSiQue and 2WikiMultihopQA. On HotpotQA itself, exact match starts at 0.39 and averages 0.41 after a single revision; picking the best of eight candidates (oracle) reaches 0.54. 71% of revisions improve the original program, and only 1.3% break it—the proposer learned not just "how to revise" but "how to rarely break things."
The multi-round story is more interesting. On MuSiQue, independently proposing one revision moves the score from seed level to only 0.15, while ten consecutive revision rounds reach 0.27—the program really can grow round by round. But another experiment counsels restraint: on Reasoning Gym, the single-step RL proposer captured most of its five-round gains in the first round, with thinning marginal returns afterward; the QA setting is the reverse, where the first revision contributes only one-third to two-thirds of total gains—suggesting programs still have room to grow on long-context tasks. When programs can grow and when they can't, the two settings give two different answers.
Two roads, one division of labor
A 2026 blog post by Jason Wei–style thinking from Zhiting Hu's camp, *Learning Beyond Gradients*, proposed heuristic learning: let AI write accumulated experience directly into editable state—programs, heuristics, memos—modifying things in the external world while weights stay untouched.
Placed alongside this paper, the two form a contrast. One road writes experience into the program: every edit is made on the spot by the model reasoning in the moment. The other trains the revision strategy into the model: spend heavy compute upfront building the intuition for "how to revise programs," then at test time the model learns nothing new—it only acts. The former reasons live for every change; the latter compresses reasoning into reflex. As for which is cheaper—this paper's answer leans toward the latter: that 1.3% breakage rate is hard to achieve stably with on-the-spot reasoning.
Where it sits on the autonomy ladder
A September RSI survey from Shanghai Jiao Tong University, *The Last AI Built by Humans*, divides recursive self-improvement into five levels: L1 execution autonomy, L2 strategy autonomy, L3 experience autonomy, L4 deployment/environment adaptation, and L5 meta-improvement—improving "the improvement process itself." The survey defines L2 as: the system autonomously decides how to improve, but the improvement objectives, evaluation criteria, and acceptance rules remain externally given. Harness Learning sits exactly at this level: the proposer decides what to change and how, but whether a revision is kept follows a fixed rule—it is retained only when dev-set scores improve.
That acceptance rule deserves a second look. It is the least AI-like part of the whole loop, yet possibly the most critical: the program can grow round by round, but each round's "sign-off" is held by human-set rules. The road beyond L3—letting the system accumulate its own experience and adapt to its own environment—is untouched by this paper; task families remain confined to reasoning and multi-hop QA. The program grows, but the fence is still there. The real picture of this current step: the power to revise has been delegated; the power to accept has not.