Harness-Design für die Entwicklung langlaufender Anwendungen

• Anthropic entwickelte eine von GANs inspirierte Multi-Agenten-Architektur, um gleichzeitig zwei Probleme zu lösen: höhere Qualität im Frontend-Design und langfristiges autonomes Coding
• Durch die Trennung von Generator und Evaluator wird subjektive Designqualität anhand konkreter Kriterien bewertbar, wodurch das Problem der verzerrten Selbstbewertung von Agenten gelöst wird
• Mit einer 3-Agenten-Architektur aus Planner, Generator und Evaluator werden in mehrstündigen autonomen Coding-Sessions Full-Stack-Anwendungen fertiggestellt, einschließlich Sprint-Vertragsverhandlungen und Playwright-basierter QA
• Beim Wechsel von Opus 4.5 zu Opus 4.6 wurde konsistentes Coding über mehr als 2 Stunden ohne Sprint-Aufteilung möglich, wodurch sich die Komplexität des Harness reduzieren ließ, ohne Leistung einzubüßen
• Selbst wenn die Modellleistung steigt, schrumpft der Raum interessanter Harness-Kombinationen nicht, sondern verschiebt sich – die zentrale Aufgabe von AI Engineers ist es, diese neuen Kombinationen zu finden

---

Warum einfache Implementierungen an Grenzen stoßen

• In früheren Experimenten wurde ein Ansatz genutzt, bei dem ein Initialisierungs-Agent Produktspezifikationen in eine Aufgabenliste zerlegte und ein Coding-Agent einzelne Funktionen implementierte, während Artefakte den Kontext zwischen Sitzungen übertrugen
  • Auch in der Entwickler-Community tauchten ähnliche Ansätze auf, die Agenten über Hooks oder Skripte in einer dauerhaften Schleife halten – ähnlich dem „Ralph Wiggum“-Ansatz
• Bei komplexen Aufgaben blieb das Problem bestehen, dass Agenten mit der Zeit vom Kurs abkamen; dabei wurden zwei typische Fehlermodi beobachtet
• Erster Fehlermodus: Wenn sich das Kontextfenster füllt, verliert das Modell an Konsistenz; manche Modelle zeigen zudem eine Art „context anxiety“, also die Tendenz, Arbeit vorzeitig abzuschließen, sobald sie glauben, ihre Kontextgrenze erreicht zu haben
  • Ein Kontext-Reset – das vollständige Leeren des Kontextfensters und der Start eines neuen Agenten mit strukturiertem Handover inklusive vorherigem Status und nächsten Schritten – löst beide Probleme
  • Das unterscheidet sich von Compaction, bei der frühere Gesprächsteile zusammengefasst werden, damit derselbe Agent weiterarbeiten kann; Compaction erhält Kontinuität, bietet aber kein wirklich sauberes Blatt, sodass context anxiety bestehen bleiben kann
  • Bei Claude Sonnet 4.5 war context anxiety so stark, dass Compaction allein keine zuverlässige Leistung bei Langzeitaufgaben garantieren konnte; daher wurde der Kontext-Reset zu einem Kernelement des Harness-Designs
• Zweiter Fehlermodus: das Problem der Selbstbewertung, bei dem Agenten ihre eigenen Ergebnisse selbst dann selbstbewusst loben, wenn deren Qualität offensichtlich nur mittelmäßig ist
  • Besonders gravierend ist das bei subjektiven Aufgaben wie Design, weil es dort keine binären Prüfungen wie bei verifizierbaren Softwaretests gibt
  • Die Trennung von Arbeits-Agent und Bewertungs-Agent ist hier ein starker Hebel; einen unabhängigen Evaluator skeptisch zu tunen ist deutlich einfacher, als einen Generator zur Selbstkritik zu bringen

Frontend-Design: Subjektive Qualität bewertbar machen

• Ohne Eingriffe erzeugt Claude standardmäßig sichere, vorhersehbare Layouts, die technisch funktionieren, visuell aber gewöhnlich wirken
• Zwei zentrale Einsichten bestimmten das Harness-Design
  • Ästhetik lässt sich nicht vollständig in Punkte fassen, aber mit Bewertungskriterien, die Designprinzipien und Vorlieben kodieren, lässt sie sich verbessern – „Folgt dieses Design guten Gestaltungsprinzipien?“ ist konsistenter bewertbar als „Ist dieses Design schön?“
  • Die Trennung von Frontend-Erzeugung und Bewertung schafft eine Feedback-Schleife, die den Generator zu besseren Ergebnissen führt
• Vier Bewertungskriterien, die sowohl Generator als auch Evaluator erhielten:
  • Design quality: Ob Farben, Typografie, Layout und Bilder ein stimmiges Ganzes mit klarer Stimmung und Identität ergeben
  • Originality: Ob erkennbare individuelle Entscheidungen getroffen wurden oder ob es sich nur um Template-Layouts, Library-Defaults oder typische AI-Muster handelt – etwa weiße Karten auf violettem Verlauf als klassisches AI-Signal
  • Craft: Technische Ausführung wie typografische Hierarchie, konsistente Abstände, Farbharmonie und Kontrastverhältnisse – ein Test auf handwerkliche Qualität, nicht auf Kreativität
  • Functionality: Nutzbarkeit unabhängig von der Ästhetik – ob Nutzer verstehen, was die Oberfläche tut, und die wichtigsten Aktionen finden können
• Design quality und Originality wurden stärker gewichtet als Craft und Functionality, weil Claude bei Craft und Functionality ohnehin meist gut abschnitt, aber bei Design und Originality nur durchschnittliche Resultate lieferte
  • Die Kriterien werteten sehr allgemeine „AI slop“-Muster explizit ab, um das Modell zu mehr ästhetischem Risiko zu bewegen
• Die Orchestrierung wurde mit dem Claude Agent SDK aufgebaut: Der Generator erzeugte ein HTML/CSS/JS-Frontend, der Evaluator interagierte über Playwright MCP direkt mit der Live-Seite, machte Screenshots, prüfte die Umsetzung sorgfältig und schrieb Bewertungen samt ausführlicher Kritik
  • Pro Generierung wurden 5 bis 15 Iterationen durchlaufen, in denen der Generator auf die Kritik des Evaluators reagierte und sich in individuellere Richtungen bewegte
  • Ein vollständiger Lauf konnte bis zu 4 Stunden dauern
  • Nach jeder Bewertung sollte der Generator eine strategische Entscheidung treffen: bei gutem Trend den aktuellen Ansatz verfeinern, bei schwachem Ansatz komplett zu einer anderen Ästhetik wechseln
• Die Formulierung der Kriterien beeinflusste den Generator auf unerwartete Weise – Formulierungen wie „die besten Designs sind von Museumsqualität“ führten zu bestimmten visuellen Konvergenzen; die mit den Kriterien verbundene Sprache prägte also direkt den Charakter der Ergebnisse
• Die Punktzahlen verbesserten sich über die Iterationen meist, aber nicht immer linear; häufig wurden mittlere Iterationen den letzten vorgezogen
  • Die Implementierungskomplexität nahm im Verlauf tendenziell zu, weil der Generator auf Basis des Evaluator-Feedbacks ambitioniertere Lösungen verfolgte
  • Schon die erste Iteration war sichtbar besser als eine Baseline ohne spezielles Prompting; allein die Kriterien und ihre Sprache halfen dem Modell, die üblichen Standardmuster zu verlassen
• Beispiel einer niederländischen Museums-Website: Bis zur 9. Iteration entstand eine saubere Dark-Theme-Landing-Page, doch in der 10. Iteration wurde der Ansatz vollständig verworfen und als räumliches Erlebnis neu gedacht – mit einem per CSS-Perspektive gerenderten 3D-Raum, kariertem Boden, frei an den Wänden hängenden Werken und Navigation zwischen Galerien durch Türen. Ein solcher kreativer Sprung wäre in einer Einzeldurchlauf-Generierung kaum zu erwarten gewesen

Ausweitung auf Full-Stack-Coding

Architektur

• Ein früheres Harness für langlaufende Prozesse löste konsistentes Multi-Session-Coding bereits mit Initialisierungs-Agent, funktionsbezogenen Coding-Agenten und Kontext-Resets zwischen Sitzungen
  • Wegen der context anxiety in Sonnet 4.5 waren Kontext-Resets dort essenziell; in Opus 4.5 war dieses Verhalten jedoch weitgehend verschwunden, sodass der gesamte Build in einer durchgehenden Sitzung ohne Kontext-Resets ausgeführt werden konnte
  • Die automatische Compaction des Claude Agent SDK übernahm das Management wachsender Kontexte
• Aufbau eines 3-Agenten-Systems:
  • Planner: Erweitert einen kurzen Prompt von 1 bis 4 Sätzen zu einer vollständigen Produktspezifikation – mit Fokus auf Produktkontext und High-Level-Architektur statt auf technische Detailumsetzung, da voreilig festgelegte Technikdetails Fehler nachgelagert fortpflanzen könnten
    • Der Planner wurde angewiesen, Gelegenheiten zu finden, AI-Funktionen in die Produktspezifikation einzuweben
  • Generator: Nimmt sprintweise einzelne Funktionen aus der Spezifikation auf, implementiert sie mit React/Vite/FastAPI/SQLite (später PostgreSQL), führt am Ende jedes Sprints eine Selbstbewertung durch, übergibt dann an QA und verwaltet Versionen mit git
  • Evaluator: Nutzt Playwright MCP, um die laufende Anwendung wie ein realer Nutzer durchzuklicken und UI-Funktionalität, API-Endpunkte und Datenbankzustand zu testen – bewertet nach Produkttiefe, Funktionalität, visuellem Design und Codequalität; bei Unterschreitung definierter harter Schwellenwerte pro Kriterium gilt der Sprint als fehlgeschlagen
• Vor jedem Sprint verhandelten Generator und Evaluator einen Sprint-Vertrag – also eine gemeinsame Definition dessen, was für dieses Arbeitspaket als „fertig“ gilt, noch bevor Code geschrieben wurde
  • Da die Produktspezifikation bewusst auf höherer Ebene blieb, schloss dieser Schritt die Lücke zwischen User Stories und testbarer Implementierung
  • Die Kommunikation erfolgte dateibasiert: Ein Agent schrieb eine Datei, der andere las sie und antwortete

Ergebnisse des Harness-Laufs: Retro-Game-Maker

• Getestet wurde mit dem Prompt: „Baue einen 2D-Retro-Game-Maker mit Level-Editor, Sprite-Editor, Entity-Verhalten und spielbarem Testmodus“
• Solo-Agent: 20 Minuten / 9 Dollar gegenüber vollem Harness: 6 Stunden / 200 Dollar – das Harness war mehr als 20-mal teurer, aber der Qualitätsunterschied der Ergebnisse war sofort sichtbar
• Ergebnis des Solo-Laufs: Der Startbildschirm entsprach zunächst den Erwartungen, doch beim Klicken traten Probleme auf – verschwenderisches Layout, steifer Workflow, fehlende Anleitung dazu, zuerst Sprites und Entities anzulegen, und vor allem funktionierte das eigentliche Spiel nicht: Entities erschienen zwar auf dem Bildschirm, reagierten aber nicht auf Eingaben; die Verbindung zwischen Entity-Definitionen und Game-Runtime war unterbrochen
• Ergebnis des Harness-Laufs: Der Planner weitete den Ein-Satz-Prompt auf 16 Funktionsspezifikationen über 10 Sprints aus – darunter Sprite-Animationssystem, Verhaltens-Templates, Soundeffekte und Musik, AI-gestützter Sprite-Generator und Level-Designer sowie Export von Spielen über teilbare Links
  • Er übernahm zudem die Frontend-Design-Fähigkeiten und erzeugte die visuelle Designsprache der App als Teil der Spezifikation
  • Die Canvas nutzte die gesamte Viewport-Fläche, Panel-Größen waren sinnvoll gewählt und die visuelle Identität war entlang der Designrichtung der Spezifikation konsistent
  • Der Sprite-Editor war deutlich reichhaltiger und vollständiger, mit saubererer Tool-Palette, besserem Farbwähler und besser nutzbaren Zoom-Kontrollen
  • Durch AI-Integration ließ sich per Prompting verschiedenes im Spiel erzeugen, was den Workflow beschleunigte
• Der entscheidende Unterschied im Play-Modus: Im Solo-Lauf funktionierte das Spiel nicht, im Harness-Lauf konnte man Entities tatsächlich bewegen und das Spiel spielen – es gab zwar noch etwas grobe Stellen in der Physik-Engine und Grenzen beim AI-Level-Design, aber die Kernfunktionalität war vorhanden
• Der Evaluator hielt die Implementierung eng an der Spezifikation – allein Sprint 3 deckte für den Level-Editor einen detaillierten Vertrag mit 27 Kriterien ab
  • Beispiele gefundener Probleme: Das Rechteck-Füllwerkzeug platzierte Tiles nur an Start- und Endpunkt des Ziehens, ein Fehler in der Bedingung des Delete-Key-Handlers für Entities und ein Problem mit der Reihenfolge von FastAPI-Routen, durch das reorder als Integer geparst und ein 422-Fehler zurückgegeben wurde
• Das Tuning des Evaluators erforderte erheblichen Aufwand – im Standardzustand war Claude ein schwacher QA-Agent, der berechtigte Probleme zwar fand, sich dann aber selbst davon überzeugte, dass sie „nicht so schlimm“ seien, und oberflächliche Tests übersahen subtile Bugs
  • Erst nach mehreren Entwicklungszyklen – Logs des Evaluators lesen, Fälle divergierender Urteile suchen und das QA-Prompt aktualisieren – wurde eine vernünftige Bewertungsqualität erreicht

Iterative Verbesserung des Harness

• Die ersten Resultate waren ermutigend, aber groß, langsam und teuer, weshalb als nächster Schritt eine Vereinfachung des Harness ohne Leistungsverlust angestrebt wurde
  • Jede Komponente des Harness kodiert Annahmen darüber, was das Modell nicht allein leisten kann; diese Annahmen sind wert, unter Stresstest gestellt zu werden, weil sie mit besseren Modellen schnell veralten können
  • Leitprinzip war: „Finde die einfachstmögliche Lösung und erhöhe die Komplexität nur bei Bedarf.“
• Versuche radikaler Vereinfachung konnten die ursprüngliche Leistung nicht reproduzieren; weil schwer festzustellen war, welche Teile tatsächlich Last trugen, wurde auf einen systematischen Ansatz umgestellt, bei dem jeweils nur eine Komponente entfernt wurde
• Die Veröffentlichung von Opus 4.6 war ein zusätzlicher Anstoß zur Reduktion der Harness-Komplexität – das Modell plante sorgfältiger, hielt agentische Aufgaben länger durch, arbeitete stabiler in größeren Codebasen, prüfte eigenen Code in Review und Debugging besser und zeigte deutlich verbesserte Fähigkeiten bei der Suche in langen Kontexten

Wegfall der Sprint-Struktur

• Die Sprint-Struktur wurde vollständig entfernt – dank der verbesserten Fähigkeiten von Opus 4.6 konnte das Modell Aufgaben auch ohne diese Zerlegung konsistent bearbeiten
• Planner und Evaluator blieben bestehen – ohne Planner fehlte dem Generator Scope, sodass er nur mit rohem Prompt und ohne Spezifikation Builds mit zu wenig Funktionen begann
• Der Evaluator wurde von einer Sprint-für-Sprint-Bewertung auf einen einzelnen Durchlauf am Ende der Ausführung umgestellt
  • Liegt eine Aufgabe innerhalb der Fähigkeiten des Modells allein, ist der Evaluator unnötiger Overhead; bei Aufgaben an der Leistungsgrenze des Modells bringt er jedoch weiterhin spürbare Verbesserungen
  • Der Evaluator ist daher kein starres Ja/Nein-Element, sondern lohnt seine Kosten dann, wenn die Aufgabe über das hinausgeht, was das aktuelle Modell zuverlässig allein leisten kann
• Zusätzlich wurde Prompting verbessert, um den Build von AI-Funktionen zu stärken – es brauchte viel Iteration, bis der Generator in der Lage war, geeignete Agenten zu bauen, die die Funktionen der App selbst über Tools antreiben, auch weil dieses Wissen sehr neu ist und Claudes Trainingsdaten dazu nur wenig Abdeckung haben

Ergebnisse des aktualisierten Harness: Browser-DAW

• Getestet wurde mit dem Prompt: „Baue eine voll funktionsfähige DAW im Browser mit der Web Audio API“
• Gesamtkosten: rund 4 Stunden und 124,70 Dollar
  • Planner: 4,7 Min / 0,46 Dollar, Build-Runde 1: 2 Std 7 Min / 71,08 Dollar, QA-Runde 1: 8,8 Min / 3,24 Dollar, Build-Runde 2: 1 Std 2 Min / 36,89 Dollar, QA-Runde 2: 6,8 Min / 3,09 Dollar, Build-Runde 3: 10,9 Min / 5,88 Dollar, QA-Runde 3: 9,6 Min / 4,06 Dollar
• Der Builder lief mehr als 2 Stunden konsistent, ohne in Sprints zerlegt zu werden
• Erstes Feedback des QA-Agenten: Designtreue sowie AI-Agenten und Backend seien stark, aber funktionale Vollständigkeit sei der größte Schwachpunkt – Clips ließen sich in der Timeline nicht ziehen oder verschieben, Instrumenten-Panels wie Synth-Knobs oder Drum-Pads fehlten und visuelle Effekteditoren wie EQ-Kurven oder Compressor-Meter waren nicht vorhanden
• Zweites QA-Feedback: Audioaufnahme war noch ein Stub, Clip-Resize und Split fehlten, und Effektvisualisierungen bestanden nur aus numerischen Slidern statt aus echten Grafiken
• Die finale App erreichte nicht das Niveau professioneller Musikproduktionssoftware, und die Fähigkeit des Agenten zum Komponieren von Musik muss noch besser werden, zumal Claude keinen Ton tatsächlich hören kann, wodurch die QA-Feedback-Schleife bei musikalischem Geschmack weniger wirksam ist
  • Dennoch enthielt sie die Kernelemente eines funktionierenden Musikproduktionsprogramms mit Arrangement View, Mixer und Transport
  • Per Prompting konnten kurze Song-Snippets erzeugt werden – der Agent setzte Tempo und Tonart, platzierte Melodien, erstellte Drum-Tracks, passte Mixer-Level an und fügte Reverb hinzu

Ausblick

• Mit besseren Modellen ist zu erwarten, dass längere und komplexere Aufgaben bearbeitet werden können; in manchen Fällen sinkt dadurch die Bedeutung des umgebenden Scaffolds, sodass manche Probleme mit dem nächsten Modell von selbst verschwinden könnten
• Gleichzeitig eröffnet ein besseres Modell auch mehr Raum für Harnesses, die über die Baseline hinaus komplexe Aufgaben erreichbar machen
• Zentrale Lehren:
  • Es bleibt gute Praxis, das Zielmodell experimentell zu untersuchen, bei realen Problemen Traces zu lesen und die Leistung auf das gewünschte Ergebnis hin zu tunen
  • Bei komplexeren Aufgaben schafft man Spielraum, indem man die Aufgabe zerlegt und für einzelne Aspekte spezialisierte Agenten einsetzt
  • Mit jedem neuen Modell sollte das Harness neu überprüft werden: Teile, die nicht mehr die Leistung tragen, sollten entfernt werden, während neue Komponenten hinzukommen können, um zuvor unmögliche Fähigkeiten zu erreichen
• Auch wenn Modelle besser werden, schrumpft der Raum interessanter Harness-Kombinationen nicht, sondern verschiebt sich – und die Aufgabe von AI Engineers besteht darin, diese nächste neue Kombination weiterhin zu finden