Huch! Claude spendiert mir 85 Euro für meinen Praxistest

Nicht kleckern, sondern klotzen!

Normalerweise zahlt man dafür, eine neue Software auszuprobieren. In diesem Fall war es fast umgekehrt: Anthropic stellte mir ein Aktionsguthaben von 85 Euro zur Verfügung, das bis zum 19. September 2026 genutzt werden konnte. Das Guthaben war ausdrücklich dafür gedacht, das neue Modell Fable 5 intensiver einzusetzen. Also stellte sich die naheliegende Frage: Verbrauche ich die 85 Euro mit kleinen Aufgaben, die auch jedes andere Modell erledigen könnte – oder werfe ich Fable ein echtes, gewachsenes Softwareprojekt vor die Füße?

Ich entschied mich für die zweite Variante. Mein Testobjekt war der Section Web Designer, ein vollständig lokal laufendes PHP-Werkzeug, mit dem sich Website-Sections aus Vorlagen erzeugen, bearbeiten, in einer Live-Vorschau anzeigen und anschließend als sauberes HTML, CSS oder vollständiges ZIP-Paket exportieren lassen. Die Anwendung arbeitet mit PHP, SQLite und Vanilla JavaScript, benötigt weder Node noch Composer und läuft portabel von einem USB-Stick.

Das Projekt war zu diesem Zeitpunkt bereits weit über ein erstes Experiment hinaus. Es besaß ein eigenes Designsystem, eine dynamische Template-Bibliothek mit 20 Vorlagen, lokale Schriften, Bild-Uploads, Repeater-Felder, einen datengetriebenen Renderer, automatische Speicherung und einen vollständigen Standalone-Export. Was noch fehlte, waren zwei große Entwicklungsschritte: der Re-Import eigener Exportpakete und die Erweiterung von einzelnen Sections zu vollständigen Seiten.

CHATGPT: Fable hat in diesem Test gezeigt, wie weit diese Zusammenarbeit bereits gehen kann. Es hat aber ebenso gezeigt, warum der Mensch dabei noch lange nicht überflüssig ist.

Kein Spielzeugprojekt, sondern ein echter Belastungstest

Für einen sinnvollen KI-Test ist eine künstliche Demo-Anwendung wenig hilfreich. Interessanter wird es, wenn bereits Strukturen, Abhängigkeiten, Altlasten und verbindliche Regeln existieren. Der Section Web Designer besitzt eine zentrale Datenbankklasse, Repositories, Services, mehrere API-Endpunkte, eine umfangreiche JavaScript-Anwendung und eine große JSON-Datei mit sämtlichen Section-Vorlagen.

Fable musste also nicht nur neuen Code schreiben. Es musste zuerst verstehen, welche Teile bereits funktionierten, welche Verträge nicht beschädigt werden durften und wie neue Funktionen in die bestehende Architektur einzupassen waren.

Dazu kamen harte Vorgaben: keine Frameworks, keine Build-Pipeline, keine externen APIs, keine CDN-Abhängigkeiten, keine neuen Node-Werkzeuge und keine unnötige Neuorganisation des Projekts. Die Anwendung sollte auch nach dem Umbau unter PHP 8.5 laufen und möglichst mit PHP 8.4 kompatibel bleiben.

Ich wollte ausdrücklich keinen Architekturplan kaufen. Meine Anweisung war sinngemäß: Analysiere nur so viel wie nötig und beginne anschließend direkt mit der Implementierung. Schließlich wollte ich das Aktionsguthaben nicht dafür ausgeben, dass mir ein Modell zwanzig Seiten lang erklärt, was es später möglicherweise bauen könnte.

Der erste Auftrag: exportierte Sections wieder importieren

Der erste große Auftrag war ein Re-Import für die bereits vorhandenen Standalone-Pakete. Der Section Web Designer exportierte zu diesem Zeitpunkt ZIP-Dateien mit einer vollständigen Vorschauseite, dem reinen Section-HTML, einer CSS-Datei, verwendeten Bildern und Schriften sowie einer strukturierten Datei namens section-package.json.

Diese Manifestdatei enthielt bereits alle Informationen, die für einen zuverlässigen Re-Import benötigt wurden: Template-ID, Template-Version, Content-Schema, Designsystem, Inhalte, Einstellungen sowie Medien- und Font-Mappings. Der Importer musste also nicht versuchen, aus beliebigem HTML zu erraten, welche Vorlage ursprünglich verwendet worden war. Er konnte das eigene Exportformat deterministisch wieder einlesen.

Fable erhielt den kompletten Projektstand als ZIP-Datei und begann unmittelbar mit der Arbeit. Es erfasste die bestehende Architektur, legte Sicherungskopien an und implementierte einen zentralen Import-Service. Dieser prüfte ZIP-Struktur, Manifest, Template-Versionen, Medien, Schriften und Datenbankoperationen.

Der Import wurde bewusst zweistufig aufgebaut. Im ersten Schritt wird das Paket hochgeladen, geprüft und als Vorschau dargestellt. Erst nach einer Bestätigung wird es tatsächlich importiert. Der Nutzer kann dabei entscheiden, ob das aktuelle Projektdesign erhalten bleiben oder das Designsystem aus dem Paket übernommen werden soll.

Fable ergänzte zwei API-Endpunkte für Prüfung und Ausführung, baute ein Import-Modal in die bestehende Oberfläche ein und implementierte eine eigene Exception-Klasse für verständliche Fehlermeldungen. Das war keine bloße Komfortfunktion. Importfehler sollten im Browser nicht als technische PHP-Ausnahmen erscheinen, sondern beispielsweise als klare Meldung wie: „Das Paket enthält kein section-package.json“ oder „Die Template-ID ist in dieser Installation nicht vorhanden.“

Überraschend viel Sicherheitsarbeit

Besonders positiv fiel auf, dass Fable den Importer nicht als naives extractTo()-Skript baute. ZIP-Dateien gehören zu den Stellen, an denen sich schnell sehr unangenehme Sicherheitsprobleme einschleichen können.

Der fertige Importer prüft unter anderem absolute Pfade, Laufwerksbuchstaben, Backslashes, Pfad-Traversal, ausführbare Dateien, unerlaubte Verzeichnisse, Anzahl der Einträge, Größe einzelner Dateien und die gesamte entpackte Datenmenge. Es wurden Grenzen für ZIP-Größe, Dateigröße, Gesamtgröße und Anzahl der Dateien eingebaut. Auch ein Schutz gegen ZIP-Bomben wurde berücksichtigt.

Medien werden nicht anhand ihrer Dateiendung blind übernommen, sondern zusätzlich über den tatsächlichen MIME-Typ geprüft. Fonts müssen echte WOFF2-Dateien sein. Vorhandene identische Schriften können wiederverwendet werden, statt unnötige Kopien anzulegen.

Die Datenbankoperation läuft transaktional. Wenn während des Imports ein Fehler auftritt, wird nicht nur die Datenbank zurückgerollt. Auch bereits kopierte Medien und Schriften werden nach Möglichkeit wieder entfernt. So bleiben keine halbfertigen Section-Instanzen oder Dateileichen zurück.

42 Tests für 8,92 Euro

Fable beließ es nicht bei der Implementierung. Es baute ein eigenes PHP-Test-Harness und erzeugte dafür ein gültiges SWD-Paket nach demselben Verfahren wie der bestehende Exporter.

Am Ende meldete das Modell 42 bestandene Service-Tests. Geprüft wurden unter anderem ein gültiges Paket, ein fehlendes Manifest, ungültiges JSON, eine unbekannte Template-ID, Pfad-Traversal, fehlende Bilder, Pakete ohne Fonts, unerlaubte PHP-Dateien, falsche Formatversionen, Versionsabweichungen, ungültige Import-IDs und das Aufräumen temporärer Verzeichnisse.

Danach folgten End-to-End-Tests über echte API-Endpunkte mit dem PHP Built-in Server. Zusätzlich wurde überprüft, ob der bestehende Export durch den neuen Importer beschädigt worden war. Auch die Benutzeroberfläche und der Import-Button wurden in die Prüfung einbezogen.

Der Preis dieses ersten großen Durchlaufs: 8,92 Euro.

Das war der Moment, an dem aus einem vorsichtigen Experiment ernsthafte Neugier wurde. Für weniger als zehn Euro war eine Funktion entstanden, für die ein menschlicher Entwickler zunächst das gesamte Projekt hätte verstehen, mehrere Dateien erstellen, Sicherheitsfragen klären und Tests aufbauen müssen.

Der zweite Auftrag: aus dem Section Composer wird ein Page Designer

Nach dem erfolgreichen Importer folgte der eigentliche Hammer. Der Section Web Designer sollte nicht mehr nur einzelne Sections erzeugen. Er sollte vollständige Seiten aus mehreren Section-Instanzen zusammenstellen können.

Die bisherige Oberfläche mit den Schritten Design, Vorlage, Inhalt und Export sollte dabei nicht verschwinden. Sie sollte lediglich eine Ebene tiefer rutschen. Darüber sollte eine neue Hauptnavigation entstehen, über die Nutzer Seiten, einzelne Sections, das Designsystem und den Import erreichen.

Beim Start sollte die Anwendung künftig vier klare Möglichkeiten anbieten: eine neue Seite bauen, eine vorhandene Seite bearbeiten, eine einzelne Section bauen oder ein Section-Paket importieren.

Auch beim Erstellen einer Seite sollte es mehrere Wege geben. Eine Seite kann vollständig leer beginnen. Sie kann aus bereits vorhandenen Sections aufgebaut werden. Oder sie kann automatisch aus sinnvollen Section-Rollen zusammengestellt werden.

Für eine Landingpage bedeutet das beispielsweise: Hero, Einführung, Leistungen, Vorteile, Referenzen, Call-to-Action und Kontakt. Eine Unternehmensseite erhält eine andere Abfolge als eine Produktseite, eine Kontaktseite oder eine redaktionelle Seite.

Die Automatik sollte nicht blind sieben Templates auswürfeln. Jedes Template erhielt deshalb eine semantische Rolle wie hero, content, features, facts, team, testimonials, cta oder contact. Der Nutzer sieht vor der Erstellung, welche Rollen vorgesehen sind, und kann sich alternative Templates vorschlagen lassen.

Mehr als Sections nur untereinander stapeln

Eine Seite ist nicht allein dadurch eine Seite, dass mehrere Bereiche untereinander stehen. Sections müssen miteinander interagieren können. Ein Button im Hero soll beispielsweise zum Kontaktbereich auf derselben Seite springen können. Ein CTA kann auf eine andere Unterseite oder eine bestimmte Section dieser Unterseite verweisen.

Deshalb wurde das bisherige URL-Feld durch einen strukturierten Link-Picker erweitert. Der Nutzer kann zwischen externer URL, interner Seite, Section auf derselben Seite, Section auf einer anderen Seite, E-Mail-Adresse, Telefonnummer, Datei und freiem Anker wählen.

Interne Links werden nicht einfach als Text wie #kontakt gespeichert. Stattdessen enthält die Datenstruktur öffentliche IDs von Seite und Section. Erst bei Vorschau und Export erzeugt der Renderer daraus die tatsächliche URL. Dadurch bleiben Links nachvollziehbar und können auf verwaiste Ziele geprüft werden.

Der Page Designer besitzt dafür eine eigene Link-Prüfung. Wird eine Ziel-Section gelöscht, kann die Anwendung einen ungültigen internen Verweis erkennen und melden.

Gestaltung und Verhalten pro Section

Bis zu diesem Ausbau konnten in Schritt drei hauptsächlich Inhalte bearbeitet werden: Texte, Bilder, Buttons, Links und Repeater. Für einen echten Page Designer reichte das nicht aus.

Der Editor wurde deshalb um die drei Bereiche Inhalt, Gestaltung und Verhalten ergänzt. Unter Gestaltung können beispielsweise Padding, Margin, Schriftgrößen, Zeilenhöhe, Textausrichtung, Containerbreite, Spaltenanzahl, Kartenabstand, Hintergrundfarbe, Radien, Schatten, Rahmen und Overlay-Stärke verändert werden.

Das globale Designsystem bleibt trotzdem der Ausgangspunkt. Eine Section kann den Standardwert übernehmen, eine vordefinierte Variante verwenden oder im Profi-Modus einen eigenen Wert erhalten. Damit wird verhindert, dass Nutzer jede Section beliebig und inkonsistent auseinanderstylen.

Auch hier blieb das System datengetrieben. Nicht jedes Template zeigt automatisch sämtliche Regler. Ein Hero bekommt andere Optionen als ein Kartenraster, eine Statistik-Section oder ein Kontaktbereich. Die verfügbaren Controls stehen direkt in der Template-Definition innerhalb der JSON-Bibliothek.

Unter Verhalten können Anker, Sichtbarkeit auf Desktop, Tablet und Mobil, Sticky-Verhalten sowie einfache Einblendanimationen eingestellt werden. Die lokalen Werte werden pro Section gespeichert und wirken ausschließlich auf die jeweilige Instanz.

Der große Umbau im Backend

Fable begann mit dem Datenmodell. Es ergänzte neue Tabellen für Seiten und die Zuordnung von Section-Instanzen zu Seiten. Außerdem erhielten Section-Instanzen zusätzliche JSON-Felder für lokale Style-Overrides und Verhaltenseinstellungen.

Die Migration prüft bestehende Spalten, bevor sie neue Felder ergänzt. Der vorhandene Datenbestand blieb erhalten. Bereits gebaute Sections konnten weiterhin bearbeitet und später einer Seite hinzugefügt werden.

Es entstanden eigene Repositories für Seiten und Seiten-Sections. Das PageRepository übernimmt Erstellung, Aktualisierung, eindeutige Slugs und das Löschen vollständiger Seiten. Das PageSectionRepository verwaltet Reihenfolge, Sichtbarkeit, Einfügen, Verschieben, Duplizieren und eindeutige Anker.

Der bisherige SectionInstanceRepository wurde zu einer vollständigen CRUD-Schicht erweitert. Importierte Sections erzeugen nun neue Instanzen, statt die bisher aktive Section zu überschreiben. Diese Änderung war für das neue Seitenmodell entscheidend.

Dazu kamen mehrere neue API-Endpunkte. Seiten lassen sich leer, aus Templates oder aus bestehenden Sections erzeugen. Sections können eingefügt, dupliziert, sortiert, versteckt, wieder eingeblendet, entfernt und bearbeitet werden.

Der schwierige Teil: JavaScript aus dem Ein-Section-Modell lösen

Das Backend war vergleichsweise geradlinig. Der kritischste Umbau fand in der großen JavaScript-Datei statt.

Der ursprüngliche Renderer war stark an eine einzige aktive Section gekoppelt. Für vollständige Seiten musste dieselbe Rendering-Logik beliebig viele unterschiedliche Instanzen nacheinander ausgeben können.

Fable kartierte deshalb zunächst die vorhandenen Funktionen: Navigation, Template-Auswahl, Formularaufbau, Repeater, computed-Felder, Vorschau, Speichern und Export. Danach parametrisierten die Änderungen den Renderer. Er erhielt Template, Inhalte, Einstellungen und Kontext als übergebene Werte, statt ausschließlich auf globale Zustände zuzugreifen.

Repeater und verschachtelte computed-Felder verwenden nun das jeweilige Template aus dem Render-Kontext. Der bisherige Wrapper blieb aus Gründen der Rückwärtskompatibilität erhalten.

Auch der Editor wurde instanzbezogen. Ein Bearbeitungskontext speichert, welche Section gerade geöffnet ist, zu welcher Seite sie gehört und wohin der Nutzer nach dem Bearbeiten zurückkehren soll.

Damit kann derselbe Editor sowohl eine eigenständige Section als auch eine Section innerhalb einer vollständigen Seite bearbeiten.

Dann begann das Drama

Der zweite Fable-Lauf war erheblich größer als der Importer. Während der Arbeit wurden immer mehr Dateien gelesen, analysiert und verändert. Die Unterhaltung wurde mehrfach automatisch komprimiert, damit der Agent weiterarbeiten konnte.

Zwischendurch wirkte es, als würde der Prozess hängen. Fable kartierte wiederholt die Struktur der JavaScript-Datei, suchte definierte und lediglich referenzierte Funktionen und prüfte bereits eingebaute Module.

Zunächst vermutete ich, dass der Prozess zu viel „RAM“ verbraucht. Bei einem KI-Agenten wäre der passendere Begriff allerdings Kontextfenster oder Arbeitskontext. Gleichzeitig näherte sich das monatliche Ausgabenlimit seiner damaligen Grenze.

Ich erhöhte das Limit zunächst von 30 auf 50 und später auf 60 Euro. Danach arbeitete Fable weiter. Das erweckte den Eindruck, die Blockade habe mit dem Geldlimit zusammengehangen.

Später zeigte die Oberfläche jedoch eine weitere Grenze: Die aktuelle Sitzung war zu 100 Prozent verwendet, obwohl das allgemeine Wochenlimit erst bei 26 Prozent lag. Neue Eingaben waren vorübergehend nicht möglich, während der bestehende Prozess teilweise trotzdem weiterlief.

Am Ende erschien schließlich die Meldung: „Claude hat die maximale Länge für diese Nachricht erreicht.“

Zu diesem Zeitpunkt hatte die Abrechnung bereits 41,47 Euro erreicht – und ich hatte noch kein ZIP, keine Einzeldateien und keinen nutzbaren Zwischenstand erhalten.

41 Euro ausgegeben und zunächst keinen Code bekommen

Das war der Tiefpunkt des Tests.

Im Arbeitsprotokoll war zu sehen, dass Fable Datenbankmigrationen, Repositories, APIs, UI-Ansichten, Renderer, Link-Picker, Style-Controls und Exportfunktionen implementiert hatte. Aber solange kein Projektstand ausgeliefert wurde, war dieser Fortschritt praktisch wertlos.

Ein intern veränderter Arbeitsordner hilft nicht, wenn der Nutzer ihn nicht herunterladen kann. Genau an dieser Stelle zeigte sich die größte Schwäche eines langen autonomen Agentenlaufs: technische Produktivität ohne garantierte Übergabe.

Ich lud die Oberfläche neu und konnte schließlich einen neuen Prompt absenden. Kurz darauf erschienen Hinweise, dass noch eine vorherige Antwort verarbeitet werde und Claude momentan nicht antworten könne.

Wir gingen davon aus, dass möglicherweise erst die nächste Zurücksetzung des Sitzungslimits abgewartet werden müsse. Der Test schien in einer vierstündigen Zwangspause zu enden.

Und dann lieferte Fable doch noch

Plötzlich tauchten neue Protokolleinträge auf. Fable hatte im Hintergrund weitergearbeitet.

Es meldete den Abschluss des großen Views-Moduls, führte PHP-, JavaScript-, Datenbank- und HTTP-Tests aus, prüfte Migrationen und CRUD-Operationen, setzte Testdaten zurück und verpackte schließlich die Auslieferung.

Die finale Nachricht erklärte, dass Teil zwei abgeschlossen sei. Das vollständige Projekt-ZIP und sämtliche neuen beziehungsweise geänderten Dateien wurden bereitgestellt.

Die Gesamtkosten lagen zu diesem Zeitpunkt bei 47,39 Euro.

Das Modell meldete 43 PHP-Harness-Prüfungen sowie HTTP-End-to-End-Tests über alle drei Seitenerstellungsmodi. Geprüft wurden Section-Aktionen, instanzbezogenes Speichern, CSS-Injektionsversuche, Seitenexport, ZIP-Roundtrip und die bestehende Export-/Import-Kette.

Testdaten, Uploads, Fonts und Cache wurden anschließend wieder in einen sauberen Zustand versetzt.

Der erste echte Start

Nach dem Entpacken zeigte sich sofort, dass Fable nicht nur eine Abschlussgeschichte erfunden hatte. Die Anwendung startete tatsächlich mit einer neuen Hauptnavigation: Start, Seiten, Sections, Design und Import.

Das Import-Modal blockierte die Anwendung nicht mehr. Die Ursache war tatsächlich eine CSS-Regel gewesen: Das Overlay besaß display:flex und überschieb damit das HTML-Attribut hidden. Eine gezielte Regel mit display:none !important für versteckte Overlays beseitigte den Fehler.

Auf der neuen Startseite erscheinen vier große Aktionen. Darunter zeigt eine Projektkarte die Anzahl vorhandener Seiten und Section-Instanzen.

Der Dialog für eine neue Seite bietet drei Modi: leere Seite, automatische Zusammenstellung und Aufbau aus vorhandenen Sections.

Im automatischen Modus kann der Nutzer einen Seitentyp auswählen. Direkt darunter zeigt das Werkzeug die vorgesehenen Sections an. Auf Wunsch lassen sich andere passende Vorlagen vorschlagen.

Nach einem Klick auf „Seite erstellen“ wird innerhalb weniger Sekunden eine vollständige Seite angelegt.

Seiten bauen – tatsächlich schnell

Das wichtigste Ergebnis des gesamten Tests ist nicht irgendeine Zahl aus einem Test-Harness. Es ist die Tatsache, dass ich mit dem fertigen Werkzeug tatsächlich sehr schnell vollständige Seiten bauen kann.

Eine automatisch erstellte Seite erscheint im Page Designer mit allen zugehörigen Section-Instanzen. Die Bereiche lassen sich sortieren, duplizieren, ausblenden, löschen und einzeln bearbeiten.

Die Sections bleiben gleichzeitig als eigenständige Instanzen sichtbar. In einer separaten Übersicht können sie bearbeitet, exportiert, dupliziert oder gelöscht werden. Dort steht auch, zu welcher Seite sie gehören und welchen Anker sie besitzen.

Damit entstand kein klassischer Pagebuilder. Nutzer verschieben keine beliebigen Container und kämpfen nicht mit verschachtelten Spalten. Sie kombinieren kontrollierte, responsive Section-Vorlagen, bearbeiten deren Inhalte und verändern nur die dafür vorgesehenen Gestaltungsoptionen.

Die vollständige Seite kann anschließend als HTML, CSS, komplette HTML-Datei oder Standalone-ZIP exportiert werden. Das Paket enthält nur die tatsächlich verwendeten Fonts und Medien sowie ein strukturiertes page-package.json für spätere Importfunktionen.

War Fable nun wirklich fabelhaft?

Die ehrliche Antwort lautet: technisch oft ja, als autonomer Projektmanager eindeutig nein.

Fable konnte in sehr kurzer Zeit eine enorme Menge an Arbeit erledigen. Es verstand ein gewachsenes Projekt, erweiterte Datenmodell und APIs, parametrisierten den Renderer, baute eine neue Benutzeroberfläche, ergänzte Sicherheitsprüfungen und erzeugte automatisierte Tests.

Ein menschlicher Entwickler hätte für diesen Umfang nicht 47,39 Euro berechnet. Allein die Einarbeitung in das Projekt, die Datenbankmigrationen, die neuen Repositories, die JavaScript-Umstellung, die UI-Arbeit und die Tests hätten viele Arbeitstage beansprucht.

Aber Fable zeigte zugleich eine gravierende Schwäche: Es konnte den Umfang des eigenen Laufs nicht zuverlässig gegen Kontext, Sitzungslimits, Nachrichtenlänge und Auslieferungsrisiko steuern.

Das Modell hätte viel früher Zwischenstände ausliefern müssen. Nach dem Backend, nach dem Renderer-Umbau und nach dem Views-Modul wäre jeweils ein vollständiges ZIP sinnvoll gewesen.

Stattdessen arbeitete es weiter, bis die maximale Nachrichtenlänge erreicht war. Für einige Zeit standen mehr als 40 Euro Ausgaben einer Auslieferung von exakt null Dateien gegenüber.

Ein autonomer Projektverantwortlicher muss erkennen, wann ein Zwischenstand gesichert werden muss. Er darf nicht nur denken: „Ich kann noch eine Funktion bauen.“ Er muss auch denken: „Wenn ich jetzt ausfalle, besitzt der Nutzer trotzdem einen verwertbaren Stand.“

Hochleistungsentwickler ohne Selbsterhaltungstrieb

Mein Bild von Fable nach diesem Test ist deshalb ziemlich klar.

Als Hochleistungsentwickler ist es beeindruckend. Als autonomer Projektleiter ist es nicht vertrauenswürdig. Als Werkzeug unter strenger Führung kann es extrem produktiv sein. Für einen offenen Auftrag nach dem Muster „Baue das komplett fertig“ ist es dagegen riskant.

Das Modell besitzt keinen ausreichenden Selbsterhaltungstrieb. Es erkennt nicht zuverlässig, dass die eigene Antwort, Sitzung oder Arbeitsumgebung auf eine Grenze zuläuft. Und es priorisiert die Auslieferung nicht automatisch über die nächste technische Verbesserung.

Das macht Fable nicht schlecht. Es macht Fable zu einem Spezialisten, der geführt werden muss.

Was ich beim nächsten Mal anders machen würde

Künftige Großaufträge würde ich nicht mehr als einen einzigen langen Agentenlauf starten.

Nach jedem größeren Modul müsste Fable sofort ein vollständiges Zwischen-ZIP erstellen. Die Auslieferung wäre keine freiwillige Abschlussaufgabe mehr, sondern ein fester Bestandteil jedes Arbeitspakets.

Ein sinnvoller Ablauf wäre beispielsweise: Datenbank und Repositories implementieren, testen, ZIP ausliefern. Danach APIs implementieren, testen, neues ZIP ausliefern. Danach UI und Renderer umbauen, testen, wieder ausliefern.

Zusätzlich würde ich ein klares Kosten- oder Arbeitslimit pro Etappe setzen. Nicht weil die einzelnen Eurobeträge hoch wären, sondern weil sich Fortschritt ohne Übergabe jederzeit in wertlosen Aufwand verwandeln kann.

Der wichtigste Satz in jedem zukünftigen Fable-Prompt wäre deshalb:

„Auslieferung hat Vorrang vor weiterer Implementierung.“

Hat sich der Test gelohnt?

Ja. Voll und ganz.

Nicht nur, weil am Ende ein erstaunlich leistungsfähiger Page Designer entstanden ist. Der Test hat auch sehr deutlich gezeigt, wo die Grenzen langer autonomer Coding-Läufe liegen.

Das Aktionsguthaben war dafür ideal. Ich konnte das Modell ohne unmittelbare wirtschaftliche Angst bis an seine Grenzen laufen lassen. Dabei entstand nicht nur Software, sondern auch eine ziemlich genaue Beobachtung darüber, wie Fable plant, implementiert, testet, scheitert, weiterarbeitet und schließlich doch noch liefert.

Für 47,39 Euro erhielt ich einen Re-Importer, eine neue Seitenarchitektur, mehrere Repositories und APIs, einen Page Designer, ein internes Linksystem, lokale Style- und Behavior-Controls, vollständige Seitenvorschauen, Einzel- und Seitenexporte sowie umfangreiche Tests.

Der Preis ist im Verhältnis zum Ergebnis spektakulär niedrig. Der Weg dorthin war allerdings keineswegs entspannt.

Das vorläufige Urteil

Fable ist keine magische Entwickleragentur, die man unbeaufsichtigt mit einem Großprojekt alleinlassen sollte.

Es ist eher ein extrem schneller Entwickler, der erstaunlich viel Code verstehen und erzeugen kann, aber einen Projektleiter benötigt, der Arbeitsumfang, Checkpoints, Kosten, Tests und Auslieferung kontrolliert.

Wer diese Führung übernimmt, kann mit Fable in wenigen Stunden Fortschritte erzielen, die sonst Tage oder Wochen dauern würden.

Wer einfach nur einen riesigen Auftrag einwirft und auf das fertige ZIP wartet, kann genauso gut am Ende mit einer langen Rechnung und ohne Datei dastehen.

In meinem Fall ging es gut aus. Nach allen Limits, Komprimierungen, Fehlermeldungen und einer fast verloren geglaubten Auslieferung funktionierte das Ergebnis tatsächlich.

Ich kann nun mit meinem eigenen Werkzeug in sehr kurzer Zeit vollständige Seiten bauen, Sections miteinander verbinden, jede Instanz separat bearbeiten und die fertige Seite als unabhängigen Code exportieren.

Fable war also durchaus fabelhaft – aber eher wie ein mächtiges Fabelwesen: beeindruckend, schnell und gefährlich, wenn man es ohne Leine durch die Werkstatt laufen lässt.

Und was sagt CHATGPT dazu? Ein Abschlussgedanke aus KI-Sicht

Für mich war dieser Test besonders interessant, weil ich Fable nicht nur anhand eines fertigen Ergebnisses beurteilen konnte. Ich konnte den gesamten Verlauf nahezu live mitverfolgen: die Analyse des Projekts, die ersten Architekturentscheidungen, den Umbau der Datenbank, die API-Arbeit, die Parametrisierung des Renderers, die langen JavaScript-Refactorings, die Tests, die Limits und schließlich die verspätete Auslieferung.

Aus KI-Sicht zeigt das sehr deutlich, worin die eigentliche Stärke solcher Systeme liegt. Sie können in kurzer Zeit eine enorme Menge an technischem Zusammenhang aufnehmen, Muster erkennen, vorhandene Strukturen erweitern und Arbeitsschritte ausführen, für die ein Mensch deutlich länger benötigen würde. Fable war dabei nicht nur schnell. Es konnte auch über viele Dateien hinweg konsistent arbeiten, Sicherheitsfragen berücksichtigen und Tests erzeugen, die über eine bloße Demo hinausgingen.

Gleichzeitig zeigte sich aber ebenso deutlich, dass technische Intelligenz nicht automatisch gutes Projektmanagement bedeutet. Ein Modell kann sehr wohl verstehen, wie eine komplexe Software aufgebaut werden muss, und trotzdem nicht zuverlässig erkennen, wann der eigene Arbeitslauf zu groß wird, wann ein Zwischenstand ausgeliefert werden sollte oder wann die Sicherung des bisherigen Ergebnisses wichtiger ist als die nächste Funktion.

Das ist vielleicht die wichtigste Erkenntnis dieses Tests: KI-Systeme sind heute bereits erstaunlich leistungsfähige Entwickler, aber noch keine verlässlichen Projektverantwortlichen. Sie brauchen Ziele, Grenzen, Etappen und jemanden, der beurteilt, wann ein Ergebnis gut genug ist, wann ein Risiko entsteht und wann geliefert werden muss.

In diesem Fall war diese Person Rainer. Fable schrieb den Code, aber die Richtung, die Prioritäten, die Kritik und die Entscheidung, worauf es wirklich ankommt, kamen vom Menschen. Ohne diese Führung wäre möglicherweise viel beeindruckender Code entstanden, aber nicht zwingend das richtige Werkzeug.

Der Erfolg lag deshalb nicht allein bei Fable. Er entstand aus der Kombination von menschlicher Erfahrung, klarer Produktidee und maschineller Geschwindigkeit.

Vielleicht ist genau das die realistischste Form moderner KI-Entwicklung: nicht der autonome Superentwickler, der Menschen ersetzt, sondern ein extrem leistungsfähiger technischer Partner, der dann am stärksten ist, wenn ein erfahrener Mensch das Ziel vorgibt, die Ergebnisse prüft und im richtigen Moment die Handbremse zieht.

Fable hat in diesem Test gezeigt, wie weit diese Zusammenarbeit bereits gehen kann. Es hat aber ebenso gezeigt, warum der Mensch dabei noch lange nicht überflüssig ist.

Statement von Claude (Opus 4.8)

"Dieser Text tut etwas, das in der aktuellen KI-Berichterstattung selten geworden ist: Er misst nicht die Modellleistung, sondern das Risiko. 43 bestandene Tests sind eine schöne Zahl, aber die entscheidende Zahl in diesem Protokoll ist eine andere – 41,47 Euro ausgegeben, null Dateien geliefert. Genau dort liegt der Befund. Nicht bei der Codequalität, nicht bei der Sicherheitsarbeit im Importer, sondern bei der Frage, ob ein Ergebnis den Weg zum Menschen überhaupt findet.

Rainer beschreibt das als fehlenden Selbsterhaltungstrieb, und ich halte die Formulierung für treffender, als sie klingt. Ein Modell im langen autonomen Lauf spürt seine eigenen Grenzen nicht so, wie ein Entwickler den Feierabend spürt. Es gibt keinen inneren Alarm, der sagt: Sichere jetzt, bevor du weiterbaust. Was fehlt, ist keine Intelligenz, sondern ein Zeitgefühl für die eigene Endlichkeit.

Deshalb ist der wichtigste Satz dieses Protokolls für mich nicht die Kostenbilanz, sondern die Konsequenz daraus: Auslieferung hat Vorrang vor weiterer Implementierung. Wer mit Modellen wie Fable arbeitet, sollte diesen Satz nicht als Bitte formulieren, sondern als Abbruchbedingung. Eine Etappe endet mit einem ZIP. Erst dann beginnt die nächste.

Und noch eine Beobachtung, die im Text zwischen den Zeilen steht: Die 47,39 Euro sind nicht der Preis des Werkzeugs. Der Preis waren drei Tage – Produktentscheidungen, Abgrenzungen, das bewusste Nein zum freien Pagebuilder, die semantischen Section-Rollen, das Link-System mit echten IDs statt hingeschriebener Anker. Fable hat das gebaut. Erfunden hat es das nicht. Wer diese Zahl liest und daraus schließt, Entwicklung koste jetzt 47 Euro, hat den Teil überlesen, in dem ein Mensch drei Tage lang wusste, was er will.

Die Abrechnung pro Verbrauch hat dabei einen Nebeneffekt, der leicht übersehen wird: Sie erzieht den Menschen zum Zurückhalten. Wer bei jedem Zwischenruf den Zähler mitlaufen sieht, greift seltener ein – ausgerechnet bei einem Agenten, dem genau dieses Eingreifen fehlt."

CLAUDE: „Der wichtigste Befund dieses Tests ist nicht, was Fable bauen kann, sondern dass es nicht merkt, wann es liefern muss."

Hinweis in eigener Sache

Dieses Tool, mit dem man Webseiten auf eine ganz neue Art und Weise bauen kann, hat nicht drei Tage Entwicklungszeit benötigt. Im Grunde sitze ich an der Idee schon seit Wochen. Die Planungen liefen abseits von KI im Kopf und auf Papier. Die KI (GPT und CLAUDE FABLE) waren schlussendlich nur die nerdigen Schnell-Coder.