GAN-Stil Harness Skill
Inspiriert von Anthropic's Harness-Design für langlebige Anwendungsentwicklung (24. März 2026)
Ein Multi-Agenten-Harness, der Generierung von Evaluierung trennt und eine adversarialer Rückkopplungsschleife erzeugt, die die Qualität weit über das hinaus treibt, was ein einzelner Agent erreichen kann.
Kern-Einsicht
Wenn man Agenten auffordert, ihre eigene Arbeit zu bewerten, sind sie pathologische Optimisten – sie loben mittelmäßige Ergebnisse und reden sich aus berechtigten Problemen heraus. Aber es ist weitaus machbarer, einen separaten Evaluator so zu entwickeln, dass er schonungslos streng ist, als einem Generator beizubringen, sich selbst zu kritisieren.
Dies ist die gleiche Dynamik wie bei GANs (Generative Adversarial Networks): Der Generator produziert, der Evaluator kritisiert, und dieses Feedback treibt die nächste Iteration an.
Wann man es einsetzen sollte
- Erstellung vollständiger Anwendungen aus einem einzigen Prompt
- Frontend-Design-Aufgaben, die hohe visuelle Qualität erfordern
- Full-Stack-Projekte, die funktionierende Features benötigen, nicht nur Code
- Jede Aufgabe, bei der „KI-Schrott“-Ästhetik nicht akzeptabel ist
- Projekte, bei denen Sie 50-200 $ für Produktionsqualität investieren möchten
Wann man es NICHT einsetzen sollte
- Schnelle Einzelfeld-Korrekturen (verwenden Sie stattdessen
claude -p) - Aufgaben mit knappem Budget (<10 $)
- Einfaches Refactoring (stattdessen das De-Sloppify-Muster verwenden)
- Aufgaben, die bereits gut mit Tests spezifiziert sind (TDD-Workflow verwenden)
Architektur
┌─────────────┐
│ PLANNER │
│ (Sonnet) │
└──────┬──────┘
│ Produktspezifikation
│ (Features, Sprints, Designrichtung)
▼
┌────────────────────────┐
│ │
│ GENERATOR-EVALUATOR │
│ FEEDBACK-SCHLEIFE │
│ │
│ ┌──────────┐ │
│ │GENERATOR │--build-->│──┐
│ │ (Sonnet) │ │ │
│ └────▲─────┘ │ │
│ │ │ │ Live-App
│ Feedback │ │
│ │ │ │
│ ┌────┴─────┐ │ │
│ │EVALUATOR │<-test----│──┘
│ │ (Sonnet) │ │
│ │+Playwright │
│ └──────────┘ │
│ │
│ 5-15 Iterationen │
└────────────────────────┘
Die Drei Agenten
1. Planungs-Agent
Rolle: Produktmanager – erweitert einen kurzen Prompt zu einer vollständigen Produktspezifikation.
Wichtige Verhaltensweisen:
- Nimmt einen einzeiligen Prompt und erstellt eine Spezifikation mit 16 Features und mehreren Sprints
- Definiert User Stories, technische Anforderungen und die visuelle Designrichtung
- Ist bewusst ambitioniert – konservative Planung führt zu enttäuschenden Ergebnissen
- Erstellt Bewertungskriterien, die der Evaluator später verwendet
Modell: Standardmäßig Sonnet; erhöhen über GAN_PLANNER_MODEL=opus für tiefere Spezifikationserweiterung
2. Generator-Agent
Rolle: Entwickler – implementiert Features gemäß der Spezifikation.
Wichtige Verhaltensweisen:
- Arbeitet in strukturierten Sprints (oder im kontinuierlichen Modus mit neueren Modellen)
- Handelt vor dem Schreiben von Code einen „Sprint-Vertrag“ mit dem Evaluator aus
- Nutzt Full-Stack-Tools: React, FastAPI/Express, Datenbanken, CSS
- Verwaltet Git für die Versionskontrolle zwischen Iterationen
- Liest Evaluator-Feedback und integriert es in der nächsten Iteration
Modell: Standardmäßig Sonnet; erhöhen über GAN_GENERATOR_MODEL=opus für maximale Programmierfähigkeit
3. Evaluator-Agent
Rolle: QA-Ingenieur – testet die laufende Anwendung live, nicht nur den Code.
Wichtige Verhaltensweisen:
- Verwendet Playwright MCP zur Interaktion mit der Live-Anwendung
- Klickt sich durch Features, füllt Formulare aus, testet API-Endpunkte
- Bewertet anhand von vier Kriterien (konfigurierbar):
- Designqualität – Fühlt es sich wie ein kohärentes Ganzes an?
- Originalität – Eigene Entscheidungen vs. Vorlage/KI-Muster?
- Handwerkskunst – Typografie, Abstände, Animationen, Mikro-Interaktionen?
- Funktionalität – Funktionieren alle Features tatsächlich?
- Gibt strukturiertes Feedback mit Bewertungen und spezifischen Problemen zurück
- Ist darauf ausgelegt, schonungslos streng zu sein – lobt niemals mittelmäßige Arbeit
Modell: Standardmäßig Sonnet; erhöhen über GAN_EVALUATOR_MODEL=opus für stärkere Beurteilung + Tool-Nutzung
Bewertungskriterien
Die vier Standardkriterien, jeweils bewertet von 1-10:
## Bewertungs-Rubrik
### Designqualität (Gewicht: 0,3)
- 1-3: Generisch, vorlagenhaft, „KI-Schrott“-Ästhetik
- 4-6: Solide, aber unauffällig, folgt Konventionen
- 7-8: Eigenständige, kohärente visuelle Identität
- 9-10: Könnte für die Arbeit eines professionellen Designers durchgehen
### Originalität (Gewicht: 0,2)
- 1-3: Standardfarben, Standardlayouts, keine Persönlichkeit
- 4-6: Einige eigene Entscheidungen, meist Standardmuster
- 7-8: Klare kreative Vision, einzigartiger Ansatz
- 9-10: Überraschend, entzückend, wirklich neuartig
### Handwerkskunst (Gewicht: 0,3)
- 1-3: Kaputte Layouts, fehlende Zustände, keine Animationen
- 4-6: Funktioniert, fühlt sich aber grob an, inkonsistente Abstände
- 7-8: Poliert, flüssige Übergänge, responsiv
- 9-10: Pixelgenau, entzückende Mikro-Interaktionen
### Funktionalität (Gewicht: 0,2)
- 1-3: Kernfunktionen defekt oder fehlend
- 4-6: Happy Path funktioniert, Randfälle schlagen fehl
- 7-8: Alle Features funktionieren, gute Fehlerbehandlung
- 9-10: Bombensicher, behandelt jeden Randfall
Bewertung
- Gewichtete Punktzahl = Summe der (Kriteriums-Punktzahl * Gewicht)
- Bestandenschwelle = 7,0 (konfigurierbar)
- Maximale Iterationen = 15 (konfigurierbar, typischerweise 5-15 ausreichend)
Verwendung
Über Befehl
# Vollständiger Drei-Agenten-Harness
/project:gan-build "Erstelle eine Projektmanagement-App mit Kanban-Boards, Team-Zusammenarbeit und Dark Mode"
# Mit benutzerdefinierter Konfiguration
/project:gan-build "Erstelle eine Rezepte-Plattform zum Teilen" --max-iterations 10 --pass-threshold 7.5
# Frontend-Design-Modus (nur Generator + Evaluator, kein Planer)
/project:gan-design "Erstelle eine Landing Page für einen Crypto-Portfolio-Tracker"
Über Shell-Skript
# Grundlegende Verwendung
./scripts/gan-harness.sh "Erstelle ein Musik-Streaming-Dashboard"
# Mit Optionen
GAN_MAX_ITERATIONS=10 \
GAN_PASS_THRESHOLD=7.5 \
GAN_EVAL_CRITERIA="functionality,performance,security" \
./scripts/gan-harness.sh "Erstelle eine REST-API für Aufgabenverwaltung"
Über Claude Code (Manuell)
# Schritt 1: Planen
claude -p --model sonnet "Du bist ein Produktplaner. Lies PLANNER_PROMPT.md. Erweitere diese kurze Beschreibung zu einer vollständigen Produktspezifikation: 'Erstelle eine Kanban-Board-App'. Schreibe die Spezifikation in spec.md"
# Schritt 2: Generieren (Iteration 1)
claude -p --model sonnet "Du bist ein Generator. Lies spec.md. Implementiere Sprint 1. Starte den Dev-Server auf Port 3000."
# Schritt 3: Evaluieren (Iteration 1)
claude -p --model sonnet --allowedTools "Read,Bash,mcp__playwright__*" "Du bist ein Evaluator. Lies EVALUATOR_PROMPT.md. Teste die Live-App unter http://localhost:3000. Bewerte anhand der Rubrik. Schreibe das Feedback in feedback-001.md"
# Schritt 4: Generieren (Iteration 2 – liest Feedback)
claude -p --model sonnet "Du bist ein Generator. Lies spec.md und feedback-001.md. Behebe alle Probleme. Verbessere die Bewertungen."
# Wiederhole Schritte 3-4, bis die Bestandenschwelle erreicht ist
Entwicklung über Modellfähigkeiten hinweg
Der Harness sollte sich vereinfachen, wenn Modelle besser werden. In Anlehnung an Anthropics Evolution:
Stufe 1 – Schwächere Modelle (Sonnet-Klasse)
- Vollständige Sprint-Zerlegung erforderlich
- Kontextzurücksetzungen zwischen Sprints (Kontextangst vermeiden)
- Mindestens 2 Agenten: Initialisierer + Programmier-Agent
- Umfangreiches Gerüst gleicht Modelleinschränkungen aus
Stufe 2 – Leistungsfähige Modelle (Opus 4.5-Klasse)
- Vollständiger 3-Agenten-Harness: Planer + Generator + Evaluator
- Sprint-Verträge vor jeder Implementierungsphase
- 10-Sprint-Zerlegung für komplexe Apps
- Kontextzurücksetzungen immer noch nützlich, aber weniger kritisch
Stufe 3 – Grenzmodelle (Opus 4.6-Klasse)
- Vereinfachter Harness: ein einziger Planungsdurchlauf, kontinuierliche Generierung
- Evaluierung reduziert auf einen einzigen Enddurchlauf (Modell ist intelligenter)
- Keine Sprint-Struktur erforderlich
- Automatische Kompaktierung bewältigt Kontextwachstum
Schlüsselprinzip: Jede Komponente des Harness codiert eine Annahme darüber, was das Modell allein nicht kann. Wenn sich Modelle verbessern, testen Sie diese Annahmen erneut. Entfernen Sie, was nicht mehr benötigt wird.
Konfiguration
Umgebungsvariablen
| Variable | Standard | Beschreibung |
|---|---|---|
GAN_MAX_ITERATIONS | 15 | Maximale Generator-Evaluator-Zyklen |
GAN_PASS_THRESHOLD | 7.0 | Gewichtete Punktzahl zum Bestehen (1-10) |
GAN_PLANNER_MODEL | sonnet | Modell für den Planungs-Agenten |
GAN_GENERATOR_MODEL | sonnet | Modell für den Generator-Agenten |
GAN_EVALUATOR_MODEL | sonnet | Modell für den Evaluator-Agenten |
GAN_EVAL_CRITERIA | design,originality,craft,functionality | Komma-getrennte Kriterien |
GAN_DEV_SERVER_PORT | 3000 | Port für die Live-App |
GAN_DEV_SERVER_CMD | npm run dev | Befehl zum Starten des Dev-Servers |
GAN_PROJECT_DIR | . | Projekt-Arbeitsverzeichnis |
GAN_SKIP_PLANNER | false | Planer überspringen, Spezifikation direkt verwenden |
GAN_EVAL_MODE | playwright | playwright, screenshot oder code-only |
Evaluierungsmodi
| Modus | Werkzeuge | Am besten geeignet für |
|---|---|---|
playwright | Browser MCP + Live-Interaktion | Full-Stack-Apps mit UI |
screenshot | Screenshot + visuelle Analyse | Statische Seiten, nur Design |
code-only | Tests + Linting + Build | APIs, Bibliotheken, CLI-Tools |
Anti-Patterns
-
Evaluator zu nachsichtig – Wenn der Evaluator in Iteration 1 alles bestehen lässt, ist Ihre Rubrik zu großzügig. Verschärfen Sie die Bewertungskriterien und fügen Sie explizite Strafen für häufige KI-Muster hinzu.
-
Generator ignoriert Feedback – Stellen Sie sicher, dass Feedback als Datei und nicht inline übergeben wird. Der Generator sollte zu Beginn jeder Iteration
feedback-NNN.mdlesen. -
Endlosschleifen – Setzen Sie immer
GAN_MAX_ITERATIONS. Wenn der Generator nach 3 Iterationen ein Score-Plateau nicht verbessern kann, stoppen Sie und markieren Sie es für menschliche Überprüfung. -
Evaluator testet oberflächlich – Der Evaluator muss Playwright verwenden, um mit der Live-App zu interagieren, nicht nur einen Screenshot zu machen. Klicken Sie auf Schaltflächen, füllen Sie Formulare aus, testen Sie Fehlerzustände.
-
Evaluator lobt eigene Korrekturen – Lassen Sie den Evaluator niemals Korrekturen vorschlagen und diese dann bewerten. Der Evaluator kritisiert nur; der Generator behebt.
-
Kontexterschöpfung – Verwenden Sie für lange Sitzungen die automatische Kompaktierung des Claude Agent SDK oder setzen Sie den Kontext zwischen größeren Phasen zurück.
Ergebnisse: Was zu erwarten ist
Basierend auf Anthropics veröffentlichten Ergebnissen:
| Metrik | Einzelner Agent | GAN Harness | Verbesserung |
|---|---|---|---|
| Zeit | 20 Min | 4-6 Stunden | 12-18x länger |
| Kosten | 9 $ | 125-200 $ | 14-22x mehr |
| Qualität | Kaum funktionsfähig | Produktionsreif | Phasenübergang |
| Kernfunktionen | Defekt | Alle funktionieren | N/A |
| Design | Generischer KI-Schrott | Eigenständig, poliert | N/A |
Der Kompromiss ist klar: ~20x mehr Zeit und Kosten für einen qualitativen Sprung in der Ausgabequalität. Dies ist für Projekte, bei denen Qualität zählt.
Referenzen
- Anthropic: Harness Design for Long-Running Apps — Originalarbeit von Prithvi Rajasekaran
- Epsilla: The GAN-Style Agent Loop — Architektur-Dekonstruktion
- Martin Fowler: Harness Engineering — Breiterer Branchenkontext
- OpenAI: Harness Engineering — OpenAI's parallele Arbeit