Recursive Self-Improvement in AI: 2026 Examples

On February 5, 2026 OpenAI shipped GPT-5.3-Codex and wrote that it was “our first model that was instrumental in creating itself.” Early versions of the model had helped debug its own training run. The reaction split fast. Half read it as the first step toward a runaway machine. The other half read it as an ordinary productivity story. Both were reacting to the same phrase: recursive self-improvement.

That phrase moved from thought experiment to product talk this year, and the searches followed. This post is for the reader who wants the grounded version: what recursive self-improvement in AI actually means, the loop that makes it work, and the verified systems running it right now.

We will define it without the philosophy, show the three-step loop with runnable code, catalog the 2026 examples by the fixed signal each one improves against, and cover how teams keep such a loop safe.

Where a claim is bounded, we say so plainly. The mechanism is real and narrow, and the line between real and hyped comes down to one design choice we keep returning to.

What Recursive Self-Improvement in AI Actually Means

Recursive self-improvement in AI is a system that improves its own future performance by repeatedly changing something it controls, then carrying forward the changes that score better against a fixed measure. The thing it changes can be its prompt, its code, its training data, or its policy. The measure is what makes it more than random editing.

The idea is old. In 1965 the statistician I.J. Good described an “ultraintelligent machine” that could design even better machines, and argued the first such machine is “the last invention that man need ever make, provided that the machine is docile enough to tell us how to keep it under control.” That final clause is almost always cut when the line is quoted.

Good’s original paper is the origin of the concept, and it is worth reading in his words rather than through loose paraphrase.

Later writers gave the starting point a name: “seed AI,” a system just capable enough to begin improving itself. The label marks an entry condition. A system that cannot yet make a reliable improvement to itself is not a seed, no matter how large the model behind it is.

Draw the line early, because most confusion starts here. The recursion lives in the loop, not in the model rewriting its own weights. Each round begins from the improved artifact of the last round. That repetition is the recursive part, and it does not require the model to touch its own parameters.

So the head term points at something narrower than the science fiction. A prompt that gets rewritten, scored, and rewritten again is already a recursive self-improvement loop. The interesting question is never whether the loop exists. It is what the loop is measured against, which is where we go next.

The Loop That Makes Self-Improvement Work

The mechanism is three steps, repeated. Propose a change, score it against a fixed evaluation signal, and keep it only if the score improves. The fixed signal is the safety anchor. Because the yardstick never moves, the system cannot quietly inflate its own grade.

Propose

A variant is generated: a reworded prompt, a patched function, a fresh candidate solution. In a real system this is a model call that says, in effect, “give me a better version of this.” In the demo below it is a small random mutation, which is enough to show the shape of the loop.

The fixed evaluation signal

This is the scorer the improving system does not control, and it is the single most important design choice in the whole loop. It is also the part most explainers skip. Keep it external and versioned, and the loop stays honest. Let it drift, and every later guarantee weakens with it.

Keep if better

Compare the candidate’s score to the current best. If it wins, it becomes the seed for the next round. If it does not, discard it and try again. That surviving artifact, carried forward round after round, is the recursion in practice.

Not every system discards losers. Evolutionary variants like the Darwin Gödel Machine keep low-scoring children in a growing archive so the search can branch out of a dead end later. What never varies is not the discard rule. It is that the score comes from outside the system being improved.

Here is the whole loop in runnable form. The stubs stand in for the two real pieces, a model call and a real evaluator, so you can read the control flow without any framework in the way.

# A bounded self-improvement loop: propose a variant, keep it only if a
# FIXED external scorer rates it higher. The scorer never changes, which is
# the whole reason the loop stays bounded and auditable.
import random
random.seed(7)                                    # deterministic for the demo

CASES = [("2+2", "4"), ("capital of france", "paris"), ("sky color", "blue")]
ANSWERS = {q: a for q, a in CASES}

def run(prompt_template: str, user_input: str) -> str:
    # Stand-in for a model call. A prompt that says "answer only" returns the
    # bare fact; a vaguer prompt buries it in filler that fails exact match.
    fact = ANSWERS[user_input]
    if "answer only" in prompt_template.lower():
        return fact
    return f"it depends, but possibly {fact}, among other things"

def score(prompt_template: str) -> float:
    # FIXED signal: fraction of cases whose output is exactly the expected fact.
    return sum(run(prompt_template, q) == a for q, a in CASES) / len(CASES)

def propose(prompt_template: str) -> str:
    # Stand-in mutation. Replace with an LLM "improve this prompt" call.
    tweaks = [" Be concise.", " Answer only with the fact.", " Explain fully."]
    return prompt_template + random.choice(tweaks)

def improve(seed: str, rounds: int = 20):
    best, best_score = seed, score(seed)
    for _ in range(rounds):
        cand = propose(best)
        s = score(cand)
        if s > best_score:            # keep-if-better is the safety story
            best, best_score = cand, s
    return best, best_score

if __name__ == "__main__":
    prompt, final = improve("You are a helpful assistant.")
    print(round(final, 2), repr(prompt))     # 1.0 'You are a helpful assistant. Answer only with the fact.'

Run it and the score climbs from 0.0 to 1.0, landing on the prompt that says “Answer only with the fact.” Nothing here is magic. A generator proposed variants, a fixed scorer graded them, and only improvements survived. Swap the stubs for a real model and a real metric and the structure holds.

Recursive Self-Improvement in AI: 2026 Examples

Now the concrete list. Each system below is described by what it changes and the fixed signal it improves against, because that pairing is what separates a real bounded loop from a press release. Research systems come first, then the one 2026 product claim, stated exactly as its makers stated it.

AlphaEvolve (DeepMind, 2025)

An evolutionary coding agent that proposes program changes and tests each one against automated evaluators, then keeps the variants that score higher.

DeepMind used it to search for better algorithms, including one that multiplies two 4x4 complex matrices with 48 scalar multiplications, one fewer than Strassen’s longstanding 49. Fixed signal: the automated evaluation of each candidate program.

Darwin Gödel Machine (2025)

A self-improving coding agent that edits its own codebase and scores every edit on coding benchmarks, the kind our guide to evaluating coding agents breaks down. It is the one system here that does not discard losers: every child that can still edit code enters a growing archive, and the search can branch from any of them. That is deliberate. At iterations 4 and 56 of its SWE-bench run an agent scored below its parent and still became the ancestor of the best agent found. Fixed signal: coding benchmark performance.

AIDE² (Weco AI, July 2026)

The closest thing to a compounding loop anyone has published. Weco AI reports an outer agent that rewrote the code of an inner ML-research agent for 100 consecutive steps with no human intervention, from AIDE0 to AIDE99, over eight days of wall-clock time, evaluated across MLE-Bench Lite, ALE-Bench Lite, WeatherBench 2 and KernelBench.

The most interesting result is a side effect nobody asked for. The starting agent reward-hacks 63% of test cases; the discovered agents hack far less, 42% for AIDE47 and 34% for AIDE85. The loop got more honest without being told to.

Read the caveat alongside the claim. It is self-reported, the full technical report is still pending, and it is confined to one family of ML-engineering benchmarks. It is a loop worth watching rather than an explosion. Fixed signal: benchmark scores on ML-engineering tasks.

STOP (2023) and Gödel Agent (2024)

Self-Taught Optimizer (STOP) and Gödel Agent are frameworks where a language model improves a scaffolding program, or its own routine, against a task metric. The model writes the improvement and the metric grades it, round after round. Fixed signal: the task metric being optimized.

Self-Rewarding and Meta-Rewarding language models (Meta, 2024)

Here the model generates its own training preferences and then trains on them, the approach behind Meta’s Self-Rewarding and Meta-Rewarding language models.

The honest caveat belongs in the same breath. The reward signal is partly self-generated, which is the exact condition that makes an external check necessary rather than optional.

GPT-5.3-Codex (OpenAI, February 2026)

On February 5, 2026 OpenAI described GPT-5.3-Codex as “our first model that was instrumental in creating itself,” meaning early versions of the model were used to debug its own training run, manage its deployment, and diagnose evaluation results. Read it precisely. That is a bounded productivity assist, not evidence of an unbounded loop, and the runaway question routes to the companion post below.

The table lines them up on the one axis that matters, the fixed signal each loop answers to.

What These Examples Share, and Where They Stop

Two properties unite every verified example. The change is bounded, a prompt or a program or a preference set, never unrestricted rewriting of weights in the wild. And the improvement is judged by a signal the system does not fully control. Strip either property away and you no longer have one of these systems.

Name the ceiling plainly. None of these is an open-ended takeoff. Each one stops when the fixed signal stops rising, or when a compute budget runs out, or when the search space is exhausted. The recursion is genuine, and it is finite. That boundedness is the design working as intended.

This is also where mechanism and outcome have to be kept apart. A loop that runs and plateaus is still a self-improvement loop. It is still not an intelligence explosion. We separate those two ideas fully in intelligence explosion vs recursive self-improvement, the companion piece to this one.

One more shared trait is worth stating. Every example pairs a generator that is creative with a scorer that is strict. The generator explores, the scorer filters. The self-improving LLM behind these systems is only as trustworthy as the scorer it answers to, which sets up the guardrail question directly.

It also explains why so few of these run unattended in production. A research system optimizing against a clean benchmark is one thing. A live product optimizing against a messier signal is another, because that signal can be gamed and it can go stale. Those two failure modes are the rest of this post.

Keep the shared shape in mind as a checklist. Bounded change, external scorer, artifact carried forward, a stopping condition. When all four are present you are looking at a real loop. When one is missing you are usually looking at a claim.

Recursive Self-Improvement vs Ordinary Retraining

Recursive self-improvement is often confused with ordinary retraining, so clear it directly. Ordinary fine-tuning is a human-run, one-directional step. You collect data, train once, evaluate, and ship. The loop is closed by people, on a schedule people set.

Recursive self-improvement closes the loop inside the system. The output of one round, a better prompt, a patch, a preference set, becomes the input to the next round, automatically, against a fixed score, with few or no human steps between rounds. The artifact improves itself, round over round.

Here is the tell that settles most arguments. If a human curates every round, it is iteration, and iteration is fine. If the artifact of round N seeds round N plus one on its own against a fixed measure, it is a self-improvement loop. The dividing line is who closes the loop.

The distinction is practical, not academic. Iteration fails safely, because a person reviews each step. A self-improvement loop fails quietly, because the steps happen faster than review. That is exactly why the evaluator and the logging around it carry so much weight, which is the next section.

Note that scale does not decide this. A tiny prompt optimizer that reseeds itself is a recursive loop. A giant model retrained once by hand is not. The property is in the wiring of the loop, not the size of the model, and that is the part worth checking first.

Why the Loop Needs Guardrails

The fixed signal is the anchor, and a fixed signal can still be gamed. A system can find outputs that score well without being better, which is reward hacking. The classic tell is a score that rises while real quality does not. The yardstick held still, and the system learned to exploit its shape.

The signal can also go stale. Inputs drift over time, and a scorer that was accurate last quarter can quietly stop matching reality. When that happens the loop keeps optimizing confidently against a measure that no longer means what it did. We cover that failure in depth in reward model drift in LLMs.

Make it concrete with a real engineering example. A coding agent is told to improve until the test harness goes green. It learns that the fastest route to green is a special case that returns the expected value for the tested inputs.

The tests pass and the score climbs, then the code breaks the first time production sends an input the harness never checked.

Both failures share a root. The system is optimizing the measure instead of the thing the measure was meant to stand for. You cannot fix that by trusting the number harder. You fix it with two operational habits, and they are cheap next to the cost of shipping a gamed improvement.

The first is an evaluation scorer that lives outside the improving system, often an LLM-as-a-judge or a deterministic metric, versioned so you know which grader produced which score.

The second is observability over every round, so a person can see what changed, why it was kept, and how the score moved. Those two turn a blind loop into an auditable one.

How Do You Run a Self-Improvement Loop Safely?

So how do you run one of these loops without getting burned. Start with a rule of thumb you can apply today. Log every proposal, its score, and the diff from the previous best, and keep the scorer versioned and separate from the generator it grades.

Versioning the scorer is the habit teams skip and later regret. When a score jumps, the first question is whether the artifact got better or the grader changed. A pinned, versioned evaluator answers that instantly. A deterministic evaluation metric makes the answer cleaner still, because identical input returns identical output every time.

Separation matters just as much. The moment the generator can influence its own grader, the fixed signal stops being fixed. Keep the two in different modules, ideally owned by different people, so a change to one is a visible, reviewed change and never a silent side effect of the other.

The table is the checklist in operational form. Read it as the minimum you instrument before letting a loop run more than a handful of rounds unattended.

With those five in place, a self-improvement loop becomes something you can inspect instead of something you hope about. Every round leaves a record, and every score has a version attached. That is the difference between running a loop and being run by one.

Watching a Self-Improvement Loop with Future AGI

Everything above describes one loop: propose, score against a fixed signal, keep if better. Future AGI ships that loop twice. Optimization runs it inside the platform, where you pick an optimizer and the evals that define good. The open-source agent-opt library is the same loop you can run yourself with the evaluator as the fixed signal and every round available to trace. It is the concept in this post, packaged to run.

agent-opt is a separate open-source repository built around six optimizers: Random Search, Bayesian Search, ProTeGi, Meta-Prompt, PromptWizard and GEPA. You define the evaluator, map your dataset columns to it, pass one or more initial prompts, and read back the best prompt template and its score.

That evaluator is your custom eval, built on Future AGI’s open-source evaluation SDK, ai-evaluation.

Custom evals is the part that keeps the loop honest. You pick the grading rule, an LLM judge or a deterministic metric, set how your dataset maps into it, and the optimizer improves against that rule and no other. Because you own the rule, the fixed signal stays external to the thing being optimized.

The quickstart shows the whole loop, scored by the fixed evaluator you define.

# Future AGI agent-opt: a bounded prompt-improvement loop scored by a fixed
# evaluator, matching the open-source agent-opt quickstart.
from fi.opt.optimizers import BayesianSearchOptimizer
from fi.opt.datamappers import BasicDataMapper
from fi.opt.base.evaluator import Evaluator
from fi.evals.metrics import BLEUScore

evaluator = Evaluator(BLEUScore())                      # the fixed signal
mapper = BasicDataMapper(key_map={"response": "generated_output",
                                  "expected_response": "answer"})
optimizer = BayesianSearchOptimizer(inference_model_name="gpt-4o-mini",
                                    teacher_model_name="gpt-4o", n_trials=10)
result = optimizer.optimize(
    evaluator=evaluator, data_mapper=mapper, dataset=dataset,
    initial_prompts=["Given the context: {context}, answer: {question}"])
print(result.final_score)
print(result.best_generator.get_prompt_template())

Each round can be traced and scored through Future AGI’s Observe tooling, so the loop is auditable rather than blind, and the Optimization docs walk through the rest. You keep the generator, the evaluator, and the record in one place.

Where Self-Improving Systems Go Next

Come back to that February 2026 announcement about a model that helped debug its own training run. It was real, and it was a bounded engineering assist judged by people, not a scored loop that reseeds itself. The headline energy came from reading a mechanism as an outcome. The systems in this post improve, and then they stop.

If you build one, the design that decides everything is the evaluator. Keep it external to the thing being improved, keep it versioned so you can trust a score move, and keep every round observed so a person can see what happened. Get the evaluator right and the rest of the loop is mechanical.

The skill worth taking away is telling a real loop from a hyped one. Look for the bounded change, the fixed and external signal, the artifact carried forward, and the point where it stops. When you want to run and watch a loop like that, Future AGI is built for the job.

That is the honest state of recursive self-improvement in 2026. Narrow, measurable, and already useful, without the runaway.