Das Fazit in 5 Sekunden
Was bei der KI-Automatisierung wirklich zählt, ist nicht eine schnelle erste Antwort, sondern möglichst wenig Nacharbeit, bis das Ergebnis wirklich fertig ist.
Ein System zur Artikelproduktion hat sich nach einigen Tagen bis etwa einer Woche intensiven Umbaus von einem simplen „Ding, das eine KI Text schreiben lässt und speichert" zu einer kleinen autonomen Fabrik entwickelt, mit Überwachung, Neustarts, Konfliktkontrolle, Zwischenspeicherung, Fehlerisolierung, Qualitätsschranken und Beweisverwaltung.
Gewirkt hat bei diesem großen Umbau die Idee, ultra ganz am Anfang großer Designänderungen einzusetzen. Das ist der Modus, der GPT-5.6 Sol nicht nur tiefer nachdenken lässt, sondern auch mehrere Arbeiten parallel vorantreibt.
Ein Durchlauf ist schwer. Aber später gibt es weniger „das war ja kaputt", „die parallele Ausführung hat einen Unfall verursacht", „es gibt keinen Beleg" und „wieder alles von vorn". Unterm Strich wird die Gesamtzeit kürzer.
In Fabriksprache: Die Taktzeit ist lang, aber die Nacharbeitsquote ist niedrig, also ist die gesamte Durchlaufzeit kurz.
Vorab eine Warnung: Level 6 und Level 7 sind keine weltweit gültigen Ränge
Die Begriffe Level 6 und Level 7 in diesem Artikel sind weder Spiellevel noch ISO-Norm. Es sind Etiketten, die ich für dieses System selbst vergeben habe, um den Reifegrad der Automatisierung verständlich zu erklären.
Die Grundidee ähnelt dem „Autonomic Computing", das IBM seit Langem erforscht. IBM fasst als Kerneigenschaften eines autonomen Systems zusammen: sich selbst konfigurieren, sich selbst reparieren, sich selbst optimieren und sich selbst schützen.
In diesem Artikel nenne ich die Stufe, in der das System von selbst in einen korrekten Zustand zurückkehrt, Level 6, und die Stufe, in der es darüber hinaus innerhalb eines sicheren Rahmens selbst nach besseren Betriebsweisen sucht, Level 7.
Am Anfang hieß es nur „die KI schreibt Artikel". Plötzlich wuchs dem Blog ein Zaun
Eine gewöhnliche Artikelautomatisierung ist einfach:
- Sie läuft zu einer festen Uhrzeit.
- Die KI erzeugt den Text.
- Er wird in einer Datei gespeichert.
- Er wird auf GitHub abgelegt.
- Bei einem Fehler schaut ein Mensch nach.
Schon das ist ziemlich praktisch.
Doch wenn die Zahl der Artikel steigt, es 12 Sprachen werden und man auch Qualitätsprüfung, interne Links, Aktualisierungen und die Entscheidung zur Veröffentlichung automatisiert, ändert sich das Problem.
Es geht dann nicht mehr um „Kann sie schreiben?", sondern um Fragen wie diese:
- Was tun, wenn zwei Worker (Programme, die Aufgaben ausführen) gleichzeitig denselben Artikel anfassen?
- Wo macht man weiter, wenn der Lauf mittendrin abstürzt?
- Wie verhindert man, dass eine fehlgeschlagene Aufgabe ewig wiederholt wird?
- Verwenden wir womöglich ein altes Prüfergebnis als wäre es ein neues?
- Behauptet die KI eigenmächtig, „ein Mensch hat das geprüft"?
- Wer stoppt eine Veröffentlichung in einem Zustand, in dem sie nicht erscheinen darf?
- Wie hält man die ganze Fabrik am Laufen, wenn ein externer Dienst ausfällt?
- Die Anzeige sagt „100 Punkte", aber misst diese 100 wirklich den aktuellen Zustand?
An diesem Punkt ist es keine „Blog-Automatisierung" mehr.
Es ist ein kleines Produktionssystem, das Inhalte als Rohstoff nutzt.
Level 6: Auch wenn etwas kaputtgeht, kehrt es von selbst in den richtigen Zustand zurück
Level 6 dieser Fabrik ist in einem Satz ein Mechanismus, der autonom zu einer festgelegten richtigen Antwort zurückkehrt.
Die wichtigsten Bausteine sind diese.
| Mechanismus | Für Mittelstufenschüler erklärt |
|---|---|
| desired state | Man legt die „richtige Antwort" in einer maschinenlesbaren Form fest |
| reconciliation | Man vergleicht den Ist-Zustand mit der richtigen Antwort und korrigiert Abweichungen |
| lease / fencing | Verhindert, dass zwei Beteiligte dieselbe Arbeit eigenmächtig gleichzeitig ausführen |
| checkpoint | Speichert offiziell, bis wohin die Arbeit gekommen ist |
| CAS | Überschreibt keinen neuen Zustand mit einem veralteten |
| transactional outbox | Fängt die Schieflage auf, wenn die Hauptaktion klappt und nur die Benachrichtigung scheitert |
| retry / quarantine | Wiederholt vorübergehende Fehler und isoliert „vergiftete" Daten |
| safe publication gate | Lässt nichts erscheinen, bis die Qualitätsbedingungen erfüllt sind |
| failure injection | Macht absichtlich etwas kaputt, um zu testen, ob die Wiederherstellung wirklich funktioniert |
| observability | Macht messbar, was läuft und was fehlschlägt |
In einer Momentaufnahme des Betriebs standen alle 21 Designanforderungen von Level 6 auf PASS, und die Bewertung der Steuerungsimplementierung lag bei 100. Die Zusicherungsbewertung, die externe Messung, menschliche Bestätigung und die Langzeitbilanz aller Worker einschließt, lag dagegen bei rund 69 %; die Veröffentlichung stand weiter auf HOLD und Level 7 auf OFF.
Das ist der entscheidende Punkt.
100 Punkte bei der Umsetzung und 100 Punkte, bei denen man das System wirklich beruhigt sich selbst überlassen kann, sind zwei verschiedene Dinge.
Selbst wenn alle Tests bestehen: Den Beleg, dass es wirklich eine Woche, einen Monat oder ein halbes Jahr gelaufen ist, kann man nicht ohne Zeitaufwand erzeugen.
Sols tiefes Nachdenken und Ultra: „Eine Person denkt lange nach" gegen „mehrere arbeiten parallel"
Laut offizieller Beschreibung von OpenAI hat GPT-5.6 Sol max, das tiefes Schlussfolgern auslöst, und ultra ist eine leistungsstarke Einstellung, die mehrere Agenten in parallelen Arbeitssträngen zusammenarbeiten lässt.
Ein Vergleich.
Wenn man Sol tief nachdenken lässt
Man sperrt einen hervorragenden Konstrukteur in einen Besprechungsraum.
„Lass dir Zeit. Lies den ganzen Code und alle Unterlagen. Finde die Widersprüche. Denk es bis zum Ende durch."
Das ist sehr stark.
Bei Ultra
Konstrukteur, Umsetzer, Fehlersucher, Zerstörer und Tester arbeiten gleichzeitig, und am Ende werden die Ergebnisse zusammengeführt.
Kurz gesagt: Die Intelligenz verdoppelt sich nicht einfach, sondern die Richtungen, in denen man etwas übersieht, werden gestreut.
Nach den von OpenAI veröffentlichten Zahlen erreichte GPT-5.6 Sol bei Terminal-Bench 2.1 88,8 % und Sol Ultra 91,9 %. Der Abstand beträgt 3,1 Punkte, doch auf der Fehlerseite sinkt der Wert von 11,2 % auf 8,1 %; rechnerisch geht die Fehlerquote also um etwa 28 % zurück. Das ist natürlich nur eine einzelne Bewertung und heißt nicht, dass die Fehler bei jeder Arbeit um 28 % sinken.
Dennoch ist bei teilbaren Aufgaben wie „ein riesiges Repository lesen, entwerfen, umsetzen, kaputtmachen und neu prüfen" die Richtung dieses Unterschieds gut zu erkennen.
Warum ist das schwere Ultra am Ende doch schneller?
Die Zeit bis zur Fertigstellung lässt sich ungefähr so betrachten:
gesamte Durchlaufzeit = erste Umsetzung + Nacharbeit + erneutes Testen + Störungsbehebung + Korrektur von Missverständnissen
Die meisten schauen nur auf den ersten Posten, die „erste Umsetzung".
Deshalb wirkt eine KI, die in 30 Minuten antwortet, schnell, und eine, die 2 Stunden braucht, langsam.
Wenn die 2-Stunden-Variante aber 6 Stunden Nacharbeit erspart, die sonst später angefallen wären, ist sie die schnellere.
In der Fertigung ist das genauso.
Eine Fabrik, die schnell produziert und bei der Prüfung massenhaft aussortiert, verliert am Ende gegen eine, die von Anfang an ihre Prozessfähigkeit steigert und keinen Ausschuss erzeugt.
Interessant an diesem „Ultra-Schlag in einem Zug" war, dass die meisten später gefundenen Probleme keine waren, die ein Neudesign von Grund auf erforderten.
Was in den späteren Schritten nachgeschärft wurde, waren zum Beispiel diese Dinge:
- Ich möchte auf einer Seite den Beleg sehen, dass wirklich alle Worker echte Daten verarbeitet haben.
- Verwende kein altes 50/50 als das 50/50 eines neuen Audits.
- Schreib eine KI-Prüfung nicht als menschliche Prüfung.
- Wenn es keine externe Messung gibt, schreib „unbekannt".
- Auch wenn ein Worker nichts getan hat, gilt ein korrektes NOOP (es gab nichts zu tun, er blieb absichtlich untätig) nicht als Fehler.
Das ist nicht „die Pfeiler standen falsch herum, also bauen wir das Haus neu".
Es ist eher so, als käme die Qualitätskontrolle in eine fertige Fabrik und würde bis zu den Beschriftungen der Rohre und der Kalibrierung der Messgeräte pingelig.
Warum der „Ultra-Eintopf" funktioniert hat
Es geht nicht darum, dass auf Anhieb alles perfekt war.
Genauer: Die ursprüngliche Designphilosophie war ziemlich richtig, deshalb blieben die späteren Korrekturen lokal.
Viel hat gebracht, dass man die folgenden Fragen von Anfang an ins Design aufnehmen konnte:
- Was, wenn es gleichzeitig läuft?
- Was, wenn es mittendrin stirbt?
- Was, wenn es doppelt verarbeitet wird?
- Was, wenn mit einem veralteten Zustand in der Hand geschrieben wird?
- Was, wenn nur die externe API ausfällt?
- Was, wenn fehlerhafte Daten endlos im Kreis laufen?
- Was, wenn die Prüfung selbst kaputt ist?
- Was, wenn es ein Schlupfloch gibt, mit dem man lügen kann: „alles erfolgreich"?
Normalerweise lernt man das nacheinander durch Ausfälle im Produktivbetrieb.
Diesmal habe ich die Arbeitsunfälle vorab virtuell herbeigeführt.
Den Server im Test abstürzen lassen, bevor er wirklich abstürzt. Die CI zum Weinen bringen, bevor ein Mensch weinen muss.
Dieser Gedanke passt auch gut zum Chaos Engineering. Dort definiert man den Normalzustand messbar, spielt gezielt Störungen ein, die in der Realität vorkommen, und prüft, ob der Normalzustand zusammenbricht.
Wie beeindruckend ist das im Vergleich zur Welt da draußen?
Hier sollte man nicht übertreiben, das ist ehrlicher.
„Das stärkste System der Welt" zu sagen, wäre zu viel.
Aber es ist auch nicht bloß „ich schreibe einen Blog mit KI".
Zur Einordnung kann man es so sehen:
| Vergleich | Abstand |
|---|---|
| Eine KI einen Artikel schreiben lassen und speichern | Deutlich voraus |
| Lineare Automatisierung à la Zapier / n8n | Mindestens eine Stufe voraus bei Fehlerbehebung und Konfliktkontrolle |
| Das ernsthafte Backend eines privaten SaaS | Viele Designelemente auf demselben Niveau |
| Interne Automatisierungsplattform eines kleinen bis mittleren Unternehmens | Durchaus vergleichbar |
| Ausgereifter kommerzieller Dienst mit eigenen SREs (Ingenieuren für Zuverlässigkeit) | Bei Langzeitbetrieb, externer Überwachung und Sicherheitsgarantien noch darunter |
| Riesige Infrastruktur auf Google- oder Amazon-Niveau | Von der Größenordnung her ein anderes Universum |
Für ein Einzelprojekt ist merkwürdig, dass mehr Code darüber gewachsen ist, wie man sich bei Fehlern verhält, als über die Funktion, Artikel zu schreiben.
Wenn lease, fencing, CAS, outbox, quarantine und failure injection in einer Artikelfabrik wohnen, ist das weniger ein Blog als ein Logistikzentrum.
Level 7: Der Fabrikleiter fängt an, Verbesserungsideen selbst auszuprobieren
Bei Level 6 legen Menschen die „richtige Antwort" fest.
Geht etwas kaputt, kehrt man zu dieser Antwort zurück.
Bei Level 7 sucht das System innerhalb des Rahmens der richtigen Antwort selbst nach besseren Betriebsweisen.
Das Bild dazu:
- Qualität, Geschwindigkeit, Kosten, Wartezeit und Fehlerquote gleichzeitig messen.
- Die Sicherheitsbedingungen absolut unveränderlich machen.
- Neue Prompts und Verarbeitungsreihenfolgen im Shadow-Modus ausprobieren (ein paralleler Testlauf ohne Wirkung auf die Produktion).
- Sieht es gut aus, per Canary (schrittweise Einführung) ausweiten: 5 %, 20 %, 100 %.
- Sinkt die Qualität, automatisch zurückrollen.
- Ist die Zuverlässigkeit schlecht, nur die Experimente stoppen und die normale Produktion weiterlaufen lassen.
- In einem Experimentbuch festhalten, was ausprobiert wurde, was gut war und warum es übernommen wurde.
Das kommt der Kombination aus der Self-Optimization des IBM-Autonomic-Computing, dem Error Budget von Google SRE (wie viele Fehler man sich leisten kann, bevor man bremsen muss) sowie Canary und Rollback von AWS nahe.
Allerdings muss Level 7 jetzt nicht sofort in den Produktivbetrieb.
Der Grund ist einfach: Ich sammle noch die Langzeitbilanz von Level 6.
Wenn man noch prüft, ob die Anlage stabil ist, und dem KI-Fabrikleiter sagt: „Ab heute darfst du auch die Bandgeschwindigkeit selbst ändern", wird die Ursachenabgrenzung mühsam.
Wenn ich jetzt etwas tue, dann nicht Level 7 selbst, sondern eine Stärkung der Beobachtung, indem die tatsächliche Arbeit aller Worker auf einer Seite zusammenläuft.
Den Monat, in dem man zahlt, zum „Investitionsmonat für Anlagen" machen
Ultra für leichte Alltagsaufgaben einzusetzen, ist kaum nötig.
Für kleine Korrekturen, Routineprüfungen oder bereits festgelegte Worker-Verarbeitung reichen das normale Sol oder tiefes Schlussfolgern in vielen Fällen aus.
Ultra lohnt sich bei Arbeiten, bei denen ein Fehlschlag viel Nacharbeit bedeutet:
- Neuentwurf des gesamten Systems
- Großangelegtes Refactoring
- Neuordnung der Worker-Struktur
- Entwurf von Überwachung und Wiederherstellung
- Überprüfung der Sicherheitsgrenzen
- Die Shadow-Grundlage für Level 7
- Hinzufügen vieler Tests und Fehlerinjektionen
Sinnvoll ist daher: im Alltag die Fabrik betreiben, große Umbauthemen sammeln und in einer Zeit, in der man den Spitzenmodus nutzen kann, gebündelt in die Anlagen investieren.
Statt die KI-Abrechnung als „Monatsgebühr, mit der man jeden Tag ein bisschen klüger wird" zu sehen, betrachtet man sie als Baukosten, um das Fundament in einem Zug zu erneuern.
Mit dieser Sicht muss man den Wert eines schweren Modells nicht allein am Preis pro Antwort messen.
Die größte Erkenntnis dieser knappen Woche
Die größte Erkenntnis ist, die Klugheit einer KI nicht nur an der Trefferquote zu messen.
In der Praxis zählen diese fünf Dinge:
- Genauigkeit des ersten Entwurfs — muss man später nicht alles einreißen?
- Widerlegungsfähigkeit — kann sie den eigenen Vorschlag selbst zerlegen?
- Parallelität — lassen sich Entwurf, Umsetzung, Test und Prüfung getrennt vorantreiben?
- Beweisbarkeit — statt „es hat wohl funktioniert" festhalten können, was tatsächlich gelaufen ist.
- Wiederherstellbarkeit — kann sie sich nach einem Fehler erholen, ohne einen Menschen zu rufen?
Eine gute KI-Fabrik ist also keine „Fabrik, die nie scheitert".
Sie ist eine Fabrik, die vom Scheitern ausgeht, bei Fehlern nicht stehen bleibt, keine falschen Erfolge meldet und von jedem Punkt aus zurückfinden kann.
Fazit: Geschwindigkeit heißt, wie schnell man bis zum Ende kommt
Wenn man erklärt, warum es in etwa einer Woche so weit gekommen ist, mit „die KI war irre schnell", verfehlt man den Kern.
Gewirkt hat, beim ersten Entwurf reichlich Rechenressourcen einzusetzen und danach zum günstigen Normalbetrieb zurückzukehren.
Ultra ist kein magischer Knopf für die richtige Antwort. Es ähnelt eher einer Vorrichtung, die Nacharbeit durch Vorauszahlung beseitigt.
Auch wenn ein einzelner Durchlauf langsam ist: Ist die Gesamtzeit bis zur Fertigstellung kurz, ist es schnell.
Und was jetzt in dieser Phase gebraucht wird, ist nicht, ein noch klügeres Level 7 aufzusetzen.
Sondern Level 6 eine Weile in Ruhe zu lassen und zu beobachten, ob es wirklich von selbst weiterarbeitet.
Wenn die Fabrik gelangweilt wirkt, kann man dem KI-Fabrikleiter dann die Verbesserungsbefugnis übertragen.
Im Moment wäre es einfach zu unterhaltsam, dem Fabrikleiter einen Knopf zum eigenmächtigen Ändern der Bandgeschwindigkeit zu geben.
Quellen (7)
- OpenAI, GPT-5.6: https://openai.com/index/gpt-5-6/
- OpenAI, GPT-5.6 (japanische Fassung): https://openai.com/ja-JP/index/gpt-5-6/
- IBM Research, Autonomic computing: https://research.ibm.com/publications/autonomic-computing-architectural-approach-and-prototype
- IBM Research, Utility functions: https://research.ibm.com/publications/achieving-self-management-via-utility-functions
- Google SRE, Error Budget Policy: https://sre.google/workbook/error-budget-policy/
- Principles of Chaos Engineering: https://principlesofchaos.org/
- AWS, Amazon ECS canary deployments: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/canary-deployment.html
