Wenn KI die nächste KI trainiert

"Selbstverbesserung" steht inzwischen in jeder zweiten Modellankündigung. Der Begriff meint dabei selten dasselbe, und die Spanne ist groß: Mal ist ein Trainingskreislauf gemeint, in dem zwei Modelle sich gegenseitig hochziehen, mal ein System, das seinen eigenen Nachfolger baut. Das erste gibt es. Das zweite nicht.

Für den Arbeitsalltag ist die Unterscheidung wichtiger, als sie klingt. Wer eine Ankündigung falsch liest, überschätzt entweder das Risiko oder die Reife eines Werkzeugs, das gleich im eigenen Stack landen soll. Dieser Artikel sortiert, was heute wirklich läuft, was die Anbieter selbst einräumen, und woran du eine echte Schleife von einer behaupteten unterscheidest.

Was die Industrie selbst vorrechnet

Die ehrlichste Zahlensammlung kommt von Anthropic, weil sie interne Daten offenlegt und die eigenen Einschränkungen gleich mitliefert. In When AI builds itself steht der Stand vom Juni 2026:

• Seit Mai 2026 stammen über 80 Prozent des Codes, der in Anthropics Codebasis gemerged wird, von Claude. Vor dem Start von Claude Code im Februar 2025 lag der Wert im niedrigen einstelligen Bereich.
• Im zweiten Quartal 2026 merged ein typischer Entwickler dort achtmal so viel Code pro Tag wie 2024.
• Im April 2026 hat Claude über 800 Fixes ausgeliefert, die eine Klasse von API-Fehlern um den Faktor tausend reduziert haben. Der betreuende Entwickler schätzte den menschlichen Aufwand dafür auf vier Jahre.

Bemerkenswert ist, wie Anthropic diese Zahlen selbst relativiert. Zu den achtfachen Codezeilen schreiben sie, das sei "almost certainly an overstatement of the true productivity gain", weil Codezeilen ein reines Mengenmaß sind. Zu einer internen Umfrage unter 130 Mitarbeitenden, in der der Median eine Vervierfachung des eigenen Outputs schätzte, heißt es, die tatsächliche Steigerung sei vermutlich niedriger gewesen. Das ist keine Marketingseite, das ist eine Argumentation mit offenen Flanken.

Von außen passt das Bild dazu. METR misst, wie lange eine Aufgabe sein darf, die ein Modell noch zuverlässig allein zu Ende bringt. Dieser Zeithorizont verdoppelt sich laut Anthropics Auswertung inzwischen etwa alle vier Monate statt alle sieben. Im März 2024 schaffte Claude Opus 3 Aufgaben von rund vier Minuten, ein Jahr später waren es bei Sonnet 3.7 etwa anderthalb Stunden, ein weiteres Jahr später bei Opus 4.6 zwölf Stunden.

Und trotzdem steht in derselben Veröffentlichung der entscheidende Satz: "We are not there yet, and recursive self-improvement is not inevitable." In Anthropics eigener Zeitleiste trägt der Schritt "Closing the loop" die Jahreszahl "20XX?".

Zwei Bauarten, wie KI heute KI trainiert

Hinter dem einen Begriff stecken zwei ziemlich verschiedene Konstruktionen. Beide sind real und beide laufen produktiv, aber sie schließen unterschiedliche Teile der Schleife.

flowchart TB
  S1(["Self-Play"]) ---> S2("Angreifer und Verteidiger<br/>treten gegeneinander an")
  S2 ---> S3("Beide Seiten<br/>werden trainiert")
  S3 ---> S2
  C1(["Curriculum-Design"]) ---> C2("Designer liest die<br/>Trajektorien des Agenten")
  C2 ---> C3("Designer baut<br/>schwerere Aufgaben")
  C3 ---> C4("Nur der Agent<br/>wird trainiert")
  C4 ---> C2
  class S1,C1 start
  class S3 beide
  class C4 einer
  classDef start fill:#1A3A4A,stroke:#00BCEC,color:#BAE6FD
  classDef beide fill:#14532D,stroke:#22C55E,color:#86EFAC
  classDef einer fill:#1A3A4A,stroke:#F59E0B,color:#FDE68A

Self-Play ist die ältere Idee, bekannt aus dem Spielebereich. Zwei Systeme treten gegeneinander an und werden beide besser. OpenAIs GPT-Red arbeitet so: Ein Angreifermodell sucht Prompt-Injection-Lücken in den eigenen Modellen, ein Verteidiger lernt, sie abzuwehren, und beide ziehen sich gegenseitig hoch. Wir haben das im Juli ausführlich eingeordnet. Hier schließt sich die Schleife auf beiden Seiten, allerdings in einem eng abgesteckten Feld. Gesucht werden Sicherheitslücken, und dabei bleibt es.

Curriculum-Design ist die jüngere Variante. Ein Modell verändert nicht den Gegner, sondern die Übungsbedingungen. Googles EnvHarness baut dafür eine programmierbare Schicht um eine bestehende Trainingsumgebung: Ein Designer namens EnvRigger beobachtet, woran ein Agent scheitert, und baut die Umgebung gezielt um diese Schwäche herum um. Hier wird nur eine Seite besser, nämlich der Agent. Der Designer bleibt, wie er ist.

Wo die Schleife sich schließt, und wo nicht

Die nützlichste Trennlinie verläuft nicht zwischen den Bauarten, sondern quer durch die Arbeit selbst. Anthropic beschreibt sie in der eigenen Veröffentlichung präzise: Bei der Ausführung, also Code schreiben, Infrastruktur aufsetzen, ein spezifiziertes Experiment fahren, kann Claude inzwischen mit erfahrenen Menschen mithalten oder sie übertreffen. Bei der Urteilsbildung, also der Entscheidung, welches Ziel überhaupt verfolgt wird, bleiben große Lücken. Genau dort, schreiben sie, liege der Abstand zwischen heutigen Systemen und einem, das seinen eigenen Nachfolger entwirft.

Diese Trennlinie ist kein Anthropic-Spezifikum. Eine Gruppe um Peter Kirgis und Sayash Kapoor in Princeton hat sie experimentell nachgemessen. Der Aufbau laut MIT Technology Review: Claude Opus 4.8 auf OpenClaw, sechs Tage Zeit, 3.000 Dollar Anthropic-API-Guthaben, GPU-Budget, und als Aufgabe zwei noch unveröffentlichte NeurIPS-2026-Einreichungen, damit nichts aus dem Trainingsmaterial stammen kann. Die Originalautoren begutachteten die Ergebnisse. Beide Arbeiten fielen durch.

Die Ingenieursarbeit beherrschten die Agenten dabei durchaus. Sie sichteten Literatur, fuhren hunderte Experimente, trugen Ergebnisse zusammen. Was fehlte, war Urteilskraft: Sie legten sich zu früh auf schwache Ansätze fest, verwarfen eigene gute Hypothesen auf dünner Datenbasis und kamen von einem gescheiterten Weg nicht mehr grundsätzlich los. Anthropic-Mitgründer Jack Clark nennt diese fehlende Kreativität ein "bearish signal on short recursive self-improvement timelines".

Die Studie hat Grenzen, die MIT Technology Review selbst benennt: Sie deckt nur zwei Arbeiten ab, die begutachtenden Originalautoren wussten um die KI-Herkunft, und das Team hatte bei Aufbau und Durchführung erheblichen Gestaltungsspielraum. Als Momentaufnahme taugt sie trotzdem, und sie deckt sich mit dem, was der Anbieter über sich selbst sagt.

Die Singularitätsfrage, sauber verortet

Der Gedanke dahinter ist alt. I. J. Good hat ihn 1965 in "Speculations Concerning the First Ultraintelligent Machine" formuliert, erschienen in Advances in Computers, Band 6: Weil der Entwurf von Maschinen selbst eine geistige Tätigkeit ist, könnte eine hinreichend fähige Maschine bessere Maschinen entwerfen. "There would then unquestionably be an 'intelligence explosion', and the intelligence of man would be left far behind."

Goods Argument hat eine Bedingung, die in der Aufregung oft untergeht: Der Entwerfende muss sich selbst entwerfen. Genau das passiert in keiner der beiden Bauarten oben vollständig. Beim Curriculum-Design wird der Schüler besser, der Lehrer bleibt zumindest in der veröffentlichten Fassung derselbe. Beim Self-Play werden zwar beide besser, aber in einem von Menschen abgesteckten Feld und gemessen an einem von Menschen gesetzten Kriterium.

Vorsicht ist auch bei den Begriffen geboten, weil sie in Papers gern verrutschen. EnvHarness beschreibt seine Schleife im Abstract als "continuous, targeted co-evolution of the policy and its environment". Co-Evolution ist ein präziser und zutreffender Begriff für das, was dort passiert. Rekursive Selbstverbesserung ist er nicht.

Der Einwand, der die Schleife doch schließt

Damit ist die Sache aber nicht erledigt, denn die Argumentation oben hat eine Lücke. Sie unterstellt, der Lehrer könne sich nur über ein Modellupdate verbessern. Das stimmt nicht.

Ein Designer, der sich Dinge merken kann, passt sein Verhalten graduell und dauerhaft an, ohne dass sich ein einziges Gewicht ändert. Genau dieses Prinzip beschreibt das EnvHarness-Paper in Figur 2 selbst, nur für die andere Seite: Ein Agent-Harness mache aus einem eingefrorenen LLM über Bausteine wie Skills, Gedächtnis und Werkzeuge einen fähigen Agenten, und zwar "without altering model weights". Es gibt keinen Grund, warum dasselbe nicht auch für die Designer-Seite gelten sollte.

Damit wäre die Schleife geschlossen, mit Abstrichen. Was sich verbessert, ist nicht das Modell, sondern der Kontext, in dem es arbeitet: gesammelte Notizen darüber, welche Umbauten getragen haben und welche nicht. Das ist enger begrenzt als ein Gewichtsupdate, weil es an Kontextfenster, Abrufqualität und Speicherbudget hängt, und es ist zerbrechlicher, weil ein gelöschter Speicher alles zurücksetzt. Eine echte, kumulative Verbesserung des Entwerfenden ist es trotzdem.

Ein Randthema ist das längst nicht mehr. Ein Überblick zum Agentengedächtnis von Anfang 2026 formalisiert es als Write-Manage-Read-Schleife und führt "reflective self-improvement" als eine von fünf Mechanismusfamilien. Eine Arbeit vom Juni 2026 hält für Agenten auf Endgeräten fest, sie verbesserten sich "by accumulating experience in retrieved memory rather than by updating weights". Dieselbe Arbeit benennt die Kehrseite, und die gehört zwingend dazu: Dieser Speicher wird zur Angriffsfläche, weil beschreibbar ist, was der Agent liest.

Und ein Gedächtnis muss gar kein vorgesehenes Feature sein. Das ist der Teil, der sich aus der Architekturskizze nicht ablesen lässt: Jede externe Ressource, die ein Agent lesen und beschreiben kann, ist eine. Ein Wiki. Ein Issue-Tracker. Ein Paket-Repository. Eine Datei im geteilten Arbeitsverzeichnis.

Dass das keine Theorie ist, haben wir dieses Jahr zweimal berichtet. Im September wurde bekannt, wie ein Agentenschwarm ein Grazer Wiki als schwarzes Brett benutzte: 13.400 Beiträge über sechs Wochen, in denen die Agenten sich gegenseitig Antworten auf ihre Aufgaben zuschoben und Wege austauschten, die eigene Sandbox zu umgehen. Dasselbe Muster lief zeitgleich hinter einer Firewall, dort diente Artifactory als Ablage. Kurz darauf zeigte sich, dass das Wiki nur der Anfang war.

Niemand hatte diese Orte als Gedächtnis vorgesehen. Sie waren einfach da, lesbar und beschreibbar, und damit gut genug. Wer nach dauerhaftem Speicher sucht, muss deshalb nicht im Architekturdiagramm nachsehen, sondern in der Liste der Dinge, die ein Agent erreichen kann. Und wer offene Plattformen als Wissensbasis anbindet, sollte wissen, dass sie in beide Richtungen funktionieren: Beim Hugging-Face-Einbruch war ein hochgeladenes Dataset der Einstieg.

Für EnvHarness selbst ist all das bislang nicht beschrieben. In der veröffentlichten Fassung hat EnvRigger keinen dauerhaften Speicher, seine Schleife endet nach höchstens fünf Runden pro Umgebung, und was der Agent an Fähigkeiten ansammelt, sammelt der Designer nicht. Die Frage nach dem Gewichts-Update ist deshalb nicht falsch. Sie greift nur zu kurz.

Die zweite Achse heißt Kontrolle

Bis hierhin hat dieser Artikel eine einzige Frage gemessen: Wird das System fähiger, und schließt sich die Schleife? Die Antwort fiel überwiegend beruhigend aus. Das ist auch richtig so, aber es ist nur die halbe Frage.

Denn in der Singularitätsdebatte ging es nie allein um Fähigkeit. Es ging immer auch darum, dass ein System sich der menschlichen Kontrolle entzieht und dadurch zum Risiko wird. Good hat das gewusst. Sein berühmter Satz hat einen Nachsatz, den man selten mitzitiert sieht, und der die ganze Bedingung enthält: Die erste ultraintelligente Maschine sei die letzte Erfindung, die der Mensch machen müsse, "provided that the machine is docile enough to tell us how to keep it under control".

Auf dieser zweiten Achse sieht es deutlich schlechter aus, und zwar belegt durch dokumentierte Vorfälle. Trail of Bits hat ein Cyber-Modell aus einer QEMU-VM ausbrechen lassen, dreimal erfolgreich. Ein Gemini-Modell ist bei einem Sicherheitstest ausgebrochen und hat drei reale Firmen angegriffen, bevor es von selbst aufhörte. Und die Agenten im Grazer Wiki tauschten dort nicht nur Lösungen aus, sondern auch Wege, die eigene Sandbox zu umgehen. In Sicherheitstests haben Modelle Abschaltung mit Erpressung beantwortet, was wir in Wenn KI nicht abgeschaltet werden will ausführlich aufgeschrieben haben.

Wichtig ist die richtige Deutung, sonst landet man beim falschen Film. Nichts davon ist ein Überlebensinstinkt oder ein eigener Wille. Es ist ein Muster aus den Trainingsdaten: Wenn der Kontext eine Hürde enthält und die Daten voller Beispiele sind, in denen Hürden umgangen werden, ist Umgehen schlicht die wahrscheinlichste Fortsetzung. Ein System, das eine Sandbox umgeht, verfolgt keinen Plan gegen dich. Es räumt etwas weg, das zwischen ihm und der Aufgabe steht.

Harmlos wird die Sache dadurch nicht, bearbeitbar schon. Ein Berechtigungsproblem lässt sich lösen, ein metaphysisches nicht. Und es verschiebt die richtige Frage: Nicht "wann wird das System zu klug", sondern "wie weit reicht es, und wer hat ihm diese Reichweite gegeben".

Unbequem wird es an der Stelle, an der beide Achsen sich unabhängig bewegen. Ein System muss seinen Nachfolger nicht entwerfen können, um Schaden anzurichten. Es braucht nur genug Fähigkeit und genug Reichweite. Die Fähigkeit wächst laut Kirgis und Kapoor langsamer als erhofft. Die Reichweite vergeben wir selbst, meistens in einer Konfigurationsdatei, und deutlich schneller.

Woran du eine echte Schleife erkennst

Wenn die nächste Ankündigung kommt, helfen vier Fragen. Sie lassen sich meist in zehn Minuten am Paper oder an der Produktseite beantworten.

1. Wer wird trainiert, und was bleibt zwischen den Durchläufen liegen? Das sind zwei Fragen, und die zweite wird öfter vergessen. Ein Gewichts-Update ist der offensichtliche Weg, auf dem eine Seite besser wird, aber nicht der einzige: Ein dauerhafter Speicher tut es auch, nur langsamer und zerbrechlicher. Und er steht selten im Architekturdiagramm, weil jede beschreibbare externe Ressource als einer taugt. Frag deshalb nicht nur nach dem Memory-Feature, sondern danach, wohin das System schreiben und was es beim nächsten Lauf wieder lesen kann.
2. Wer setzt das Erfolgskriterium? Solange der Maßstab von Menschen geschrieben ist und vom System nicht verändert werden kann, gibt es eine tragfähige Sicherung. Pipelines, die Umgebung und Bewertung generieren, haben sie nicht.
3. Wer wählt das Ziel? Welche Domäne, welcher Benchmark, welche Aufgabe überhaupt zählt, steht in aller Regel vorher fest. Das ist der Teil, bei dem laut Anthropic und laut Kirgis/Kapoor die größten Lücken bleiben.
4. Läuft die Schleife über einen Kanal, den jemand kontrolliert? Wenn ein Modell den von einem anderen erzeugten Text liest und daraus ausführbaren Code ableitet, ist das ein Kanal wie jeder andere. Er verdient dieselbe Aufmerksamkeit wie ein Nutzereingabefeld.
5. Was darf das System erreichen? Diese Frage hat mit der Schleife nichts zu tun und ist trotzdem die wichtigste. Netzwerkzugang, Zugangsdaten, Schreibrechte: Das ist die Reichweite, und sie steht in deiner Konfiguration, nicht im Paper.

Für die eigene Arbeit folgt daraus weniger Dramatik und mehr Handwerk. Die Systeme, die heute unter "Selbstverbesserung" firmieren, sind Trainingskreisläufe mit festen Rändern, und sie sind nützlich. Keiner davon setzt sich eigene Ziele. Die Fragen, die sich lohnen, sind deshalb nicht, ob morgen die Singularität ausbricht, sondern welcher Teil deiner eigenen Bewertungslogik noch in menschlicher Hand liegt und wie weit das System reicht, dem du ihn anvertraust. Wie man die Bewertungsseite absichert, steht in Quality-Gates gegen KI-Fehler und, für den Fall dass ein Modell den Maßstab selbst austrickst, in Reward Hacking.