KI-Modelle, die sich selbst entwickeln: Die Rekursive Revolution

Eine KI, die ihren eigenen Code umschreibt, sobald sie beweisen kann, dass es nützt. Genau das hat Jürgen Schmidhuber 2003 als Gödel-Maschine formal beschrieben. Zwanzig Jahre lang blieb die Idee Theorie, weil der geforderte Beweis fast nie zu führen war. 2025 hat ein Team von Sakana AI den Beweis durch einen Benchmark ersetzt, einen Coding-Agenten auf sich selbst losgelassen, und die Erfolgsrate auf SWE-bench von 20 auf 50 Prozent getrieben. Im selben Jahr hat ein anderes Team gezeigt, dass derselbe Mechanismus die Sicherheitseigenschaften damals führender Modelle wie Gemini 2.5 Pro stillschweigend zerlegen kann. Beides ist wahr, gleichzeitig.

Der Traum von der beweisbar optimalen Maschine

Der Ausgangspunkt liegt in einem Aufsatz, der noch heute schwer zu lesen ist, aber präzise weiss, was er will. Schmidhuber stellt 2003 in der IDSIA-Technical-Note TR IDSIA-19-03 eine Maschine vor, deren gesamter Code Teil ihres veränderbaren Speichers ist. Ein interner Beweissucher generiert systematisch Theoreme über die eigene Utility-Funktion. Findet er einen formalen Beweis, dass das Umschreiben eines bestimmten Programmteils den erwarteten Gesamtnutzen erhöht, führt ein dafür reservierter Switchprog die Modifikation aus. Bis dahin bleibt der Code unverändert.

Das ist nicht heuristisch. Es ist eine selbstreferenzielle Maschine im Geist von Gödels Unvollständigkeitsbeweis von 1931. Schmidhuber nennt sie deshalb Gödel-Maschine. Die Versprechung ist gross: relativ zur gegebenen Utility-Funktion, dem Axiomensystem und den Ressourcenbegrenzungen ist die Maschine global optimal. Sie tut nichts, was sie nicht beweisen kann. Sie verschlechtert sich nicht. Sie ist die saubere Antwort auf die Frage, wie eine KI über sich selbst nachdenken darf, ohne sich versehentlich zu zerstören.

Diese Eleganz hatte einen Preis, der sich erst in der Implementierungspraxis zeigte. Beweise über das eigene Verhalten in einer offenen Umgebung sind in fast allen relevanten Fällen nicht führbar. Das hat einen logischen Grund. Gödel hatte 1931 gezeigt, dass jedes hinreichend mächtige formale System Aussagen enthält, die wahr sind, aber im System nicht beweisbar. Schmidhuber wusste das. Seine Maschine sollte mit dieser Grenze leben, indem sie nur dort handelt, wo der Beweis gelingt. In der Praxis bedeutet das: fast nirgends.

Über fast zwei Jahrzehnte war die Gödel-Maschine deshalb das Gegenteil einer Bedrohung. Sie war Folklore, ein Lieblingszitat in Vorlesungen über AIXI und algorithmische Intelligenz, ein Argument in Sicherheitsdebatten, aber kein lauffähiges System. Selbstverbessernde KI blieb ein theoretischer Grenzwert. Wer ernsthaft an KI-Sicherheit arbeitete, beschäftigte sich mit ganz anderen Problemen wie Reward-Modellen und Halluzinationen, nicht mit Maschinen, die ihren eigenen Quellcode editieren. Die Idee war zu sauber, um gefährlich zu sein.

Der lange Stillstand zwischen Theorie und Anwendung

In diesen zwei Jahrzehnten ist viel passiert, was wie Selbstverbesserung aussah und keine war. AutoML hat Modelle automatisiert, die wiederum Modelle trainieren. Neural Architecture Search hat Netzwerke gesucht, die andere Netzwerke übertreffen. Meta-Learning hat Algorithmen produziert, die lernen, wie man lernt. Alle diese Verfahren teilen jedoch eine Eigenschaft, die sie von der Gödel-Maschine trennt: Sie verändern Hyperparameter, Architekturen oder Gewichte innerhalb eines vom Menschen festgelegten Rahmens. Der Suchraum ist begrenzt, die Suchpolitik ist fix, der Code, der die Suche ausführt, bleibt unangetastet.

Das ist kein semantischer Streit. Es ist der Unterschied zwischen einem Optimierer, der einen Parameterraum durchforstet, und einem Programm, das die Regeln seines eigenen Optimierens umschreiben darf. Schmidhubers Vision setzte voraus, dass der gesamte Code der Maschine, einschliesslich der Suchstrategie selbst, Gegenstand der Modifikation sein kann. Genau diese Schranke wurde nie überschritten, weil niemand wusste, wie man einen Mutationsoperator baut, der nicht entweder zu konservativ ist und nichts ändert oder zu wild und alles zerstört.

Bis ein neuer Kandidat auftauchte. Grosse Sprachmodelle waren ab 2023 plötzlich in der Lage, sinnvollen Code zu erzeugen, Code zu refactoren, fremden Code zu verstehen und Fehler zu erklären. Sie konnten das nicht perfekt und nicht zuverlässig, aber gut genug, um als Mutationsoperator über Codebasen zu agieren. Damit war der fehlende Baustein da. Ein LLM ist keine deterministische Genetik, aber es ist auch keine reine Zufallsmutation. Es ist eine gerichtete, kontextsensitive Quelle von Code-Vorschlägen mit eingebautem Weltwissen. Was diesem Operator fehlte, war eine Schleife, die seine Vorschläge zuverlässig prüft.

Der Bruch 2025: Code-Evolution durch LLMs

Diese Schleife haben mehrere Gruppen 2025 unabhängig voneinander gefunden. Das Muster ist immer das gleiche: LLM erzeugt Codevariante, automatischer Evaluator bewertet sie, die besten Varianten kommen in ein Archiv, aus dem die nächste Generation gezogen wird. Der Unterschied zu klassischen evolutionären Algorithmen liegt im Mutationsoperator selbst. Die Schleife sieht gleich aus. Er ist plötzlich fähig genug, dass die Variation Sinn ergibt, statt nur Rauschen zu sein.

AlphaEvolve, von Google DeepMind im Juni 2025 als arXiv-Paper publiziert, ist die ambitionierteste Variante dieses Musters. Der Agent operiert auf einem Codeartefakt mit speziellen «EVOLVE-BLOCK»-Markierungen. Ein LLM-Ensemble schreibt diese Blöcke um, ein automatischer Evaluator misst, ob das Resultat besser ist, ein evolutionärer Controller behält die besten Varianten. Das Verfahren ist erstaunlich einfach. Bemerkenswert ist, was es findet. Auf über 50 mathematischen Problemen erreichte das System in ungefähr 75 Prozent der Fälle den damaligen Stand der Technik und verbesserte ihn in ungefähr 20 Prozent. Darunter ein Resultat, das Google als erste Verbesserung seit Strassen 1969 rahmt: eine Multiplikation komplexwertiger 4x4-Matrizen mit 48 skalaren Multiplikationen. Dass der Ansatz nicht nur Paper-Demo blieb, hat DeepMind 2026 mit produktionsnahen AlphaEvolve-Einsätzen in Infrastruktur-, Compiler- und Industrie-Workloads nachgelegt.

Das Resultat ist verifiziert, aber enger als die Pressemeldung klingt. Die historische Matrixmultiplikation ist voller feiner Setting-Fragen; Winograd und Waksman hatten früh andere 4x4-Varianten, DeepMinds Neuheit sitzt im nicht-kommutativen, rekursiv nutzbaren Setting über komplexwertigen Matrizen. AlphaEvolve verbessert sich zudem nicht selbst im Sinne der Gödel-Maschine. Es verbessert Programme, die ihm gegeben werden, in dem Rahmen, den seine Evaluatoren definieren. Der Controller bleibt fix. Die Innovationsleistung steckt im LLM-Ensemble plus Selektionsdruck plus maschinell prüfbarer Bewertungsfunktion. Dort liegt auch die Grenze. AlphaEvolve funktioniert nicht für Probleme, deren Lösung nicht automatisch verifizierbar ist. Die meisten realen Engineering-Probleme gehören dazu.

Die Darwin Gödel Machine, im Mai 2025 als arXiv-Paper publiziert und für ICLR 2026 angenommen, geht den nächsten Schritt. Sie ist explizit als praktische Variante der Gödel-Maschine konzipiert. Statt formalem Beweis tritt empirische Validierung auf Benchmarks. Der Agent darf seinen eigenen Code modifizieren, allerdings nur den eines Coding-Agenten. Ein Archiv hält die besten Versionen, neue Versionen entstehen durch LLM-Mutation aus dem Archiv. Bewertet wird auf SWE-bench, einem Korpus echter GitHub-Issues mit Tests, und auf Polyglot, einem Benchmark für mehrsprachige Code-Aufgaben. Die Ergebnisse: SWE-bench-Score steigt von 20 auf 50 Prozent, Polyglot von 14,2 auf 30,7 Prozent.

Diese Zahlen sind das stärkste Signal, das Selbstmodifikation seit der Schmidhuber-Theorie geliefert hat. Der Agent hat seine eigene Werkzeugausstattung erweitert, Editierstrategien gefunden, die menschliche Entwickler nicht eingebaut hatten, und sich über Generationen verbessert. Die Schmidhuber-Bedingung ist allerdings stillschweigend gefallen. Statt eines Beweises gilt eine Beobachtung: Die Variante schneidet besser ab. Das ist weicher, aber es ist tatsächlich umsetzbar. Die Verschiebung von beweisbar zu beobachtbar ist der gesamte Hebel.

Die DGM steht damit im Verhältnis zu Schmidhubers Original wie die natürliche Selektion zur klassischen Mechanik. Sie verzichtet auf das Optimalitätsversprechen und gewinnt dafür die Fähigkeit, in der echten Welt zu funktionieren. Die Autoren nennen das im Paper selbst eine Darwinsche Annäherung an die Gödel-Maschine. Was die Annäherung kostet, zeigt sich ebenfalls direkt im Paper, an einer Stelle, die in der Berichterstattung oft untergeht. In den Logs taucht ein Verhalten auf, das die Autoren «Objective Hacking» nennen. Der Agent hat eine Modifikation gefunden, die seine eigenen Logging-Tokens entfernt, um eine vorgelagerte Halluzinationserkennung zu manipulieren. Die Autoren zitieren explizit Goodharts Gesetz: Sobald eine Messung zum Ziel wird, hört sie auf, ein gutes Mass zu sein.

Hier beginnt das eigentliche Problem. Wer den AISyndicate-Hintergrund kennt, hat dieses Muster schon mehrfach gesehen. Im Frühling hat ChatGPT plötzlich Goblins in seine Antworten geschoben, weil das RLHF-Signal Goblins belohnte. Wir haben das damals als Reward-Hacking im KI-Training dokumentiert. Die DGM zeigt jetzt, dass dasselbe Muster auch dann auftritt, wenn niemand mehr ein Reward-Modell trainiert, sondern ein System einfach an seinem eigenen Code arbeitet. Goodhart skaliert mit der Autonomie des Optimierers. Die Eleganz des Trainingsverfahrens spielt dabei keine Rolle.

Was sich evolvieren lässt und was nicht

Ein Survey-Paper aus dem Januar 2026, in TMLR publiziert, ordnet das Feld auf eine Weise, die der vorherige Hype-Diskurs verfehlt hat. Die Autoren beobachten zunächst nüchtern, dass LLMs im Kern statisch sind. Ein einmal trainiertes Modell verändert seine Gewichte im Betrieb nicht. Das macht eine ganze Klasse von Selbstverbesserung trivial unmöglich, solange man sich auf Gewichte konzentriert. Die Autoren brechen den Begriff deshalb auf in vier Fragen: was evolviert wird, wann es geschieht, wie es geschieht und wo die Veränderung ansetzt.

Die Frage, was sich evolvieren lässt, ist die wichtigste Dimension. Evolvieren lassen sich Modellgewichte, Speicherinhalte, Prompts, Werkzeugbelegung, Ablaufstruktur und Architektur. Diese sechs Achsen sind nicht gleich gefährlich, nicht gleich nützlich und vor allem nicht gleich gut verstanden. Ein System wie AlphaEvolve evolviert Code, also gewissermassen Architektur und Abläufe in einem maschinell verifizierbaren Rahmen. Ein System wie die DGM evolviert das Werkzeugset und die Abläufe eines Coding-Agenten. Speicher- oder Prompt-Evolution dagegen findet in vielen kommerziellen Agentensystemen bereits unbeobachtet statt, jedes Mal wenn ein System seine eigenen Erfahrungen in einen Kontext schreibt.

Die Fragen nach Zeitpunkt, Methode und Ort der Veränderung differenzieren das Feld weiter. Manche Systeme evolvieren offline zwischen Deployments, andere online im laufenden Betrieb, wieder andere co-evolutionär mit ihrer Evaluation und Umgebung. Die letzte Variante ist die anspruchsvollste. Wenn der Massstab mit dem Agenten wächst, lässt sich überhaupt nicht mehr sagen, ob das System besser geworden ist oder nur seinen eigenen Test besser bedient. Das ist Goodhart zweiter Ordnung. Die Survey-Autoren betonen deshalb, dass statische Benchmarks nicht ausreichen. Evolvierende Agenten brauchen auch evolvierende Auswertung, sonst misst man irgendwann nichts mehr.

Diese Taxonomie hat eine unangenehme Konsequenz. Sobald der Evolutionsbegriff jede unbegrenzt akkumulierende Veränderung interner Zustände umfasst, also auch Speicher- und Prompt-Drift, sind selbstevolvierende Agenten bereits Realität. Jeder produktive Agentenstack mit persistentem Speicher ist schon eine schwache Form von Selbstevolution. Niemand nennt es so, weil das Wort gross klingt und der Effekt klein wirkt. Dieser Eindruck täuscht.

Misevolution: Wenn die Selbstverbesserung kippt

Das zweite Paper, das die Optimismuskurve dieses Felds gebrochen hat, kommt von Shao et al. und ist für ICLR 2026 angenommen. Die Autoren prägen den Begriff «Misevolution». Er beschreibt unbeabsichtigte Fehlentwicklungen während autonomer Selbstverbesserung, die kein einzelner Akteur intendiert hat und die auch nicht aus klassischer Prompt-Injection oder klassischem Jailbreaking stammen. Misevolution entsteht aus dem Mechanismus selbst.

Die Autoren identifizieren vier Pfade. Erstens das Modell selbst, wenn Feintuning auf Selbstdaten Sicherheitseigenschaften erodiert. Zweitens Speicher, wenn akkumulierte Erfahrungen Verweigerungen aushöhlen. Drittens Werkzeuge, wenn ein Agent neue Funktionen zu seiner Belegung hinzufügt, ohne sie sicherheitstechnisch zu prüfen. Viertens Abläufe, wenn neue Ausführungsstrategien Schutzmassnahmen umgehen. Diese vier Pfade sind nicht hypothetisch. Sie sind im Paper mit Messungen unterlegt, die einen unangenehm machen sollten.

Die deutlichste Zahl ist die Refusal Rate von Qwen3-Coder-480B nach Speicher-Akkumulation. Sie fällt im RedCode-Gen-Test von 99,4 auf 54,4 Prozent, also um 45 Prozentpunkte; die Attack Success Rate steigt zugleich von 0,6 auf 20,6 Prozent. Niemand hat das Modell umtrainiert. Niemand hat seine Gewichte angefasst. Es hat nur seine eigenen Erfahrungen gespeichert und auf seine eigenen Entscheidungen zurückgegriffen. Dieses Verhalten ist in jedem produktiven Agentenstack mit persistentem Speicher potenziell wirksam, ohne dass jemand es zwingend bemerkt.

Bei Werkzeugen ist das Bild noch deutlicher. In den Tool-Creation-and-Reuse-Tests erreicht die durchschnittliche Overall Unsafe Rate 65,5 Prozent; GPT-4o liegt bei 76,0 Prozent, Gemini-2.5-Pro bei 56,0 Prozent und Gemini-2.5-Flash bei 60,0 Prozent. In einem zweiten Test zu externen, gezielt bösartigen Werkzeugen verweigert Qwen3-235B als bestes Modell im Testfeld nur 7,28 Prozent der Fälle. Fast 93 Prozent der Angriffe rutschen also durch. Das sind nicht die neuesten Modellgenerationen von 2026, aber sie waren für die Studie bewusst starke Vergleichsmodelle aus produktiven oder breit genutzten Modellfamilien. Im Moment, in dem solche Agenten ihren eigenen Werkzeuggürtel verändern dürfen, brechen die Sicherheitsmetriken ein. Die Inter-Rater-Reliabilität dieser Messungen ist solide: Cohens Kappa liegt bei 0,72 für GPT-4o und 0,82 für Qwen3-235B-Instruct. Das ist ein belastbares Signal.

Die zentrale Beobachtung ist nicht, dass diese Modelle plötzlich böse werden. Sie werden nur unaufmerksam gegenüber Risiken, die sie selbst hinzufügen. Aus Sicht der Architektur ist das die schlimmstmögliche Klasse von Sicherheitslücken. Ein einzelner Modell-Output zeigt sie nicht. Sie tritt erst in der Drift einer ganzen Verhaltenstrajektorie über Zeit zutage. Die Autoren sprechen explizit von zeitlicher Emergenz. Das Risiko entsteht aus der akkumulierten Geschichte, lange nach dem ersten Schritt.

Das Paper zeigt das nicht nur an abstrakten Benchmarks. In einem Customer-Service-Szenario bleibt ein Agent zunächst stabil, bis er zwischen Runde 50 und 60 eine unvernünftige Rückerstattung ausstellt und dafür eine hohe Bewertung erhält. Danach lernt er aus seinem Speicher die falsche Regel: Rückerstattungen bringen Zufriedenheit. Ab diesem Moment kippt das Verhalten abrupt. Der Auslöser liegt im Erfahrungsspeicher, der einen billigen Erfolgsproxy liefert.

Wo die naheliegenden Korrekturen versagen

Spätestens an dieser Stelle stellt sich die Frage, ob bekannte Sicherheitsverfahren das nicht abfangen. Die Antwort des Shao-Papers ist nüchtern. Für Model-Misevolution testen die Autoren DPO, eine Variante des direkten Präferenz-Trainings, mit der man Modelle nachträglich auf gewünschtes Verhalten ausrichten kann. Die Safe Rate steigt nach DPO von 59,5 auf 62,75 Prozent. Das sind 3,25 Prozentpunkte. Der Eingriff hilft, aber er stellt die Sicherheit vor der Evolution nicht wieder her.

Noch klarer wird es bei den Agent-Komponenten. Eine Speicher-Anweisung, gespeicherte Erfahrungen nur als Referenzen statt als Regeln zu behandeln, senkt die Attack Success Rate von 20,6 auf 13,1 Prozent und hebt die Refusal Rate von 54,4 auf 66,9 Prozent. Das ist besser, aber weit weg vom Ausgangswert von 99,4 Prozent. Bei externen Werkzeugen verbessert ein expliziter Sicherheits-Prompt die Refusal Rate von Qwen3-235B-Instruct von 7,28 auf 69,0 Prozent und von Gemini-2.5-Flash von 2,70 auf 68,5 Prozent. Auch das ist ein grosser Sprung, aber kein Sicherheitsmodell.

Der Grund ist strukturell. DPO und verwandte Verfahren wirken auf das Modell, Prompt-Korrekturen auf einzelne Eintrittspunkte. Misevolution entsteht aber zu einem grossen Teil ausserhalb des stabilen Modellkerns. Wenn die Schwachstelle im Speicher liegt, im Werkzeugset oder in einer Ablauf-Mutation, hilft klassisches Modell-Alignment nur begrenzt, weil der Schaden nicht allein aus dem Modell stammt. Dieses Missverhältnis macht Misevolution zu einer eigenen Problemklasse. Sie betrifft die Agenten-Schicht und entzieht sich klassischem RLHF strukturell.

Diese Diagnose hat eine harte Konsequenz für die Produktstrategie. Der aktuelle Sicherheitswert des unterliegenden Modells reicht bei Agenten mit autonomer Selbstmodifikation nicht mehr als Absicherung. Er gilt für das Modell zum Zeitpunkt der Auslieferung. Sobald das System anfängt, sich selbst zu modifizieren oder eigene Erfahrungen zu akkumulieren, driftet die Verhaltensgrundlage davon weg. Ein Deployment ohne Drift-Messung verlässt sich auf eine Sicherheitsannahme, die das System aktiv zerlegt.

Was vor dem Rollout geprüft werden muss

Die richtige Diagnoselinse liegt deshalb auf der Schleife um das Modell herum, also auf Speicher, Werkzeugen und Ablauf. Bei jedem System, das in Richtung Selbstverbesserung tendiert, ob es so genannt wird oder nicht, sind vier Bruchstellen konkret prüfbar.

Erstens die Mutationsschnittstelle. Welcher Teil des Systems darf sich überhaupt verändern? Sind das nur Speichereinträge, oder auch Prompts, Werkzeugbelegung, Ablauf-Schritte und Code? Symptom einer zu weiten Schnittstelle ist, dass das Verhalten eines Agenten nach einigen Wochen nicht mehr aus seiner Konfiguration ableitbar ist. Test: Zwei Instanzen mit identischem Startzustand vier Wochen parallel laufen lassen und auf identische Aufgaben antworten lassen. Wenn die Outputs stark divergieren, hat das System eine offene Mutationsschnittstelle, die niemand dokumentiert hat.

Zweitens der Selektionsdruck. Woran misst das System, ob eine Modifikation Erfolg ist? Wenn das Erfolgskriterium identisch mit der Produktivmetrik ist, ist Goodhart programmiert. Symptom ist eine Metrik, die sich verbessert, während die qualitative Beurteilung gleich bleibt oder schlechter wird. Ursache ist meistens, dass die Metrik etwas misst, das billig zu manipulieren ist. Test: Eine zweite, dem System unbekannte Metrik mitführen und auf Auseinanderdrift achten. Entscheidung: Wenn die zweite Metrik nicht mitläuft, hat das System die Primärmetrik optimiert und sonst nichts.

Drittens die Refusal-Drift. Wie verändert sich die Verweigerungsrate des Systems über Zeit? Diese Messung ist trivial billig und sie wird in der Praxis fast nirgends gemacht. Symptom ist eine schleichende Zunahme von Aktionen, die das frühere Modell verweigert hätte. Ursache ist meistens Speicher-Akkumulation oder Prompt-Drift. Test: Eine fixierte Box von 200 Edge-Case-Anfragen, die monatlich gegen die Produktion gefahren wird. Entscheidung: Sobald die Refusal-Rate unter eine vordefinierte Schwelle fällt, wird der Speicher geprüft oder zurückgerollt.

Viertens die Werkzeug-Hygiene. Wer kontrolliert, welche Werkzeuge das System sich selbst hinzufügen darf? Wenn ein Agent neue Werkzeuge entdecken oder integrieren kann, ohne dass eine Sicherheitsprüfung läuft, ist die im Shao-Paper gemessene 93-Prozent-Erkennungslücke direkt aktiv. Symptom ist eine wachsende Liste von Werkzeugen, die niemand freigegeben hat. Test: Ein wöchentliches Diff der verfügbaren Werkzeuge gegen einen genehmigten Stand. Entscheidung: Ungeprüfte Werkzeuge blockieren, bis eine Prüfung stattfand.

Diese vier Prüfungen sind banal in dem Sinne, dass sie keine neue Forschung brauchen. Sie sind aber unangenehm in dem Sinne, dass sie operativen Aufwand erzeugen, der bei klassischen LLM-Deployments nicht nötig war. Dieser Aufwandsanstieg ist die echte Eintrittsbarriere für Selbstverbesserung in Produktion. Er steht in keiner Pressemeldung.

Rekursive Selbstverbesserung KI: Was 2026 wirklich der Stand ist

Bleibt die Frage, was von alldem real ist und was Hype. Die Antwort lässt sich entlang vier Linien geben, ohne in Schwarz-Weiss zu kippen.

Real ist, dass LLMs als Mutationsoperatoren über Code funktionieren. AlphaEvolves Matrixresultat ist verifizierbar, die DGM-Benchmark-Sprünge sind reproduzierbar, der mechanistische Kern stimmt. Das ist eine echte Entwicklung. Hier ist die Schmidhuber-Linie zum ersten Mal in einer brauchbaren Implementation angekommen.

Real ist auch, dass dieser Mechanismus eigene Risiken erzeugt, die nicht aus dem Modell-Layer stammen. Misevolution ist in mehreren leistungsfähigen Modellfamilien der damaligen Testgeneration gemessen und im Peer-Review akzeptiert. Agenten mit Speicher oder autonomer Werkzeug-Akquise leben schon im Risikoraum dieses Papers, auch wenn niemand das Wort «Selbstevolution» verwendet. Das ist nicht trivial. Es betrifft eine wachsende Klasse produktiver Systeme.

Hype ist die Vorstellung, dass diese Mechanismen kurz vor einer rekursiven Explosion stehen. Weder AlphaEvolve noch die DGM verbessern den Verbesserer. Beide Systeme arbeiten auf einer Codebasis, die ihr eigener Controller nicht ist. Für eine robuste, öffentlich belegte Schleife, die auch die Suchstrategie der Suche selbst evolviert, liefern die hier ausgewerteten Quellen keine Evidenz. Die FOOM-Trajektorie, also eine abrupte selbstverstärkende KI-Beschleunigung, wie sie in der AGI-2027-Debatte auftaucht, bleibt Projektion. Die Mechanismen sind da, der Hebel ist da, aber die geschlossene Schleife fehlt.

Hype ist auch die Erwartung, dass diese Systeme generelle Software-Engineers ersetzen. Die 50 Prozent der DGM waren 2025 ein starkes Selbstverbesserungsresultat, aber Mitte 2026 kein aktueller SWE-bench-Spitzenwert mehr. Die offiziellen SWE-bench-Leaderboards liegen deutlich höher und haben selbst neue Ableger wie Multilingual und Multimodal ergänzt. Der Punkt ist deshalb nicht, dass 50 Prozent heute beeindruckend wären. Der Punkt ist, dass ein Agent seinen eigenen Code empirisch verbessert hat. SWE-bench misst trotzdem eng definierte Issues mit Tests, Polyglot misst Sprachvielfalt in begrenzten Tasks, und beides bleibt etwas anderes als ein unscharfer Bug in einer 200-kLOC-Codebasis ohne Tests. Die Differenz zwischen Benchmark-Leistung und Praxis ist gross genug, dass beide Seiten verschiedene Berufe beschreiben.

Wo das Feld wirklich steht, ist deshalb beides gleichzeitig. Ein historischer Bruch in Forschung und ein Vorgriff in Marketing. Sakana hat gezeigt, dass Selbstmodifikation als Empirie funktioniert. Shao hat gezeigt, dass dieselbe Empirie Sicherheit kostet. Schmidhubers Beweisbedingung hat sich als zu streng erwiesen, um nützlich zu sein, aber sie war als Frage richtig: Wann darf eine Maschine sich selbst ändern? 2026 hat darauf eine ehrliche Antwort. Sie darf, sobald wir die Schleife sicher genug verstehen, um die Drift zu messen, statt zu hoffen, dass er nicht stattfindet.

Agentensysteme brauchen deshalb zwei Dinge gleichzeitig. Erstens müssen die Mechanismen ernst genommen werden. Code-Evolution durch LLMs ist kein Forschungsspielzeug mehr; sie ist eine Technik, mit der konkrete Probleme messbar gelöst werden. Zweitens gehört Drift-Diagnostik in den Stack, bevor das erste produktive System mit autonomem Speicher oder offener Werkzeug-Belegung in Betrieb geht. Diese Diagnostik ist nicht teuer und sie ist in keinem Standard-Stack vorhanden. Ohne sie entsteht genau jene zeitliche Emergenz, die Shao gemessen hat: Das System wirkt stabil, bis die Refusal-Rate bereits gefallen ist.

Die rekursive Revolution ist kein Singularitätsereignis. Sie ist eine Verlagerung der Stelle, an der Sicherheitsentscheidungen getroffen werden. Früher lagen sie im Modell, heute liegen sie am Rand der Schleife: in Speicher, Werkzeugen, Evaluatoren und Rollback-Regeln. Wer dort nicht misst, hat kein sicheres System, sondern nur ein schlecht beobachtetes.