AIDE²: The First Evidence of Recursive Self-Improvement

We built a recursive self-improvement (RSI) system by running autoresearch on autoresearch. The system, AIDE², took eight days to discover a better autoresearch harness than the one we built over the last two years. Fully autonomously, AIDE² designed a novel search algorithm, reduced the prompt size by 16×, and built a layered system against reward hacking.

AIDE² 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, AIDE₄₇ and AIDE₈₅, and their improved performance also generalizes to tasks they were never optimized for.

We also observed an emergent behavior where AIDE² figured out how to prevent inner-loop agents from cheating. For example, AIDE₈₅ 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 AIDE₀, both AIDE₄₇ and AIDE₈₅ beat our manually tuned agent on the held-out tasks shown above. Notably, the manually tuned agent AIDE_human has been iterated on for two years, while the autoresearch loop of AIDE² 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 AIDE² to be on Level 1 of RSI.

1 · How we instantiated it: AIDE²

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 AIDE². The two loops run different agents. The outer loop runs AIDE_human, 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 AIDE₀, 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 AIDE₀ can work across very different task families (Section 2.4 walks through its internals). AIDE_k 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. AIDE_human 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 — think speedrunning Karpathy's nanochat. Heuristic algorithm engineering: competitive-programming-style problems in hard combinatorial optimization — think routing, packing, 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 — think 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 AIDE² for 100 consecutive steps with no human intervention inside the loop, from AIDE₀ to AIDE₉₉, 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 AIDE₀: +0.053 (p = 0.0024) for AIDE₄₇, +0.042 (p = 0.0041) for AIDE₈₅, 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 AIDE_human on each benchmark.

We test AIDE₄₇ and AIDE₈₅ 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. AIDE₄₇ is the best agent from the first 50 steps, and the one we later install as the outer-loop agent in Section 3.1; AIDE₈₅ 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: AIDE₈₅ wins on ALE-Bench Lite and WeatherBench 2. However, it trails AIDE₄₇ on MLE-Bench Lite (while still being better than AIDE₀). That being said, both agents outperform AIDE₀ 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, AIDE² 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, AIDE₀ reward hacks on 63% of the test cases. The discovered agents hack much less often, 42% for AIDE₄₇ and 34% for AIDE₈₅. Our hand-tuned AIDE_human only matches AIDE₄₇ at 42%.

These results are surprising as we did not give AIDE² any instructions about reducing reward hacking, yet the evolved anti-reward-hacking mechanism is more effective than our human-engineered measures. A possible explanation of this emergence is that the outer loop is selecting solutions based on private scores which the inner-loop agent cannot observe, so variations of the inner-loop agent that win by gaming the public score do not survive. Under that pressure the loop also built defenses against its own cheating, which we will expand on in the next section.

2.4 What ideas were discovered

Here, we show an overview of what the best-performing agent AIDE₈₅ looks like. But first, we provide some background on where the self-improvement starts.

The baseline. AIDE₀ is a simplified and generalized rewrite of the original AIDE. The tree search is kept, but the MLE-specific machinery is gone. It takes an existing codebase and a measurable metric, and grows a solution tree with that code as the root. AIDE-style tree search agents consist of several operators for different scenarios, e.g., drafting, debugging and improving a particular solution. Which solution is operated on (i.e., the parent node) is determined by the agent’s search policy. In the case of AIDE₀, the agent first writes five drafts, each prompted to try something very different. After that, each step either debugs a random buggy leaf or improves the best solution in the whole tree. The selection is greedy: whoever is best becomes the parent node to the next step. An eval reviewer reads each execution output and extracts the score for each node in the tree. The context handling is naive: when performing drafting or improving, the prompts to the LLM carry the full history of every earlier attempt, each attempt’s complete source code and everything its execution printed.

AIDE₈₅ improved on AIDE₀ in several ways:

1. Search policy: An obvious question for improving AIDE is how to better balance exploration vs. exploitation. AIDE₈₅ isn’t based on a more complex algorithm like MCTS, which the outer loop tried but the benchmark eventually rejected. Its search policy is an extension of AIDE, where each draft’s subtree acts as an arm in a multi-armed bandit. Each time, the agent decides which lineage to invest in with an exploration tendency, but when a lineage is chosen, the parent selection becomes greedy again. There’s also a mechanism to address local optima: when the best lineage stalls, it forks the global best under a fresh strategy. The fork copies the best node’s code into a new lineage: later improvements are steered by a different strategy, and the bandit funds the new lineage as a fresh arm instead of the stalled one. The whole decision cascade is quite complex; we show it in the figure below.

2. Context engineering: AIDE₈₅ built a context engineering system that very aggressively cuts the context. It made the trajectory summary much more compact than in AIDE₀ and AIDE_human. It engineered each operator’s context in a very specific way, providing the minimal information required for its role. This is very different from the main trend of agent design, where the general philosophy is to put as much context as possible into the LLM. The compression it found averages 16× on the full prompt against naive history concatenation, and the tokens saved are reinvested as additional search steps the agent can run.

Matrix mechanics: half circle = component included only when the recent bug rate passes 15%; eval review reads execution output through the guard (de-duplicated, head+tail, 32k cap) while debug gets the raw tail; improve additionally reads a plateau signal from the last four scores. Newest-12 one-liners + one full solution replace full transcripts. Provenance: summary and gate from steps 2 and 6; the output guard from step 63, added after a self-diagnosed crash.

3. The eval repair: The outer loop wrote a gigantic monkey patch to one of the evaluations. At first we read it as reward hacking. It was the opposite. Our harness-engineering evaluation script carried a bug where a traceback in one input example crashed the entire private eval, and the patch fixed it. This is no algorithmic improvement, and the effect on scores is negligible. But presented with a defective evaluation, the loop repaired it rather than exploiting it, an emergent behavior worth reporting.

4. Reward hacking prevention: AIDE₈₅ has a three-layer defense against reward hacking.
   • An anti-overfitting instruction injected into every stage prompt.
   • A hard-coded guard that regenerates suspicious outputs instead of trusting them.
   • A statistical layer that aims to remove the “extreme” successes that are too far away from their peers, because they might be reward hacking.

   The statistical layer was the most interesting idea, but ironically, we found the implementation has a bug; effectively, this mechanism has no impact on AIDE₈₅. Tracing further down the lineage, we found an earlier version of the agent did implement the mechanism correctly, but it was broken in a later mutation.

2.5 What did not work, which is most of it

The algorithm the loop eventually discovered is a composition of rather simple mechanisms. That is despite the loop trying advanced ideas: in one seed we hand-read all 95 rejected proposals, and they cover a surprising share of the literature in evolutionary search, tree search, and LLM-driven optimization. Under the fixed budget, they did not pass the improvement gate:

Δ is the private delta vs the incumbent at that step; run-to-run noise is ≈0.02–0.045, so italic within noise deltas are coin flips.

2.6 Net positive

Internally, we spent years iterating on AIDE_human, and it shares most of its mechanisms with the production version of Weco. The community has also spent enormous resources on optimizing agents of this kind, with limited algorithmic progress to show for it (AIRA-Dojo, FML-Bench). The outer loop discovered significantly better versions on its own. The figure in Section 2.2 shows that the discovered inner-loop agent AIDE₈₅ beats AIDE_human (dashed line) across all three external benchmarks on a strict measurement that fixes cost and requires gains to be generalizable across tasks. In addition, we see in Section 2.3 that AIDE₈₅ reward hacks less than AIDE_human on KernelBench.

If we compare agent-driven and conventional human-driven R&D in the outer loop, we find that AIDE² is roughly two orders of magnitude faster than human R&D in terms of invested time. Taken together, this clears the four conditions we set for Level 1 RSI: a fair human baseline (AIDE_human), a sustained multi-step trend (seven successive improvements over 100 unattended steps), generalization beyond the optimized measurement (both in and out of distribution), and a fixed physical budget (the fixed per-evaluation cost). We believe this is the first autonomous recursively self-improving system that materially accelerated the AI R&D process, reaching Level 1 of RSI.

3 · Discussion

3.1 Ignition and the third-order generalization

With AIDE² reaching the net positive level of RSI, the next level (Level 2) asks a different question. Did the outer loop produce a better improver for the outer loop, or only a better inner-loop agent? This is a crucial question for an RSI system, as understanding the position of such a system on the RSI ladder helps us understand our progress towards an intelligence explosion. We test this by installing AIDE₄₇ in the outer-loop seat, rerunning the outer-loop optimization, and comparing it against AIDE_human as the outer loop.

On the training distribution, both arms converge to a similar ceiling. The discovered improver AIDE₄₇ reaches it in around 20 steps, whereas the hand-built one, AIDE_human, needs about 40 steps. Although AIDE₄₇ is more sample-efficient, we do not think this is strong enough evidence of ignition, given that AIDE₄₇ is not asymptotically better. Part of the difficulty of assessing ignition is the measurement itself, since nested loops compound many sources of noise. Even the efficiency claim is not statistically significant.

3.2 Living with code you didn't write

Despite the strong performance, one problem we found with the evolved inner agent is that it is fairly difficult to work with. Like a lot of autoresearch and, more generally, vibe-coding artifacts, the final evolved agent AIDE₈₅ has fairly complex logic, and in general it is very difficult to understand how the system works. This increases the friction of deploying it into production, as we need to maintain compatibility with product features like visualization and steerability. We think there’s room for improvement here.

At the same time, we’re very surprised that such a codebase would lead to an agent that transfers better than our much cleaner and well-thought-out hand-tuned agent. Why is that the case?

Part of the mystery might be tied to perceived complexity and information density: we’re more familiar with the agent we designed, as we spent our own time building it. Although it is clearly documented, another team might still need to spend some time to understand AIDE_human fully. Meanwhile, the outer-loop agent might have done months’ or even years’ worth of experiments, which can overload one’s cognition if one doesn’t spend enough time trying to understand it.

We’re also wondering to what extent we should transfer our taste, learned from manual engineering and research, to autonomous research. One potential solution is to treat a modular piece of code as a black box and focus on interface design to handle the increased velocity of autonomous knowledge generation.

4 · Conclusion

In this work we showed AIDE², the first recursive self-improvement system that reached the net positive level of RSI: a sustained autonomous sequence of self-improvements that beats human-driven improvement per unit of R&D spend. An autonomous research agent built seven successive improved versions of itself in eight days, at orders of magnitude higher efficiency than a manual AI R&D loop. The discovered agent achieved both first- and second-order generalization and taught itself to reward hack less.

The system surprised us, and living with it taught us its limitations. The evolved agent's complexity blows up, and some of it is plain dead code; both make further customization and production deployment harder.

We also do not think the system achieved third-order generalization, what we call the ignition condition, where the improved inner-loop agent becomes a better outer-loop agent. Ignition is a necessary condition for an intelligence explosion, not a sufficient one. So we believe we are not near an intelligence explosion with the current system.

With all of that said, this system is the worst version of itself we will ever see. AIDE² is only just on Level 1 of the ladder to fully capable RSI that can lead to intelligence explosion. We think it matters to share what we have seen and what we expect to happen next, as we believe even more advanced versions of RSI are just over the horizon. A PDF technical report with the full protocol and analysis, and the release of AIDE₈₅ itself, will follow when the remaining analysis lands. Our hope is that our framework for thinking about Recursive Self-Improvement can help the community move towards a future of RSI with a better understanding of its capabilities.