Die letzten drei Wochen waren einige der aufschlussreichsten, die ich in der KI-gestützten Softwareentwicklung erlebt habe.
Claude Fable kam wieder ins Spiel, und im gleichen Zeitraum veröffentlichte OpenAI GPT-5.6 mit Sol, Terra und Luna. Das Signal des Marktes war eindeutig: Führende Labore liefern nicht mehr so sehr isolierte Durchbrüche, sondern verkürzen den Abstand zwischen Leistungsfähigkeit, Preisstufen und Bereitstellungsrhythmus. Anthropic verkauft Fable 5 jetzt als sein Top-End-Modell für langfristige Aufgaben zu etwa dem doppelten Listenpreis von Opus 5, während OpenAI GPT-5.6 als eine Familie positioniert, die von der Spitzenleistung des Flaggschiffs bis hin zu kostengünstigeren Anwendungen skaliert. xAI wiederum bepreist Grok 4.5 so aggressiv, dass es in jeder Kosten-Leistungs-Diskussion ernst genommen werden muss.
Und doch hatte das Wichtigste, was ich in diesen Wochen gelernt habe, nur sehr wenig mit Produktseiten oder Benchmark-Folien zu tun.
Der eigentliche Durchbruch in meiner Arbeitsumgebung war die Vorbereitung.
Wir hatten Stories bereit. Wir hatten die Arbeit in Teile zerlegt, die tatsächlich von agentischen Codierungssystemen ausgeführt werden konnten. Sobald diese Warteschlange existierte, wurde der Durchsatz absurd. Über Codex, Claude, Cursor, Grok und andere Tools im Workflow hinweg wurden in etwa zehn Tagen mehr als 2 Millionen Codezeilen geschrieben. Diese Zahl klingt nach Hype, bis man sieht, was sie ermöglicht hat: nicht Magie, nicht Autonomie im Abstrakten, sondern ein stetiger Strom von klar begrenzten Aufgaben mit genügend Struktur, damit die Modelle in Bewegung bleiben.
Das ist die erste Sache, die viele immer noch übersehen. Die Explosion des Outputs passiert nicht, weil die Modelle plötzlich zu selbststeuernden Ingenieuren wurden. Sie passiert, weil Menschen das Schlachtfeld vorbereitet haben.
Die zweite Sache, die ich gelernt habe, ist, dass Fehler bei Skalierung schneller auftauchen, als das Marketing je zugibt.
Codex ist ein gutes Beispiel. OpenAIs eigenes Material zu langlaufenden Arbeiten macht deutlich, dass dauerhafte Threads mit einem Kompromiss einhergehen: Kontinuität ist nützlich, aber langlaufende Threads können auch teurer und schwieriger zu verwalten werden, als ganz neu zu starten. Die Goals-Funktion wurde genau dafür entwickelt, einen Thread an ein begrenztes Ziel zu binden, anstatt jede schwierige Aufgabe in einen ständig wachsenden Prompt zu verwandeln. In der Praxis deckt sich das mit dem, was ich gesehen habe. Wenn ein Prozess zu lange läuft, ist das bessere Muster oft, ihn zu stoppen, um eine saubere Übergabe zu bitten, die Sitzung neu zu starten und mit einem neuen Ziel fortzufahren. Das ist nicht nur eine Bequemlichkeit. Es ist oft betriebliche Hygiene.
Es gibt auch ein konkreteres Codex-Problem, das jetzt eine sichtbare öffentliche Spur hinterlassen hat: Subagenten- und lokale Zustandsexplosionen.
Offenes Issue #34061 dokumentiert einen Fall, bei dem ein fortgesetzter Eltern-Thread Tausende von untergeordneten JSONL-Logs und Hunderte von Gigabyte an persistiertem Sitzungsverlauf erzeugte. Ein anderes Issue warnt ausdrücklich davor, dass fork_context=true dazu führen kann, dass große Eltern-Verläufe in Kind-Agenten gespiegelt werden, was sowohl das Korrektheitsrisiko als auch den Token-Verbrauch verstärkt. Ein weiterer öffentlicher Bericht zeigt, dass Codex-Kaltstarts zu 1–5-minütigen Wartezeiten führen, sobald ~/.codex große SQLite-Logs und Sitzungszustände angesammelt hat. Zusammengenommen beschreiben diese Berichte eine Fehlerart, die viele Power-User sofort erkennen werden: die lokale Metadatenebene. Sobald diese groß genug wird, wird die Sitzungspersistenz zu einem ernsthaften Teil der Produkterfahrung.
Das ist wichtig, weil Multi-Agent-Codierung in Demos immer besser aussieht als auf einem stark beanspruchten Entwicklungsrechner.
Das Versprechen ist klar. OpenAIs Multi-Agent-Dokumentation beschreibt, warum parallele Subagenten unabhängige Arbeitsabläufe beschleunigen können, und dieses Versprechen ist real. Aber dieselbe Dokumentation warnt auch, dass Subagenten den Token-Verbrauch erhöhen und möglicherweise nicht für Aufgaben geeignet sind, die häufige Schreibvorgänge auf gemeinsam genutzten, veränderlichen Zustand beinhalten. Die Anleitung zu parallelen Agenten auf ChatGPT Learn ist noch deutlicher: beginnt mit leseintensiven Arbeiten wie Erkundung, Tests, Triage und Zusammenfassung; seid vorsichtiger bei schreibintensiven Abläufen, weil Konflikte und Koordinationsaufwand schnell steigen. Diese Warnung ist nicht theoretisch. Jeder, der schon einmal eine Flotte von Agenten gleichzeitig auf eine vollständige Testsuite losstürmen sah, weiß genau, was das bedeutet.
In meiner eigenen Umgebung ist dies mittlerweile eines der bestimmenden betrieblichen Probleme der gesamten Kategorie.
Das Problem ist nicht, ob die Modelle intelligent genug sind, um zu parallelisieren. Das sind sie eindeutig. Das Problem ist, dass sie immer noch weitaus bessere Orchestrierungsgrenzen brauchen, denn „intelligent genug, um zu delegieren“ ist nicht dasselbe wie „intelligent genug, um die Maschinengesundheit, lokale Prioritäten und Kostendisziplin unter Konkurrenzbedingungen zu wahren.“
Diese selbe Diskrepanz zeigt sich auch bei der Preisgestaltung.
Cursor veranschaulicht das Problem anschaulich. Seine aktuelle Preisgestaltung ist transparent: Es gibt zwei monatliche Nutzungspools, einen für Cursors eigene Modelle und einen für Drittanbieter-„Other Models“. Es zeigt auch, dass Auto nicht eine einzige Sache ist. Auto Cost verwendet eine flache Token-Preise, aber Balance und Intelligence werden zum Satz des weitergeleiteten Modells abgerechnet, und der Router kann zwischen Modellen wie Composer, GPT-5.6, Claude oder Grok wählen. Für Leute, die gelegentlich interaktiv arbeiten, ist diese Flexibilität attraktiv. Für burstartige, industrielle Arbeitslasten kann sie zur Falle werden. Ein monatliches Premium-Budget kann in wenigen sehr produktiven Tagen aufgebraucht sein.
Ich habe genau diese Fehlerart in einem review-intensiven Szenario getestet.
Ein Projekt nahm etwa 500.000 neue Codezeilen auf. Unser Review-System meldete etwa 1.500 Probleme in dieser Differenz, einschließlich Duplikaten und falsch positiven Ergebnissen. Cursor CLI wurde beauftragt, diese durchzuarbeiten. Die rohen Token-Volumen waren enorm. Die Ausgabe war nützlich. Aber die Wirtschaftlichkeit war für meinen Anwendungsfall falsch. Wenn intensive Review- und Korrekturarbeit das monatliche Kontingent in einer Woche aufbrauchen kann, mag das Tool immer noch gut sein, aber das Abonnement macht keinen Sinn mehr.
Diese Spannung ist jetzt überall.
Claude ist immer noch das System, mit dem ich am liebsten arbeite. Aber es ist auch dasjenige, bei dem ich mir der Kosten am bewusstesten bin. Codex, besonders im breiteren GPT-5.6-Ökosystem, kann oft einen weitaus höheren Durchsatz erzielen, als seine Kritiker zugeben. Grok 4.5 ist kein Witz; seine öffentliche Preisgestaltung und Positionierung machen es zu einem legitimen Mitbewerber. Anthropics eigene Preisgestaltung macht den Fable-gegenüber-Opus-Kompromiss so offensichtlich, dass er quasi das Editorial für einen schreibt: Spitzenleistung ist da, aber ebenso die Rechnung.
Und dann ist da noch das schwierigste Problem von allen, das kein Launch-Event wirklich löst.
Bei fast jedem Spitzen-Codierungsmodell, das ich verwende, gibt es immer noch eine frustrierende Lücke zwischen unterdimensioniert und überentwickelt.
Die Wahl besteht zu oft zwischen einem Modell, das nicht hart genug denkt, und einem, das für die anstehende Aufgabe viel zu hart denkt. Anthropics eigene Anleitung für Fable 5 erkennt dies im Wesentlichen an. Sie besagt, dass ein höherer Aufwand zu einer Überplanung führen kann, dass Routinearbeiten von einem geringeren Aufwand profitieren können, und dass kurze Anweisungen oft aufgeblähte Gerüste übertreffen. OpenAI sagt etwas Ähnliches in seiner GPT-5.6-Anleitung: Wenn man von früheren Modellen migriert, sollte man mit demselben Reasoning-Level beginnen und dann eine Stufe tiefer testen, da die neueren Modelle die Qualität oft mit weniger Token erhalten oder sogar verbessern können. Das ist eine technische Art, dasselbe zu sagen, was viele von uns empirisch entdecken: Der Aufwandsregler ist immer noch zu leicht zu überdrehen.
Vielleicht liegt ein Teil davon immer noch an uns.
Vielleicht sind die Anweisungsdateien zu lang. Vielleicht bekämpfen einige der Gerüste jetzt die Modelle, anstatt ihnen zu helfen. Diese Theorie ist zumindest konsistent mit Anthropics eigener Anleitung zur Kontextgestaltung, die besagt, dass der Kontext informativ, aber straff sein sollte. Es besteht eine reale Möglichkeit, dass einige der Überkomplikationen, die wir den Modellen anlasten, durch eine überdimensionierte Prompt-Infrastruktur verstärkt werden.
Aber selbst wenn man das berücksichtigt, bleibt die umfassendere Schlussfolgerung unverändert.
Die Modelle machen weniger offensichtliche Fehler als zuvor. Aber die Fehler, die sie immer noch machen, sind oft gerade deshalb gefährlicher, weil sie schwerer zu erkennen sind. Sie verstecken sich in Code, der ansonsten poliert, durchdacht und professionell aussieht. Je besser die Implementierung aus der Ferne aussieht, desto misstrauischer habe ich gelernt zu sein.
Deshalb bleibe ich skeptisch gegenüber der aktuellen Welle des KI-Codierungs-Triumphalismus.
Ich verstehe, woher der Hype kommt. Wenn man nicht jeden Tag in diesen Systemen gelebt hat, kann allein der Durchsatz wie ein Wunder wirken. Und einiges davon ist es auch wirklich. Aber die tägliche praktische Nutzung zeigt auch die andere Seite: Abrechnungsunsicherheit, Orchestrierungsfehler, Fragilität bei langen Sitzungen, eine Tendenz entweder zu oberflächlicher Vereinfachung oder aufwändigem Überdesign, und das ständige Bedürfnis nach menschlicher Verpackung, Überprüfung und Beurteilung.
Wir sind noch sehr weit von einer idealen LLM-Codierungswelt entfernt.
Der Hype ist nicht völlig falsch. Aber er ist immer noch viel weniger ehrlich als die betriebliche Realität.
