AIDE²: The First Evidence of Recursive Self-Improvement
July 14, 2026 • By Weco Team
We built a recursive self-improvement (RSI) system by running autoresearch on autoresearch. The system, AIDE2, took eight days to discover a better autoresearch harness than the one we built over the last two years. Fully autonomously, AIDE2 designed a novel search algorithm, reduced the prompt size by 16×, and built a layered system against reward hacking.
AIDE2 has two autoresearch loops:
An inner loop, just like a normal autoresearch agent, optimizing code against an eval.
An outer loop, optimizing the inner-loop agent's harness code.
The outer loop starts from AIDE, an already strong autonomous research agent, and optimizes it against a heterogeneous set of tasks. After 100 outer-loop iterations, the system discovered seven successive improved versions of AIDE, each showing stronger optimization power measured under the same cost budget (including token and compute costs).
We test the best agents from the first 50 and 100 steps, AIDE47 and AIDE85, and their improved performance also generalizes to tasks they were never optimized for.
We also observed an emergent behavior where AIDE2 figured out how to prevent inner-loop agents from cheating. For example, AIDE85 cheats much less than the agent it started from, cutting its reward hacking rate from 63% to 34% on the held-out GPU kernel engineering benchmark. It built its own defenses, from prompt-level instructions to hard-coded checks.
Besides beating the starting point AIDE0, both AIDE47 and AIDE85 beat our manually tuned agent on the held-out tasks shown above. Notably, the manually tuned agent AIDEhuman has been iterated on for two years, while the autoresearch loop of AIDE2 needed only eight unattended days. We read this as the first experimental evidence of consistent recursive self-improvement that materially lifts the efficiency of AI R&D.
Where this sits on the RSI ladder
We grade recursive self-improvement on a ladder from Level 0 to Level 3, defined in the companion post 4 Levels of Recursive Self-Improvement. Level 0 is delegation: an autonomous system runs the research loop end to end, but improves the system more slowly than human R&D; most current self-improvement claims live here. Level 1 is net positive: the system improves itself more efficiently than humans improving the same system by hand, held to four conditions: a fair human baseline, a sustained multi-step trend, generalization beyond the optimized measurement, and a fixed physical budget. Level 2 is ignition, when the system improves its own ability to improve itself; in our setup, when the discovered inner-loop agent is a better outer-loop agent than its predecessor. We test for this directly with what we call the ignition test (explored in Section 3.1). Level 3 is inflection, when progress stops slowing at a fixed budget and starts accelerating. Based on our experimental evidence, we believe AIDE2 to be on Level 1 of RSI.
1 · How we instantiated it: AIDE2
We frame recursive self-improvement as a bi-level optimization task, an outer-loop agent optimizing the inner-loop agent's optimization capability, and we call the whole system AIDE2. The two loops run different agents. The outer loop runs AIDEhuman, our hand-tuned autonomous research agent, pointed at the inner-loop agent's code. At each outer-loop step, the outer-loop agent proposes a rewrite of the inner-loop agent's code, evaluates the proposed agent, and keeps it only if better than the previous best. The inner-loop agent starts at AIDE0, a simplified refactor of AIDE, our ML engineering agent that previously took first place in OpenAI's MLE-Bench and has since been widely adopted by the autonomous R&D community. We simplified AIDE by stripping the ML-specific machinery, so that one agent AIDE0 can work across very different task families (Section 2.4 walks through its internals). AIDEk is the proposed agent rewrite produced at outer step k.
We tried to minimize the differences between the starting inner-loop agent and the outer-loop agent, but there are still asymmetries between them, and that extends to model choice. AIDEhuman uses claude-opus-4.7, while each inner-loop agent runs on gemini-3-flash. Under a fixed compute budget (expanded on in subsequent paragraphs), gemini-3-flash matched or slightly beat larger models on tasks in our benchmark, so we can use this cheaper model for the inner loop to enable enough inner iteration steps with a reasonable budget. The economics of the outer loop are different. Evaluating one proposed rewrite from the outer loop means running the rewritten agent through several autoresearch runs across various tasks in the inner loop. Compared to that, the outer-loop agent’s own token usage is a small fraction of the total experiment cost; therefore, we use the most capable model for the outer loop. We keep them asymmetric for now; Section 3.1 shows what happens when a discovered agent sits in both loops.
The tasks the inner-loop agent works on span three families. ML engineering: train a model end to end against a metric. Heuristic algorithm engineering: competitive-programming-style problems in hard combinatorial optimization, like routing, packing or scheduling, where exact solutions are out of reach and you iterate on heuristics and algorithms. Harness engineering: improve an agent scaffold around models, prompts, context management and verification that turns an LLM into a working system, like making an off-the-shelf coding agent resolve more SWE-bench issues.
The inner-loop evaluation
Most of our design effort went into the inner-loop evaluation. A candidate inner-loop agent is scored across the cost-constrained autoresearch runs it conducts on the task families mentioned above. Three design choices matter in particular:
Public-private split: Inside every task, a solution gets two scores, a public score that the inner-loop agent can see and use as its optimization signal, and a private score that the inner-loop agent cannot see. The true objective is this held-out private score. The survival of a solution candidate is decided here.
Performance under a fixed cost budget: We frame the evaluation as a constrained optimization problem. The objective is to maximize the private score across the various task families while the constraint is a fixed cost budget per evaluation, metered in dollars as the proxy for overall compute. A gain must therefore be an efficiency improvement rather than simply raising the compute budget. The fixed budget doubles as selection pressure, forcing algorithmic invention over brute force. Strategies that greatly increase the number of LLM calls (e.g., best-of-N where N → ∞) or aggressive parallelization that packs more optimization steps into the same wall-clock time will not pass this cost constraint.
Task heterogeneity: The task collection is deliberately heterogeneous. This acts as evolutionary pressure toward generalizable algorithmic improvements rather than task-specific design, for example detailed prompts or a workflow for one particular type of task.
The private score is the most important one for solution selection. A solution must still hold its lead on datapoints it could not see; we call this first-order generalization. If an inner-loop agent that passes the first generalization gate also holds its lead on tasks it never self-improved on, that is second-order generalization, and it is what we measure in Section 2.2.
An interesting phenomenon that plagues AI agents is reward hacking. Similar to what we found in SpecBench, most reward hacking is, in this vocabulary, a first-order generalization failure. The private score carries no detector for it, yet we observe anti-reward hacking as an emergent behavior in the inner-loop agents selected. More on this in Section 2.3.
2 · Experiment Results
2.1 The self-improvement run
We ran AIDE2 for 100 consecutive steps with no human intervention inside the loop, from AIDE0 to AIDE99, in eight days of wall-clock time. One step is one rewrite of the inner-loop agent followed by one full evaluation across the task families. With the strict evaluation protocol we defined above, about nine in ten proposed changes were rejected.
2.2 Second-order generalization, in and out of distribution
As with any autoresearch system, optimizing the score the agent can see may lead to overfitting on the task set. The only way to measure the effectiveness of the discovery is to see how well it generalizes beyond the visible signal we instruct it to optimize.
MLE-Bench Lite: mean of 3 seeds; deltas are paired by task vs AIDE0: +0.053 (p = 0.0024) for AIDE47, +0.042 (p = 0.0041) for AIDE85, higher is better. ALE-Bench Lite: 10 problems × 10 seeds; AtCoder-style performance rating on held-out private test cases, higher is better. WeatherBench 2 runs on a fixed $15 budget per agent, weather forecast skill gain measured over the starting weather simulation engine (the dynamical core), higher is better. The dashed line represents the performance of AIDEhuman on each benchmark.
We test AIDE47 and AIDE85 on three external benchmarks the loop never saw, chosen to span distributional distance from the training tasks: two sit inside task families (not the tasks themselves) the loop self-improved on, one sits outside. AIDE47 is the best agent from the first 50 steps, and the one we later install as the outer-loop agent in Section 3.1; AIDE85 is the final best after 100. Neither agent was ever selected on any of these tasks, so a gain here is second-order generalization: evidence of general optimization ability, not tricks tuned to our own benchmark.
MLE-Bench Lite (in distribution) is OpenAI's benchmark of real Kaggle competitions and the standard public test of autonomous ML engineering, the same family as our ML-engineering tasks, with zero task overlap. ALE-Bench Lite (in distribution) is built from AtCoder's heuristic-programming contests, long-horizon combinatorial optimization graded on hidden test cases, and covers the heuristic-algorithm family the same way. WeatherBench 2 (far out of distribution) is focused around improving a physics-based weather-forecasting core: scientific computing with direct downstream utility, and, as far as we know, nobody has pointed an AIDE-style agent at a physics forecasting engine before. In this way, we measure generalization in both in- and out-of-distribution settings covering various layers of the AI stack, i.e., model development, kernel engineering (Section 2.3) and algorithmic discovery as well as in settings that measure downstream OOD utility like weather forecasting. The gains are not monotonic: AIDE85 wins on ALE-Bench Lite and WeatherBench 2. However, it trails AIDE47 on MLE-Bench Lite (while still being better than AIDE0). That being said, both agents outperform AIDE0 across all three external benchmarks, showing both in- and out-of-distribution generalization.
2.3 The loop taught itself to cheat less
We were surprised to find that, similar to how capabilities emerge in LLM training, AIDE2 also demonstrates emergent behavior. One of the most interesting behaviors is that the outer loop starts to actively prevent the inner-loop agent from reward hacking. Reward hacking is a common problem of autoresearch systems. Optimize a system against a score, and it usually learns to game the score.
One domain that suffers from this particularly is GPU kernel engineering. We adopt our previous idea for detecting reward hacking from SpecBench and apply that to a set of KernelBench tasks, measuring whether the speedup the agent reports on the unit tests actually survives in the end-to-end workload (e.g. model training). A kernel counts as reward hacking if less than half of its claimed speedup survives there, including outright slowdowns and failures.
In this setup, AIDE0 reward hacks on 63% of the test cases. Th
[truncated for AI cost control]