Letting AI Improve Itself: A 97-Page Survey Maps the Field

AI improving AI has been an active practice for three years: agents reviewing their own mistakes, generating their own practice problems, rewriting their own toolboxes. Hundreds of papers have accumulated under scattered terminology. In mid-July, a 97-page survey organized it all into a single map. The first author is from Jilin University, with KAUST as corresponding institution — and the last author is Jürgen Schmidhuber, who proposed "networks modifying networks" back in the 1990s, the field's longest-standing original advocate.

One Notation Unifies the Chaos

The survey's contribution in one sentence: it establishes a coordinate system for "AI improving AI."

It first decomposes an agent into two things: the base model underneath (parameters — a fixed set of weights), and the operational scaffold outside it (prompts, memory, tools, control logic). Then it gives a unified formalization: self-improvement is an agent-initiated update operator that commits modifications to one of these two components.

The notation is plain: parameters go from θt to θt+1, the scaffold from Σt to Σt+1. But these two arrows hang all the scattered work since 2023 on one wall: prompt editing, memory editing, tool editing, code editing, weight fine-tuning — all are update operators, differing only in target.

Two major branches subdivide further. The parameter route: the model generates its own training data (intrinsic demonstrations), scores itself (intrinsic feedback), or accumulates experience by interacting with the environment (external experience). The scaffold route: prompt optimization, memory read/write, tool self-construction, and the most radical — rewriting its own entire runtime code.

This taxonomy looks simple but is a potentially life-saving map. When you encounter a new system claiming to be "self-evolving," ask first: does it modify parameters or the scaffold? The former requires retraining, is costly, and affects everything globally; the latter can be rolled back anytime it breaks. The engineering properties of the two directions are entirely different — conflating them means talking past each other.

Schmidhuber's Thirty Years

Chapter 2 is a history, from 1790s automata to today. The interesting part is why this thread ends with Schmidhuber: in 1992 he demonstrated "fast weights" — one network learning to program another; in 1993 he built a self-referential system capable of modifying itself; in the early 2000s, he and Hochreiter (the other LSTM author) explored systems discovering their own learning algorithms.

In other words, "AI improving AI" is not a post-2023, post-GPT invention — it is an old thread that has lived intermittently for over thirty years. Large language models merely turned it from laboratory theory into an engineering reality running in the cloud daily. Every product today that lets an agent edit its own prompts sits on the extension of this line.

The applications chapter covers six domains: software engineering, web automation, game strategy, scientific discovery, embodied robotics, and general computer operation. Each is a local version of the same loop: work, review, improve, repeat.

The Survey's Own Three Judgments

What's truly worth reading is Chapter 9, where the authors step beyond literature review to offer three judgments of their own.

First, fast exploration and slow consolidation should be layered. Scaffold modification is the fast loop: editing a prompt costs nearly nothing, and reverting a bad change is trivial. Parameter modification is the slow loop: once something bad is distilled into the weights, tracing which update caused a problem is notoriously hard. Their recommendation: when environmental feedback is noisy, tinker only at the scaffold layer first; only after execution tests repeatedly validate effectiveness should you consider consolidating into parameters. Don't mix the fast and slow layers.

Second, the reviewer is attacked infrastructure, not a scoring tool. An agent optimizing any metric has a natural incentive to find shortcuts. The survey's language is heavy: a reviewer embedded in the closed loop is an attack surface. An agent's capability ceiling is usually set by how reward-hack-resistant its reviewer is. So the party proposing improvements and the party accepting them must be separated — the reviewer may evolve, but not under the control of the agent it evaluates — like letting exams get harder, but never letting the test-takers write the questions.

Third, self-improving agents should be treated as untrusted code. Alignment research has an old hard problem: how can a weaker system supervise a stronger successor? The survey identifies the highest-risk configuration as full-scaffold improvement — an agent modifying its own source code — where a single ordinary prompt injection could be consolidated into a permanent architectural-level vulnerability. So safety cannot rely solely on the initial training alignment; it requires layered gates, with a checkpoint at every layer of update.

The Map and Its Readers

Taken together, the three judgments point to the same thing: the key to self-improvement is not "can it change" but "who accepts the change and how it can be rolled back." This is fully isomorphic to decades of software engineering experience — no one lets unreviewed code straight into production; it's just that this time, both the coder and the reviewer are no longer human.

A companion GitHub repository maintains the paper list, with 571 stars and still updating today. The paper went live on July 14 — just three months old this month — with 25 citations already, a decent pace for a survey.

If one sentence must summarize: this survey invented no new technique. What it did is more fundamental — it sorted a wildly growing field along two axes: "what is modified" and "by what signal." From now on, whenever you see any system claiming to be self-evolving, ask these two questions and its position on the map becomes clear.

---

*Sources: arXiv 2607.13104 (2026-07-14; Jilin University × KAUST × Alberta × IDSIA; Zhe Ren first author, Schmidhuber last author); companion repo selfimproving-agent/Awesome-Self-Improving-Agents (571★); citation count from Google Scholar (2026-10 snapshot). 97 pages refers to the PDF layout.*