Anthropic hat gerade das stärkste Modell veröffentlicht, das es je gebaut hat – und der Benchmark-Sprung ist fast der uninteressanteste Teil.
Claude Fable 5.1 fühlt sich weniger wie ein besserer Chatbot an und mehr wie eine neue Art von Operator. Es kann stundenlang an einem Problem sitzen, sich erholen, wenn ein Plan scheitert, andere Agenten koordinieren, seine eigene Ausgabe überprüfen und weitermachen, ohne dass alle zehn Minuten jemand zur Rettung kommen muss.
Die Zahlen untermauern das. In Anthropics veröffentlichten Evaluierungen hat Fable 5.1 Fable 5 bei der agentischen wissenschaftlichen Forschung mehr als verdoppelt, ist bei der Geschäftsautomatisierung von 17,1 % auf 31,4 % gestiegen und hat bei CursorBench 73,4 % erreicht. Es lag auch bei den meisten von Anthropic gemeldeten Tests zu Programmierung, Automatisierung, Computernutzung und Wissensarbeit vor Fable 5, Opus 5 und GPT-5.6 Sol.
https://x.com/claudeai/status/2094848581425377479
Out of the Box ist es außergewöhnlich gut bei schwieriger Programmierung, langfristigen Arbeiten, Recherche, Planung, Computernutzung und der Erstellung vollständiger Ergebnisse. Die größere Chance liegt jedoch darin, was passiert, wenn man es nicht mehr als die Person einsetzt, die jede Aufgabe erledigt, sondern es mit der Leitung des Systems beauftragt, das die Arbeit erledigt.
Genau das behandelt dieser Kurs: wo Fable 5.1 wirklich anders ist, wie man es in die Führungsrolle setzt, wie man die Arbeiter darunter aufbaut, wie man es promptet, ohne es zu ersticken, wie man Ziele und Schleifen einsetzt, und die fünf Workflows, bei denen der Unterschied zu echtem Geld werden kann.
Wenn Sie sich nicht für Terminals, Agentendateien und Orchestrierung interessieren und einfach nur eine Idee in eine funktionierende App verwandeln wollen, dafür haben wir Shipper gebaut.
Worin dieses Modell wirklich außergewöhnlich ist
Bevor es an die Methoden geht, lernen Sie die Maschine kennen. Dies sind die fünf Fähigkeiten, die Fable 5.1 anders erscheinen lassen als die Modelle davor.
Es bleibt über absurd lange Läufe kohärent
Geben Sie ihm einen Job, der Stunden dauert, und es verliert viel seltener die Orientierung auf halbem Weg.
Ein früher Tester berichtete von einem unbeaufsichtigten 38-stündigen maschinellen Lernlauf, bei dem Fable ein schlechtes früheres Ergebnis diagnostizierte, es korrigierte, sechs Experimente parallel startete und mit den Ergebnissen und nächsten Schritten zurückkam. Ein anderer sagte, es habe eigene Aufzeichnungen geführt, Prioritäten neu gesetzt, als sich die Bedingungen änderten, und an der Stelle weitergemacht, wo es aufgehört hatte.
Das 1-Millionen-Token-Kontextfenster hilft, aber die Kontextgröße ist nicht die eigentliche Verbesserung. Die Verbesserung ist, dass das Modell innerhalb dieses Kontextes weiterhin nützliche Entscheidungen treffen kann, anstatt sich nur zu merken, dass die Informationen existieren.
Es sucht nach der Grundursache, nicht nach dem schnellsten Patch
Frühere Agenten fanden oft die erste Lösung, die einen Fehler verschwinden ließ. Fable 5.1 ist eher bereit, weiterzugraben, bis es versteht, warum der Fehler existierte.
In Anthropics Launch-Tests gab Millennium ihm einen Absturz, der etwa einmal in einer Million Läufen auftrat und vier bis fünf Jahre lang ungeklärt geblieben war. Fable 5.1 zerlegte eine externe Bibliothek, verband sie mit dem Core Dump und führte den Absturz auf den eigentlichen Bug zurück. Jedes andere Modell, das sie ausprobiert hatten, einschließlich Fable 5, hatte ihn übersehen.
Das ist weit über das Debuggen hinaus relevant. Derselbe Instinkt zeigt sich in Forschung, Strategie, Finanzanalyse und Betrieb: Optimiere nicht das Symptom, wenn das zugrundeliegende System falsch ist.
Es kann sehen, handeln und verifizieren
Fable 5.1 kann Screenshots, Diagramme, PDFs, Oberflächen und Dokumente inspizieren und dann das Gesehene nutzen, um die nächste Aktion zu leiten.
Das bedeutet, es kann eine Oberfläche anhand von Referenzen neu aufbauen, die in einem Finanzdokument versteckten Zahlen lesen, einen Browser bedienen, seine Implementierung mit dem ursprünglichen Design vergleichen und visuelle Probleme erkennen, bevor es behauptet, die Arbeit sei abgeschlossen.
Sein OSWorld-Computer-Use-Score stieg in Anthropics Tests über den von Fable 5 und Opus 5. Noch wichtiger ist, dass das Modell zunehmend in der Lage ist, Vision als Teil einer Verifizierungsschleife einzusetzen, nicht nur, um das Bild zu beschreiben, das Sie ihm gegeben haben.
Es gibt die Arbeit zurück, nicht einen Vortrag über die Arbeit
Geben Sie ihm einen Ordner mit Dokumenten und bitten Sie um ein Investment-Memo, eine Präsentation, einen funktionierenden Prototyp oder eine Analyse, und es gibt viel eher das Artefakt selbst zurück.
Frühe Tester berichteten von Anthropics besten PowerPoint-Ergebnissen, stärkerem Zitationsabruf über Finanzdokumente, präziseren Vertragsredlines und einer besseren Erledigung komplizierter, mehrteiliger Anfragen. Ein MongoDB-Ingenieur beschrieb einen dreitägigen Prototypenlauf, bei dem das Modell die bestehenden Dienste recherchierte, das System entwarf, es in unbeaufsichtigten Phasen implementierte und visuelle Durchläufe mit Beweisen dafür zurückgab, dass jede Phase funktionierte.
Der praktische Unterschied ist einfach: Sie verbringen weniger Zeit damit, eine Antwort in brauchbare Arbeit umzuwandeln.
Es wurde gebaut, um zu führen
Fable 5.1 ist am wertvollsten, wenn es entscheidet, was als nächstes passieren soll.
Claude Code kann ihm bereits Subagenten, Hintergrundsitzungen, Agententeams, dynamische Workflows, Ziele, Schleifen, Browser, Terminals und Projektdateien geben. Fable hat genug Planungstiefe und Kontext, um diese Teile viel länger auf eine Ziellinie auszurichten, als es frühere Modelle konnten.
Deshalb funktioniert das untenstehende Setup, und deshalb beginnt der Kurs damit, Fable aus der Arbeiterrolle zu nehmen.
Das Cockpit: Jedes Steuerelement, das Sie wirklich brauchen
Aktualisieren Sie Claude Code, bevor Sie etwas anderes tun. Laut der aktuellen Model-Konfigurationsdokumentation lässt Version 2.1.255 oder höher den Fable-Alias auf Fable 5.1 auflösen, und neuere Versionen enthalten die unten verwendeten Steuerelemente für Ziel, Schleife, Hintergrundagent und Aufwand.
Wählen Sie dann das Modell und die Aufwandsstufe:
/model fable
/effort high
High ist die sinnvolle Standardeinstellung für umfangreiche Arbeiten. Reduzieren Sie auf medium für günstigere, schnellere Durchläufe. Gehen Sie nur auf xhigh oder max, wenn das Problem schwierig genug ist, um mehr Denkarbeit zu rechtfertigen. Fables adaptives Denken ist immer aktiv, daher ist der Aufwand das entscheidende Steuerelement.
Die restlichen Steuerelemente sind einfach:
/plan oder Shift+Tab: Lassen Sie es inspizieren und planen, bevor es Dateien ändert
/goal: Arbeiten Sie über mehrere Runden hinweg weiter, bis eine überprüfbare Bedingung erfüllt ist
/loop: Führen Sie eine Eingabeaufforderung nach einem Zeitplan erneut aus, solange die Sitzung aktiv ist
/tasks: Sehen Sie, was die Hintergrundarbeiter tun
/context: Sehen Sie, was das Kontextfenster verbraucht
Das ist das Cockpit.
Der Rest des Kurses besteht darin, zu wissen, zu welchem Steuerelement man greift – und wann.
Das Hauptereignis: Machen Sie Fable zum Leiter, nicht zum Arbeiter
Das mit Abstand größte Upgrade ist ein Rollenwechsel.
Hören Sie auf, Fable jede Tastaturaufgabe zu geben. Lassen Sie es die Arbeit definieren, in saubere Bahnen aufteilen, diese Bahnen an günstigere Agenten senden und beurteilen, was zurückkommt.
Das Setup sieht so aus:
<strong>Fable formt den Plan:</strong>
Versetzen Sie es in den Plan-Modus und lassen Sie es das Projekt inspizieren, bevor es Änderungen vorschlägt. Wenn die Anfrage noch vage ist, verwenden Sie Matt Pococks
Skills-Sammlung , um die Idee zu hinterfragen, das Gespräch in ein Pflichtenheft zu verwandeln und das Pflichtenheft in Tickets aufzuteilen.
<strong>Fable delegiert die isolierte Arbeit:</strong>
Die Implementierung geht an Opus- oder Sonnet-Subagenten, wobei jeder Arbeiter eine abgegrenzte Spur besitzt. Codex kann ein weiterer Arbeiter sein, wenn Sie es bereits verwenden, sollte aber denselben Dateigrenzen und Beweisregeln folgen.
<strong>Ein separater Agent verifiziert:</strong>
Der Arbeiter benotet nicht seine eigenen Hausaufgaben. Ein frischer Prüfer liest den Plan, inspiziert das Diff, führt die Checks durch und gibt entweder die Phase frei oder gibt sie mit einem konkreten Fehler zurück.
<strong>Sie steuern an Kontrollpunkten:</strong>
Genehmigen Sie den Plan, überprüfen Sie sinnvolle Abwägungen und inspizieren Sie die Beweise am Ende. Sie müssen nicht jeden Befehl beobachten.
Warum das funktioniert: Das teure Modell gibt seine Tokens für Architektur, Priorisierung, Wiederherstellung und Beurteilung aus. Die günstigeren Modelle geben ihre für abgegrenzte Ausführung aus.
Die Wirtschaftlichkeit funktioniert nur, wenn die Spuren wirklich unabhängig sind. Unter Anthropics aktueller API-Preisgestaltung kostet Fable 5.1 10 $ pro Million Input-Token und 50 $ pro Million Output-Token, während Opus 5 die Hälfte und Sonnet 5 ein Fünftel kostet. Fable 5.1 hat auch Cache-Reads auf 0,25 $ pro Million Token gesenkt, was lange Sitzungen mit einem stabilen Projektkontext viel praktikabler macht.
Parallelisieren Sie nicht um der Show willen. Fünf Agenten, die dieselben Dateien bearbeiten, erzeugen fünf Rechnungen und ein Merge-Problem. Parallelisieren Sie Recherche, isolierte Module, Tests, Dokumentation und andere Spuren, die abgeschlossen werden können, ohne aufeinander warten zu müssen.
Bauen Sie Ihre Arbeiter
Der Leiter braucht ein kleines Team, und ein benutzerdefinierter Arbeiter ist nur eine Markdown-Datei in .claude/agents/.
Beginnen Sie mit einem Implementierungsarbeiter:
name: implementation-worker
description: Implementiert eine isolierte Phase aus einem genehmigten Plan. Nur verwenden, wenn die Phase eigene Dateien besitzt.
model: opus
tools: Read, Grep, Glob, Edit, Write, Bash
maxTurns: 25
Sie besitzen nur die Ihnen zugewiesene Phase.
Identifizieren Sie vor dem Bearbeiten die genauen Dateien und Akzeptanzkriterien in Ihrer Spur.
Ändern Sie keine Dateien, die einem anderen Arbeiter gehören.
Implementieren Sie die kleinste vollständige Lösung und führen Sie dann die relevanten Tests aus.
Geben Sie zurück:
- geänderte Dateien
- durchgeführte Prüfungen und deren tatsächliche Ausgabe
- alles, was noch unsicher ist
Erklären Sie keinen Erfolg ohne Beweise aus diesem Lauf.
Erstellen Sie dann den Arbeiter, der am wichtigsten ist, den Prüfer:
name: verifier
description: Verifiziert unabhängig eine abgeschlossene Phase anhand ihres Plans und ihrer Akzeptanzkriterien. Nach jeder Implementierungsphase verwenden.
model: opus
tools: Read, Grep, Glob, Bash
maxTurns: 15
Behandeln Sie die Implementierungszusammenfassung als eine nicht vertrauenswürdige Behauptung.
Lesen Sie den Plan und inspizieren Sie das tatsächliche Diff. Führen Sie die relevanten Tests selbst durch.
Überprüfen Sie Korrektheit, Regressionen, Umfang und jedes Akzeptanzkriterium.
Geben Sie BESTANDEN oder NICHT BESTANDEN zurück.
Fügen Sie bei jedem Fehlschlag die Beweise und die kleinste erforderliche Korrektur bei.
Ändern Sie niemals die Implementierung, die Sie bewerten.
Frische Augen erkennen, was der Autor normalisiert hat. Eine sofort überprüfte Phase ist viel billiger als ein Fehler, der entdeckt wird, nachdem vier weitere Phasen davon abhängen.
Vier Regeln halten das Team schnell:
ein Arbeiter, eine Spur, mit explizitem Dateibesitz
parallele Arbeit nur, wenn die Spuren nicht voneinander abhängen
Fable bleibt in der Führungsrolle, während Opus oder Sonnet die Arbeit erledigt
jede Behauptung der Fertigstellung wird anhand der Dateien, Tests oder des Live-Ergebnisses überprüft
Geheimnis 1: Schreiben Sie nicht die Route vor
Die meisten Prompting-Ratschläge wurden geschrieben, um schwächere Modelle vom Umherirren abzuhalten.
Lange Prozeduren, starre Schrittlisten und riesige Regelblöcke halfen, als das Modell nicht planen konnte. Bei Fable 5.1 kann dasselbe Gerüst es auf einen schlechteren Weg zwingen als den, den es selbst gefunden hätte.
Der Trick ist, streng beim Ziel und locker bei der Route zu sein.
Geben Sie ihm vier Dinge:
<strong>das Ergebnis:</strong>
was existieren muss, wenn die Arbeit erledigt ist
<strong>die Einschränkungen:</strong>
was es nicht kaputt machen, ausgeben, offenlegen oder ändern darf
<strong>den Grund:</strong>
für wen das ist und welche Entscheidung oder Aufgabe das Ergebnis unterstützen muss
<strong>den Beweis:</strong>
welche beobachtbaren Belege als fertig gelten
Dieser letzte Teil ändert alles. „Mach den Checkout zum Laufen" lädt zu einer plausiblen Behauptung ein. „Führe einen Testkauf in der Sandbox durch und zeige die resultierende Bestellzeile" gibt dem Modell eine Ziellinie, um die es sich nicht herumreden kann.
Bitten Sie nicht um eine Vorführung versteckter Gedankenketten. Bitten Sie um den Plan, die wichtigen Entscheidungen, die Beweise und die verbleibende Unsicherheit. Fables Denken ist bereits immer aktiv. Was für Sie zählt, ist, ob das Ergebnis einer Überprüfung standhält.
Und erinnern Sie es nicht ständig daran, dass das Budget schwindet. Setzen Sie die Grenze stattdessen im System: Begrenzen Sie die Arbeiterrunden, definieren Sie die erlaubten Ausgaben und sagen Sie ihm, was zu tun ist, wenn das Limit erreicht ist.
Geheimnis 2: Halten Sie CLAUDE.md leicht
CLAUDE.md wird zu Beginn jeder Claude Code-Sitzung geladen. Das macht es nützlich, aber es bedeutet auch, dass jede irrelevante Zeile jede zukünftige Aufgabe belastet.
Anthropic empfiehlt jetzt, jede Datei unter 200 Zeilen zu halten. In der Praxis kann Ihre normalerweise viel kürzer sein.
Drei Abschnitte decken die meisten Projekte ab:
<strong>was dieses Projekt ist:</strong>
das Produkt, die Architektur und wichtige Grenzen
<strong>wie man Arbeit verifiziert:</strong>
die Befehle für Build, Test, Lint und lokale Vorschau
<strong>was es immer wieder falsch macht:</strong>
projektspezifische Konventionen und wiederkehrende Fehler
Prozeduren, die nur manchmal wichtig sind, gehören in Skills. Regeln, die nur für bestimmte Dateien gelten, gehören in pfadbezogene Regeln. Historische Notizen gehören in die Dokumentation, nicht in den Prompt jeder Sitzung.
Öffnen Sie heute Abend Ihre CLAUDE.md und stellen Sie jede Zeile in Frage: Wenn das Entfernen keinen echten Fehler verursachen würde, entfernen Sie sie.
Die leichtere Datei ist normalerweise die stärkere.
Geheimnis 3: Missbrauchen Sie Ziele und Schleifen
Hier hört Fable auf, ein Gespräch zu sein, und wird zu einem Prozess, der sich weiterbewegen kann, während Sie etwas anderes tun.
Ziele: /goal gibt der Sitzung eine überprüfbare Abschlussbedingung. Nach jeder Runde prüft ein separates kleines Modell, ob die Bedingung erfüllt ist. Wenn nicht, beginnt Fable eine weitere Runde, anstatt die Kontrolle an Sie zurückzugeben. Das Ziel endet, wenn es bestanden wird, unmöglich wird, auf einen nicht behebbaren Fehler stößt oder Sie es löschen.
Die Kunst besteht darin, eine Ziellinie zu schreiben, die es nicht vortäuschen kann:
fordern Sie beobachtbare Beweise: „Alle Auth-Tests bestehen und die Ausgabe ist angehängt" ist stärker als „Auth reparieren"
definieren Sie den Fehlerpfad: Wenn ein echter Blocker das Ziel unmöglich macht, melden Sie den Blocker und die Beweise, anstatt Fortschritt zu erfinden
begrenzen Sie die riskanten Teile: Verwenden Sie maxTurns für Arbeiter, Ausgabenlimits für kostenpflichtige Dienste und explizite Grenzen für Bereitstellungen oder Produktionsdaten
behalten Sie eine Ehrlichkeitsregel in jeder Kurzbeschreibung: Jede Fortschrittsbehauptung muss auf ein Ergebnis verweisen, das während dieses Laufs erzeugt oder überprüft wurde
Führen Sie Ziele im Automatikmodus nur innerhalb von Grenzen aus, mit denen Sie sich wohlfühlen, sie unbeaufsichtigt zu lassen. Ein intelligenterer Agent hat einen größeren Schadensradius, wenn die Kurzbeschreibung falsch ist.
Schleifen: /loop führt eine Eingabeaufforderung in einem Intervall erneut aus. Verwenden Sie /loop 15m, um die Bereitstellung in einem festen Rhythmus zu überprüfen und jeden Fehler zu untersuchen, oder lassen Sie das Intervall weg und lassen Sie Claude entscheiden, wann er erneut prüft.
Schleifen innerhalb von Claude Code sind sitzungsbezogen und laufen irgendwann ab. Verwenden Sie sie für Builds, Pull Requests, Migrationen und temporäre Überwachung. Verwenden Sie eine persistente Routine oder einen geplanten Desktop-Task für Arbeiten, die über das Ende der Sitzung oder des Rechners hinaus bestehen bleiben müssen.
Zwischen Zielen und Schleifen können Sie Fable so lange arbeiten lassen, wie der Job es wirklich erfordert, mit Beweisen, die am Ende warten, anstatt eines weiteren selbstbewussten Absatzes.
Wie man ein echtes Projekt in einem Durchgang erstellt
Bauen Sie nun das gesamte System um einen einzigen Build herum auf.
Das Beispiel ist eine Landing Page mit einer funktionierenden Warteliste. Ersetzen Sie das Projekt, und dieselbe Sequenz gilt.
Schritt 1: Schreiben Sie die Kurzbeschreibung
Senden Sie eine Nachricht:
Ich bringe [Produkt] für [Zielgruppe] auf den Markt. Sie brauchen eine Landing Page, die ein klares Versprechen macht und
E-Mails erfasst.Bauen Sie eine responsive Seite mit einem funktionierenden Formular, das Anmeldungen speichert.Einschränkungen: kein Framework, das ich betreuen muss, keine kostenpflichtige Abhängigkeit, schnell auf Mobilgeräten und keine Bereitstellung, bis ich sie genehmige.Fertig bedeutet, die Seite läuft lokal, eine Test-E-Mail erscheint im Speicher, das mobile Layout ist bei 390px verifiziert und das Ergebnis wird mit Testausgabe und Screenshots gezeigt.Inspizieren Sie das Projekt und planen Sie zuerst. Delegieren Sie nur unabhängige Phasen. Verifizieren Sie jede abgeschlossene Phase.
Die Kurzbeschreibung gibt ihm ein Ziel, ohne die Implementierung in seinem Namen zu entwerfen.
Schritt 2: Genehmigen Sie den Plan
Wechseln Sie mit /plan oder Shift+Tab in den Plan-Modus, bevor es etwas ändert.
Wenn die Idee unterspezifiziert ist, installieren Sie Matt Pococks Sammlung mit /plugin install mattpocock-skills, führen Sie /setup-matt-pocock-skills einmal aus und verwenden Sie /grill-with-docs, bevor Sie das Ergebnis in ein Pflichtenheft verwandeln.
Lesen Sie den Plan. Streichen Sie die Funktionen, die Sie nicht brauchen. Stellen Sie sicher, dass jede Phase eine beobachtbare Bestehensbedingung hat. Genehmigen Sie ihn dann.
Schritt 3: Lassen Sie das Team arbeiten
Fable weist die erste isolierte Phase dem Implementierungsarbeiter zu. Der Prüfer überprüft das tatsächliche Diff und die Testausgabe. Eine abhängige Phase beginnt erst, nachdem die vorherige bestanden wurde.
Sie können das Terminal verlassen. Verwenden Sie /tasks, wenn Sie sehen wollen, was noch läuft.
Schritt 4: Setzen Sie die Ziellinie
Verwenden Sie ein Ziel, das den Zustand und den Beweis benennt:
/goal die Seite läuft lokal, das Formular speichert eine Testanmeldung und das Layout funktioniert bei 390px, nachgewiesen durch die tatsächliche Testausgabe, den gespeicherten Datensatz und einen aktuellen Screenshot. Wenn ein echter Blocker dies unmöglich macht, stoppen Sie und melden Sie die Beweise, anstatt Erfolg zu behaupten.
Diese Bedingung ist mit Worten allein viel schwerer zu erfüllen.
Schritt 5: Überprüfen Sie das Ergebnis
Kommen Sie zurück zum Diff, der Testausgabe, der gespeicherten Anmeldung und den Screenshots.
Überprüfen Sie das Produkt wie ein Benutzer, nicht wie der Manager des Modells. Bitten Sie um die Änderungen, die Sie tatsächlich sehen können, führen Sie einen letzten unabhängigen Verifizierungsdurchlauf durch und liefern Sie aus, wenn die Beweise mit der Kurzbeschreibung übereinstimmen.
Der erste Durchlauf wird sich aufwändig anfühlen.
Beim zweiten Mal werden Sie feststellen, dass dieselbe Sequenz für fast jedes Projekt funktioniert, das Sie aufgeschoben haben.
Die fünf Workflows, bei denen es echtes Geld bringt
Richten Sie nun das Setup auf Arbeiten aus, die wertvoll genug sind, um das Modell zu rechtfertigen.
Dies sind die fünf Workflows, bei denen Fable 5.1 einen messbaren Unterschied machen kann.
Der Codebase-Job, den niemand will: die auf drei Wochen geschätzte Migration, der seltene Produktionsfehler, das Performance-Problem, das sich über acht Dienste erstreckt. Fable kartiert das System, Arbeiter nehmen isolierte Teile, der Prüfer überprüft jede Phase, und der Fortschritt ist an Tests gebunden, nicht an Optimismus.
Entscheidungsreife Recherche: Eine Frage geht hinein, Recherche-Arbeiter sammeln parallel aus Primärquellen, ein skeptischer Prüfer greift jede wichtige Behauptung an, und der Leiter verwandelt das, was übrig bleibt, in ein Memo. Dies kann eine Akquisition, einen Launch, eine Marktentscheidung oder eine Investment-These untermauern.
Geschäftsbetrieb: Geben Sie ihm Zugriff auf die richtigen Tools und lassen Sie es Daten abgleichen, Anomalien untersuchen, Berichte vorbereiten, einen Prozess überwachen oder einen operativen Rückstand abarbeiten. Fable 5.1 hat Fable 5s Punktzahl in Anthropics AutomationBench fast verdoppelt, was einer der klarsten praktischen Sprünge in der Veröffentlichung ist.
Referenzgesteuerte Produktarbeit: Geben Sie ihm Screenshots der gewünschten Erfahrung, die eigentlichen Assets und Zugriff auf die laufende App. Es kann gegen die Referenz implementieren, das Ergebnis öffnen, die beiden vergleichen und so lange fortfahren, bis die sichtbare Lücke geschlossen ist. Sie liefern den Geschmack. Es liefert die Augen, Hände und Geduld.
Ein sich selbst verstärkendes Wissenssystem: Richten Sie es auf alles aus, was in Ihrem Unternehmen erhaltenswert ist, und lassen Sie es verstreute Dokumente in eine gepflegte, verknüpfte Quelle der Wahrheit verwandeln. Ein Texter kann eines aus großartigen Verkaufsseiten bauen, eine Agentur aus ihren Fallstudien und ein SaaS-Unternehmen aus Kundenanrufen, Entscheidungen, Experimenten und Support-Historie. Jeder zukünftige Agent startet schlauer, weil der nützliche Kontext bereits existiert.
Jeder dieser Punkte war früher ein „Irgendwann"-Projekt.
Fable 5.1 macht viele davon zu „Diese-Woche"-Projekten, vorausgesetzt, Sie geben dem System eine echte Ziellinie und eine Möglichkeit zu beweisen, dass es sie überschritten hat.
Das gesamte Setup in einem Block
Führen Sie Fable 5.1 als Leiter aus: Es plant, delegiert, überprüft und entscheidet
Verwenden Sie Opus oder Sonnet für abgegrenzte Arbeit, mit einem Arbeiter pro unabhängiger Spur
Geben Sie ihm Ergebnis, Einschränkungen, Grund und Beweis, und lassen Sie es dann die Route wählen
Halten Sie CLAUDE.md kurz und verschieben Sie gelegentliche Prozeduren in Skills
Verwenden Sie Ziele für überprüfbare Fertigstellung und Schleifen für geplante Prüfungen
Kontrollieren Sie die Kosten mit Aufwandsstufen, günstigeren Arbeitern, zwischengespeichertem Kontext und harten Grenzen
Richten Sie das System auf Codebasen, Recherche, Betrieb, Produktarbeit und Wissen aus, das sich selbst verstärkt
Das Modell ist der sichtbarste Teil des Setups, aber es ist nicht der gesamte Vorteil.
Der Vorteil besteht darin, einem so fähigen Modell ein klares Ziel, ein kompetentes Team, Zugang zur Realität und keine Möglichkeit zu geben, eine überzeugende Antwort mit fertiger Arbeit zu verwechseln.
