Technischer Kontext
Dieser Fall hat mich nicht wegen des Dramas „verbrannte Tokens“ interessiert, sondern weil hier sehr deutlich wird, wie KI‑Automatisierung bei einer völlig bodenständigen Aufgabe zerbricht: einen Dienst mehrsprachig machen. Keine Forschung, kein riesiges Refactoring, sondern rund 50 statische Seiten, ein paar dynamische Oberflächen und fünf Sprachen.
Der Beschreibung nach hat die Kombi Claude Code–Fable bei Medium Thinking einen Fan‑Out gemacht: rund 20 parallele Agenten hochgezogen, das Limit des Max‑Tarifs für 100 $ verfeuert und keinen einzigen Zweig abgeschlossen, weil es am 5‑Stunden‑Token‑Fenster scheiterte. Solche Geschichten sehe ich regelmäßig, wenn die Orchestrierung schlauer wirkt als die eigentliche Aufgabe.
Wichtig: Das wirkt nicht wie ein „schlechtes Modell“. Es ist eher eine schlechte KI‑Architektur für diese Art von Arbeit. Lokalisierung berührt gemeinsame Wörterbücher, Routing, Templates, i18n‑Keys, Fallback‑Logik und UI‑Prüfungen – alles stark voneinander abhängige Teilaufgaben.
Verteilt man das ohne strikt gemeinsamen Zustand auf einen Schwarm von Sub‑Agenten, fangen sie an, Analysen zu duplizieren, dieselben Dateien erneut zu öffnen, sich mit vorherigen Änderungen anzulegen und den Kontext aufzublähen. Dann greifen die klassischen Probleme: Koordinations‑Overhead, Wiederholungsläufe, Invalidierung des Präfix‑Caches und sinnloser Token‑Verbrauch.
Mir gefiel, dass der Autor des Cases intuitiv einen vernünftigeren Weg eingeschlagen hat: Sub‑Agenten verboten und das Aufgabenmanagement in einem einzigen kompakten md‑Fortschrittsdokument konsolidiert. Ehrlich gesagt ist das für diesen Umfang oft stärker als jedes „smarte“ Multi‑Agenten‑Setup.
Auswirkungen auf Geschäft und Automatisierung
Die praktische Erkenntnis ist einfach. Wenn eine Aufgabe einen gemeinsamen Kontext und viele Abhängigkeiten hat, ist ein einzelner starker Agent mit einem soliden Plan oft günstiger und zuverlässiger als ein Schwarm paralleler Ausführer.
Der zweite Punkt betrifft das Budget. Wenn Teams glauben, der Kauf eines teuren Modells decke das Implementierungsrisiko automatisch ab, bekommen sie keine Beschleunigung, sondern teures Chaos mit hübscher Oberfläche.
Gewinner sind diejenigen, die KI‑Integration als Ingenieurssystem entwerfen: Arbeit entlang echter Zustandsgrenzen aufteilen, Agentenrechte beschränken, Tokens zählen und einen externen Fortschritts‑Tracker pflegen. Verlierer sind die, die dem Modell bei verflochtenen Aufgaben zu viel Freiheit lassen und auf Magie hoffen.
Bei Nahornyi AI Lab lösen wir genau solche Dinge in der Praxis: nicht einfach „KI anschließen“, sondern einen Prozess so aufbauen, dass Automation with AI wirklich Zeit spart, anstatt ein Monatsbudget an einem Abend zu verbrennen. Falls bei Ihnen ein ähnlicher Workflow bei Lokalisierung, Support oder interner Entwicklung stockt, können wir in Ruhe die Architektur analysieren und eine KI‑Lösungsentwicklung auf Ihre echte Arbeitslast abstimmen – ganz ohne Agenten um der Agenten willen.