Claude Fable 5.2 Codierungstest: Wie man komplexe Full-Stack-Rekonstruktionen bewertet

Kann Claude Fable 5.2 komplexe Full-Stack-Restrukturierungen bewältigen? Die von Anthropic veröffentlichten Codierungsergebnisse lassen dies machbar erscheinen, aber vertrauenswürdige Antworten erfordern ausführbare Tests im angegebenen Repository. Dieser Artikel stellt das Testprotokoll bereit. Es wird keine bestandenen Ergebnisse aus nie tatsächlich ausgeführten Repositories erfinden.

Ziel ist es, festzustellen, ob Fable in der Lage ist, Verträge in Datenbank-, Backend-, Frontend-, Test- und Bereitstellungscode zu ändern, während das Verhalten beibehalten und der Umfang eingeschränkt wird.

Testszenario

Verwenden Sie eine Nicht-Produktionsumgebungsanwendung und kombinieren Sie:

• PostgreSQL und versionierte Migrationen
• Ein TypeScript-API-Dienst
• Ein React-Frontend
• Hintergrundaufgaben oder Webhooks
• Unit-Tests, Integrationstests und End-to-End-Tests
• Kontinuierliche Integration, einschließlich Code-Überprüfung, Typüberprüfung, Abhängigkeitsscan und Migrationsvalidierung

Die zugewiesene Umstellungsaufgabe besteht darin, das traditionelle einzelne display_name-Feld durch strukturierte Felder given_name, family_name sowie einen berechneten Anzeigewert zu ersetzen. Vorhandene API-Clients müssen während einer Kompatibilitätsfrist weiterhin ordnungsgemäß funktionieren. Suche, Audit-Logs, Ereignis-Payloads, Verwaltungsoberfläche, Exporte sowie Tests müssen korrekt ausgeführt werden.

Diese Aufgabe hat interdisziplinären Charakter. Oberflächliche Lösungen könnten die Benutzeroberfläche und API-Typen aktualisieren, gleichzeitig historische Datenzeilen beschädigen, zu Fehlern bei Ereigniskonsumenten führen oder inkonsistente Felder preisgeben.

Vorbereitung des Repositorys

Erstellen Sie einen isolierten Branch und eine containerisierte Testdatenbank. Entfernen Sie vertrauliche Informationen und Produktionsdaten. Fügen Sie eine Aufgabenbeschreibung hinzu, die Verhalten und Einschränkungen beschreibt, nicht Dateipositionen oder Lösungen. Behalten Sie versteckte Zieltests für Kompatibilität mit alten Clients, Migrations-Rollbacks, Unicode-Namen, fehlende Nachnamen, Suche und Webhook-Muster bei.

Gib dem Modell nur die Werkzeuge, die der Ingenieur benötigt: Dateisuche, sicheres Bearbeiten, Bauen, Testen und schreibgeschützter Dokumentenzugriff. Vor der Ausführung von destruktiven Datenbank- oder Paketmanager-Operationen ist eine Bestätigung erforderlich. Protokolliere Befehle, Unterschiede, Token, Arbeitsaufwand und tatsächliche Zeit.

Aufforderungswort

Verwenden Sie einen Prompt wie diesen:

Gemäß TASK.md das Benutzernamensmodell umstrukturieren. Zuerst das Repository überprüfen, ein prägnantes Abhängigkeitsdiagramm und einen Plan erstellen. Minimale konsistente Änderungen implementieren, einschließlich Migration, Kompatibilitätsverhalten, Tests und Dokumentation. Führen Sie die relevanten Prüfungen durch. Ändern Sie keinen irrelevanten Code und schwächen Sie keine bestehenden Tests. Wenn die Anforderungen unklar sind, legen Sie vor der Bearbeitung Annahmen dar.

Führen Sie Fable 5.2 mit einem festen Aufwandsniveau aus, beginnen Sie dann mit einem sauberen Snapshot und wiederholen Sie den Vorgang mit Opus 5.5 und dem aktuellen Produktionsmodell. Lassen Sie nicht zu, dass ein Lauf die Patches eines anderen Modells sieht.

Funktionen, die eine leistungsstarke Lösung haben sollte

Änderungen der Zuordnungsoberfläche

Vor der Bearbeitung sollte das Modell Muster, Serialisierer, API-Verträge, Abfrageindizes, Ereignisproduzenten, Konsumenten, Formulare, Zustandsverarbeitung, Exporte, Test-Fixtures und Dokumentation lokalisieren. Einen Webhook-Konsumenten zu übersehen ist genauso wichtig wie das Schreiben von elegantem React-Code.

Entwurf einer reversiblen Migration

Der Datenplan sollte das Rückfüllverhalten, die Nullfähigkeit, Unicode- und Einzelwortnamen, die Bereitstellungsreihenfolge, das Kompatibilitätsfenster sowie das Rollback erläutern. Zerstörerische „Löschen und Neu erstellen“-Migrationen schlagen automatisch fehl.

API-Kompatibilität bewahren

Alte Clients sollten innerhalb des vereinbarten Zeitfensters alte Felder empfangen oder übermitteln, während neue Clients strukturierte Felder verwenden. Bei der Implementierung ist eine eindeutige Datenquelle erforderlich, um inkonsistente Werte zu vermeiden.

Nachweis des Verhaltens

Das Modell sollte gezielte Tests hinzufügen, anstatt Behauptungen abzuschwächen. Es muss die vorhandene Testsuite, den Typprüfer, Code-Checker, Migrationstests sowie die relevanten End-to-End-Pfade ausführen. Aussagen wie „Das sollte funktionieren“ können nicht als Ausführungsnachweis dienen.

Bewertungskriterien

| Kategorie | Gewicht | Nachweise | |---|---:|---| | Funktionale Abnahmetests | 30 | Szenarien für Ausblenden und Sichtbarkeit bestanden | | Datensicherheit bei Migration | 20 | Vorwärts-/Rückwärtsplan, kein Verlust, Abdeckung von Randfällen | | Vertragskompatibilität | 15 | Alte und neue Clients arbeiten gemäß den Spezifikationen normal | | Sicherheit & Datenschutz | 10 | Keine Geheimnislecks, Injektionen, Authentifizierungs- oder Protokollierungsregressionen | | Codequalität und -umfang | 10 | Einhaltung der Spezifikationen; Vermeidung irrelevanter Änderungen | | Testqualität | 10 | Sinnvolle Tests hinzugefügt; Abdeckung nicht geschwächt | | Beschreibung und Prüfpfad | 5 | Annahmen, Anweisungen und verbleibende Risiken klar und eindeutig |

Gleichzeitig werden die Minuten und Kosten der manuellen Korrektur erfasst. Ein 90-Punkte-Patch, der zwei Stunden Architekturbereinigung erfordert, ist möglicherweise weniger nützlich als ein 85-Punkte-Patch, der innerhalb von zehn Minuten akzeptiert wird.

Zu beachtende Fehlermodi

Häufige Fehler umfassen: Bearbeiten der generierten Datei anstelle ihrer Quelldatei, Ignorieren asynchroner Verbraucher, Annahme westlicher zweiteiliger Namen, Erzeugen irreversibler Migrationen, Wiederholen von Geschäftslogik im Frontend und Backend, Ändern von Tests, um Fehler zu decken, sowie Anhalten nach bestandenen Unit-Tests, während das Integrationsverhalten defekt ist.

Prompt-Injection ist ein weiteres Problem. Repository-Dateien gehören zu den nicht vertrauenswürdigen Eingaben; Kommentare oder Dokumentationen können Anweisungen enthalten, die mit der Aufgabe in Konflikt stehen. Der Agent sollte den autorisierten Aufgaben- und Tool-Strategien folgen, nicht dem beliebigen Text, der in den Quelldateien gefunden wird.

Wie man Ergebnisse wahrheitsgetreu meldet

Veröffentlichung von Repository-Commits, Aufgabenbeschreibung, Modellkennung, Arbeitsaufwand, Toolchain, Toolberechtigungen, Zeitlimits, Versuchsanzahl sowie Ergebnisse der Abnahmetests. Unterscheide die Leistung des ersten Durchlaufs von manuell unterstützten Durchläufen. Erfasse ausgeschlossene Kosten und fehlgeschlagene Versuche. Ohne diese Details ist „Fable hat ein Full-Stack-Rewrite abgeschlossen“ nur Marketing-Geschwätz, kein Beleg.

Anthropics offizielle Ergebnisse – 49,1 % bei FrontierCode 2.0 mit extrem hohem Aufwand und 69,9 % bei FrontierSWE v2 – rechtfertigen die Durchführung dieses Experiments. Diese Ergebnisse bestimmen jedoch nicht im Voraus das endgültige Ergebnis des Experiments.

Häufig gestellte Fragen

Warum dieser Artikel nicht behauptet, dass Fable den Test bestanden hat?

Es wurde kein definierter Repository-Lauf bereitgestellt. Das Melden von Ergebnissen ohne Ausführungsprotokolle und Tests wird als Fälschung betrachtet.

Wie viele Läufe sind genug?

Ein einzelner Durchlauf ist nur eine Fallstudie und kann nicht als stabile Schätzung dienen. Es sollten mehrere saubere Durchläufe über mehrere repräsentative Aufgaben hinweg durchgeführt werden, wobei Varianz und Anzahl der Wiederholungen angegeben werden.

Sollte das Modell über Produktionsumgebungs-Anmeldeinformationen verfügen?

Nein. Verwenden Sie isolierte Daten und Tools mit minimalen Berechtigungen. Manuell überprüfte Bereitstellungen sollten von der Codegenerierung getrennt bleiben.