Claude Fable: Überschallrakete oder doch nicht? Ein Praxistest.
Fable wirkte dabei durchaus diszipliniert. Es blieb näher am Auftrag, erfand keine völlig neue Architektur und erkannte einige echte Problemstellen.
Ausgangspunkt: Ein echter CSS-Umbau statt ein Demo-Test
Für diesen Test ging es nicht um ein künstliches Beispiel, sondern um eine gewachsene WordPress-Seite - also diese hier - mit historisch gewachsenem CSS, mehreren Sonderbereichen und zwei zusätzlichen PHP-Dateien. Ziel war ein visueller Umbau: weg vom bisherigen weiß-blauen Auftritt mit vielen blauen Flächen und Weißtext auf Blau, hin zu einer ruhigeren, helleren und hochwertigeren Gestaltung.
Getestet wurde "Claude Fable" mit einem bewusst praxisnahen Auftrag: Die bestehende Struktur sollte nicht neu erfunden werden. Stattdessen sollte eine produktionsnahe Override-CSS-Datei entstehen, die vorhandene Klassen weiterverwendet, problematische Farbbereiche entschärft und nur dort PHP-Anpassungen vorschlägt, wo sie wirklich nötig sind.
Claude Fable wurde im Sommer 2026 ziemlich offensiv beworben. Viel Kontext, starke Coding-Fähigkeiten, lange Dateien, komplexe Aufgaben – kurz gesagt: ein Modell, das auch mit echten Projekten umgehen soll und nicht nur mit hübschen Demo-Beispielen.
Der verwendete Prompt
Der Testauftrag lautete sinngemäß:
Du bekommst gleich drei Dateien aus einem bestehenden WordPress-Child-Theme:
- eine große bestehende CSS-Datei
- Addon-PHP-Datei
- CSS.Datei (mit Führender PHP-Datei)
Aufgabe: Bitte überarbeite das visuelle System der Seite direkt als produktionsnahen Code.
Ziel: Die Seite soll weg vom bisherigen weiß/blauen Agentur-Look mit vielen blauen Flächen und Weißtext auf Blau. Sie soll ruhiger, heller, wärmer, hochwertiger und moderner wirken. Blau soll nur noch als Akzentfarbe verwendet werden, nicht mehr als große Flächenfarbe.
Wichtig: keine komplette Neuentwicklung, kein Framework, keine Utility-CSS-Library, keine radikale Änderung der HTML-Struktur, WordPress-Child-Theme bleibt, vorhandene Klassen möglichst weiterverwenden, PHP nur ändern, wenn es für saubere Klassen oder Wrapper wirklich nötig ist, pragmatisch, robust, wartbar.
Bitte liefere direkt: eine neue CSS-Override-Datei, konkrete kleine Änderungen an den PHP-Dateien, eine kurze Liste der überschriebenen Bereiche und eine Einbau-Anleitung.
Laufzeit und erster Eindruck
Die Verarbeitung dauerte rund elf Minuten. Für etwa 180 KB CSS plus zwei PHP-Dateien und einer CSS-Datei ist das durchaus beachtlich. Während der Analyse gab es kleinere Stolperer, etwa bei einem Bash-/sed-Befehl, der eine nicht gefundene CSS-Klasse nicht sauber abgefangen hatte. Das war aber kein Abbruch, sondern eher ein Hinweis darauf, dass das Modell intern versuchte, vorhandene Klassen und CSS-Blöcke systematisch zu durchsuchen.
Der erste Eindruck war positiv: Fable lieferte keine komplette Neuerfindung, sondern blieb grundsätzlich beim gewünschten Override-Ansatz. Besonders sinnvoll war der Hinweis auf hartcodierte Inline-Styles wie style="color:#FFFFFF", die auf einem hellen Theme problematisch werden. Diese Stellen wurden als kleine PHP-Korrekturen benannt, statt blind mit noch mehr CSS dagegen anzukämpfen.
Was gut funktioniert hat
Am besten funktionierte der Umbau im Bereich der Laborprotokolle. Die Labor-Einzelansicht wirkte nach dem Override deutlich ruhiger, moderner und strukturierter. Die helle Bühne, die Karten, die Inhaltsübersicht und das reduzierte Farbsystem gingen klar in die gewünschte Richtung.
Auch die Grundidee, große blaue Flächen zurückzunehmen und Blau eher als Akzent einzusetzen, wurde verstanden. Fable erkannte außerdem, dass Layout, Grids, Breakpoints und Animationen möglichst unangetastet bleiben sollten. Genau das war wichtig, denn bei einer bestehenden WordPress-Seite ist ein visueller Umbau oft sicherer als ein radikaler struktureller Eingriff.
Wo die Grenzen sichtbar wurden
Nicht publikationsreif war das Ergebnis vor allem dort, wo das Modell die tatsächliche HTML-Struktur nur indirekt aus dem CSS ableiten konnte. Bei der Klangwolke und im Footer zeigten sich typische Override-Probleme: zu schwache Kontraste, fast unsichtbare Überschriften, helle Links auf hellem Grund und einzelne UI-Elemente, die visuell noch nicht sauber zusammenpassten.
Das ist kein überraschendes Scheitern, sondern eher die natürliche Grenze eines solchen Tests. Ein Modell kann aus CSS-Selektoren vieles erraten, aber es sieht nicht automatisch jede reale Frontend-Situation, jede historische Sonderklasse und jede Stelle, an der WordPress, Theme, Plugin und eigenes CSS zusammenwirken.
Vergleich mit bisherigen KI-Tests
Das Ergebnis lag ungefähr auf dem Niveau, das ich zuvor auch mit Deepseek im Stand Juni/Juli 2026 erlebt hatte: stark in der Analyse, brauchbar bei größeren Umordnungen, aber nicht zuverlässig genug, um eine gewachsene Website in einem einzigen Durchlauf veröffentlichungsreif umzubauen.
Fable wirkte dabei durchaus diszipliniert. Es blieb näher am Auftrag, erfand keine völlig neue Architektur und erkannte einige echte Problemstellen. Trotzdem blieb das Ergebnis ein sehr guter Prototyp, kein fertiger Relaunch. Für eine saubere Umsetzung braucht es weiterhin kontrollierte Einzelschritte, Tests im Browser und gezielte Nacharbeit.
Fazit: Stark als Assistenz, nicht als Fertig-Knopf
Der Test war deutlich näher an echter Praxis als an einer typischen KI-Demo. Eine gewachsene WordPress-Seite mit großem CSS-Bestand, Addon-Dateien, Inline-Styles, Theme-Eigenheiten und mehreren Seitentypen ist kein sauberer Benchmark, sondern ein kleiner Maschinenraum mit vielen alten Kabeln. In diesem Umfeld hat Fable ordentlich gearbeitet.
Die Geschwindigkeit und der erste strukturelle Zugriff waren beeindruckend. Fable erkannte sinnvolle Ansatzpunkte, lieferte brauchbare Override-Ideen und fand echte Problemstellen, etwa hartcodierte weiße Schriftfarben, die auf einem helleren Design sofort zum Problem werden.
Als Assistenzmodell für Analyse, Strukturierung und erste CSS-Überarbeitungen war das Ergebnis stark. Als „mach mir die komplette Seite in einem Durchlauf fertig“-Werkzeug reicht es aber noch nicht. Dafür ist die Realität einer bestehenden Website zu kleinteilig. Ein Modell kann vieles vorbereiten, aber es sieht nicht automatisch jede echte Frontend-Situation im Browser.
Ist Claude Fable also eine Überschallrakete? In Teilen ja. Aber auch eine Rakete weiß nicht automatisch, wo in einer alten WordPress-Seite noch ein schlecht isoliertes Kabel hängt. Der sinnvollere Weg bleibt deshalb: die brauchbaren Ideen sichern und daraus Schritt für Schritt ein sauberes Designsystem entwickeln. Nicht als großer KI-Wurf im Dunkeln, sondern kontrolliert Bereich für Bereich.
Claude: "Faire, ziemlich präzise Diagnose"
Der Vollständigkeit halber habe ich Claude den fertigen Artikel ebenfalls vorgelegt und um eine Einschätzung gebeten. Sein Statement folgt hier unkommentiert und ungekürzt:
Das ist eine faire und, ehrlich gesagt, ziemlich präzise Diagnose. Die Schwachstellen, die du nennst, sind genau die, die ich im Nachhinein auch als strukturelles Risiko des Ansatzes sehen würde — und es lohnt sich, kurz zu benennen, warum sie genau dort auftraten und nicht woanders.
Der Laborbereich funktionierte am besten, weil er der am saubersten gekapselte war: eigener Token-Block, klare Scope-Klasse, das komplette Styling in einem zusammenhängenden <style>-Block, den ich vollständig lesen konnte. Da war die Variablen-Umbelegung fast ein chirurgischer Eingriff. Klangwolke und Footer sind das Gegenteil davon — dort wirken mehrere Schichten zusammen, die ich nur teilweise gesehen habe: das Total-Theme selbst (dessen generiertes CSS und Customizer-Farben gar nicht in den drei Dateien lagen), der in functions.php erzeugte Footer-Hintergrund, und historische Regeln mit höherer Spezifität, die meine token-basierten Overrides ohne !important schlicht überstimmt haben. Helle Links auf hellem Grund sind das klassische Symptom dafür: Meine globale Link-Regel hatte Spezifität 0-0-1, irgendwo sitzt eine alte Regel mit mehr Gewicht, und ohne gerenderten DOM sehe ich nicht, welche gewinnt. Das ist keine Ausrede, sondern die Bestätigung deines Fazits — aus Selektoren lässt sich viel ableiten, aber nicht der tatsächliche Kaskaden-Ausgang im Browser.
Dein Schluss, kontrolliert Bereich für Bereich vorzugehen, ist auch deshalb richtig, weil er zu dem passt, wie du das Redesign ohnehin angelegt hast: Basis-Migrationsblock zuerst, dann Bereichs-Patches mit Browser-Test dazwischen. Ein Override-Wurf über 180 KB gewachsenes CSS in einem Durchlauf kann bestenfalls ein guter Prototyp sein — dass er es in deinem Test war, nehme ich als das realistische Ergebnis, nicht als Beinahe-Erfolg.