Letting Harness Improve Itself
STOP recursive improver + Self-Harness propose-evaluate-accept loop
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Letting Harness Improve Itself”?
STOP recursive improver + Self-Harness propose-evaluate-accept loop
Make the claim earn its place. Use this page as a decision aid, not a definition to memorize. Connect the idea to one real task, one observable result, and one failure that would change your mind.
Write one question you could answer with evidence after trying this idea.
A conclusion that sounds complete but leaves the key assumption untested.
The seed improver I₀ takes three inputs: an initial solution s, a utility function u, and a black-box language model M, and returns an improved solution s'.
Key insight: the improver itself is text (a prompt or code), so the same improvement logic can be applied to the improver itself.
I_t = I_{t-1}(û, I_{t-1}; M)
// Where:
// I_{t-1} — current improver (prompt/code in text form)
// û — meta-utility: function measuring improver quality
// M — black-box language model
// Output I_t — a better improver
The improved improver automatically discovered classic optimization strategies including genetic algorithms, decomposition-based improvement, multi-arm Prompt Bandit, simulated annealing, and Beam Search—all without human pre-specification.
GPT-4 can improve consistently, but GPT-3.5 and Mixtral actually regress. The recursive structure alone is insufficient: the base model must be strong enough to support meta-level optimization.
Warning: Recursion ≠ Guaranteed Improvement
The recursive structure provides the possibility of improvement, but does not guarantee convergence. Weak models lack sufficient programming intuition at the meta level, and instead amplify noise: results regress rather than improve. This reminds us that the safety of self-improving systems must be grounded in an accurate assessment of base model capability.
Weakness Mining
Clusters failure trajectories into verifier-grounded failure patterns. Each failure record must include: terminal-verifier-level cause + causal state of related Agent behavior + abstract Agent mechanisms exposed by the trajectory.
Harness Proposal
Proposes bounded Harness edits based on mined failure patterns. The model receives: the editable surface, failure pattern summaries, records of passing behavior, and a history of previously attempted edits. Priority is given to addressable recurring error patterns.
Proposal Validation
Validates candidate edits using held-in and held-out datasets. Only accepts edits without regression, ensuring improvements don't sacrifice existing capabilities.
Harness Design = Executable Search Space
Once Harness design is formalized as an executable search space (editable prompts, policy configurations, tool orchestration code), a capable coding Agent can exploit the same design space that human engineers use: automating search, proposal, and validation without relying on manual debugging case by case. This opens up improvement possibilities far larger than hand-written prompts.
Safety Boundaries Are Indispensable
If a program is allowed to edit OS-level configurations, abstraction boundaries will be violated. The editable surface of a self-improving system must be carefully designed: permission controls and security layers must sit outside the improvement loop, guaranteed by humans or tamper-proof oversight mechanisms. Self-improvement without boundaries is self-improvement out of control.
The algorithmic cost curve in “STOP: Self-Taught Optimizer”
“The improved improver automatically discovered classic optimization strategies including genetic algorithms, decomposition-based improvement, multi-arm Prompt Bandit, simulated ann…” is not asking you to memorize steps. It trains you to spot repeated work: as the input grows, how many comparisons, moves, or recursive calls does the program perform?
Find repeated work before declaring something fast
Break “GPT-4 can improve consistently , but GPT-3.5 and Mixtral actually regress.” into three questions: how input size changes, what each round does, and whether the next round can shrink its search space. Big-O describes growth, not an exact time on every machine; constants, memory, and data distribution still matter.
Theoretical optimum is not always practical optimum
When AI writes an algorithm, trace a small input by hand and benchmark progressively larger inputs. That turns “If a program is allowed to edit OS-level configurations, abstraction boundaries will be violated .” from a slogan into a performance claim you can check.
From “STOP: Self-Taught Optimizer” to “STOP's Findings”
“STOP: Self-Taught Optimizer” grounds the problem in “💬 Plain talk: Imagine a craftsman who sharpens his own knife . The ordinary approach is to use the knife to cut vegetables (using a tool to solve a problem); STOP's approach is to first master the skill of sha…”. “STOP's Findings” then moves it toward “The improved improver automatically discovered classic optimization strategies including genetic algorithms, decomposition-based improvement, multi-arm Prompt Bandit, simulated annealing, and Beam Search—all wi…”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
For a real task, find the repeated work first, ask how input size changes, and use a small benchmark to verify the theoretical judgment. Complexity should not become a label detached from the situation.
- “STOP: Self-Taught Optimizer”: 💬 Plain talk: Imagine a craftsman who sharpens his own knife . The ordinary approach is to use the knife to cut vegetables (using a tool to solve a problem); STOP's approach is to first master the skill of sha…
- “STOP's Findings”: The improved improver automatically discovered classic optimization strategies including genetic algorithms, decomposition-based improvement, multi-arm Prompt Bandit, simulated annealing, and Beam Search—all wi…
- “The closing point”: If a program is allowed to edit OS-level configurations, abstraction boundaries will be violated . The editable surface of a self-improving system must be carefully designed: permission controls and security la…
The final “The closing point” brings the discussion to “If a program is allowed to edit OS-level configurations, abstraction boundaries will be violated . The editable surface of a self-improving system must be carefully designed: permission controls and security la…”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.