| # HARNESS_GUIDE.md — Entscheidungshilfe für Harness-Auswahl |
| |
| Basierend auf Eval-Session vom 20.03.2026. |
| Living document — wird mit weiteren Eval-Daten aktualisiert. |
| |
| --- |
| |
| ## 1. Grundprinzip: Harness ≠ Modell |
| |
| Harness-Eigenschaften und Modell-Eigenschaften sind getrennt zu bewerten: |
| |
| **Harness-Eigenschaften** (was der Agent *tut*): |
| - Rückfrageverhalten |
| - Subagent-Nutzung |
| - Scope-Disziplin |
| - Arbeitsstil / Iteration |
| - Dateistruktur |
| - Stabilität |
| |
| **Modell-Eigenschaften** (was das Modell *kann*): |
| - Reasoning-Qualität |
| - Output-Länge |
| - Kosten |
| - Geschwindigkeit |
| |
| > Die Eval vom 20.03. hat Harness+Modell-Combos getestet, nicht isolierte Harnesses. Wo relevant, wird das im Guide explizit gemacht. |
| |
| --- |
| |
| ## 2. Datengrundlage: Eval-Session 2026-03-20 |
| |
| Zwei Prompts getestet: Prompt1 (Analyse + Plan), Prompt2 (Dashboard-Bau). |
| |
| ### Codex (GPT 5.4 Medium) |
| |
| - **Rückfrageverhalten:** Stark — ~10x nachgefragt bevor gebaut |
| - **Scope-Treue:** Hoch — nah am Referenz-Repo |
| - **Output-Qualität:** Bestes Endprodukt ("dicke geliefert"), hübsches Dashboard |
| - **Stabilität:** Schwach — Dashboard 2x abgestürzt |
| - **Arbeitsstil:** Langsamer Start, dann systematisches Liefern |
| - **Feedback-Reaktion:** Erhaben/selbstbewusst, wenig Selbstkritik |
| |
| ### OpenCode (MiniMax 2.7) |
| |
| - **Rückfrageverhalten:** Keine Rückfragen — sofort losgelegt |
| - **Scope-Treue:** Verfehlt — Website statt Dashboard, Anforderungen fett verfehlt |
| - **Output-Qualität:** Saubere Dateistruktur (HTML + Python), aber falsches Produkt gebaut |
| - **Stabilität:** Nicht bewertbar (falscher Scope) |
| - **Arbeitsstil:** Schnellster Planer (10 Todos), viel parallele Recherche |
| - **Feedback-Reaktion:** Schwach — "verstanden, soll ich nochmal?" |
| |
| ### Hermes (MiniMax 2.7) |
| |
| - **Rückfrageverhalten:** Minimal — 1 Permission-Anfrage (Rich-Import) |
| - **Scope-Treue:** Mittel — Dashboard in `~/.hermes` statt Projektordner |
| - **Output-Qualität:** Terminal-basiertes Dashboard, 30s-Refresh. Anzeige "pretty useless" |
| - **Stabilität:** Funktionierte, aber irrelevante Daten |
| - **Arbeitsstil:** Langsam, kaum sichtbar, dann plötzlich Output |
| - **Feedback-Reaktion:** Stärkste — Fehler präzise akzeptiert, sofort weitergebaut |
| |
| --- |
| |
| ## 3. Pipeline-Modell: 4 Rollen, nicht 4 Alternativen |
| |
| Die Harnesses sind keine Alternativen — sie sind Stufen in einer Pipeline: |
| |
| ``` |
| Claude Code → OpenCode → Hermes → Codex |
| (Richtung) (Reality-Check) (Output) (Finish) |
| ``` |
| |
| **Claude Code** — Problem framing, Architektur, Konzept, riskante Entscheidungen, Systemdenken |
| |
| **OpenCode** — Gegenentwurf, Scope-Check, UI-/Prototyp-Check, "übersehe ich etwas?" |
| |
| **Hermes** — Hauptimplementierung, Iterationen, Feedback-Schleifen, tägliche Arbeit |
| |
| **Codex** — Polishing, Struktur glätten, README, Produktisierung, sauberer Endstand |
| |
| --- |
| |
| ## 4. Nicht jedes Projekt braucht alle 4 Stufen |
| |
| | Projekttyp | Pipeline | |
| |---|---| |
| | Kleines Projekt | Hermes → Codex | |
| | Unsicheres / neues Projekt | Claude Code → OpenCode → Hermes | |
| | Wichtiger Ship-Kandidat | Claude Code → Hermes → Codex | |
| | UI- / Produktidee | Claude Code → OpenCode → Codex | |
| | Langfristiges System / Agent-Architektur | Claude Code → OpenCode → Hermes → Codex | |
| |
| --- |
| |
| ## 5. Quick-Decision: 3 Fragen vor jedem Projekt |
| |
| 1. **Ist das Problem noch unklar?** |
| JA: Claude Code für Richtung. NEIN: Überspringen. |
| |
| 2. **Brauche ich einen Gegenentwurf?** |
| JA: OpenCode als Reality-Check. NEIN: Überspringen. |
| |
| 3. **Muss das am Ende wirklich polished sein?** |
| JA: Codex für Finish. NEIN: Hermes reicht. |
| |
| **Arbeitsregel in einem Satz:** |
| Claude Code für Richtung, OpenCode für Reality-Check, Hermes für Output, Codex für Finish. |
| |
| --- |
| |
| ## 6. Größte Gefahr: Overhead |
| |
| Zu viele Handoffs = Kontextverlust. Jeder Handoff kostet Context und Zeit. |
| |
| Pipeline nur so lang wie nötig. Default ist kürzer, nicht länger. |
| |
| --- |
| |
| ## 7. Kosten-Heuristik |
| |
| Keine konkreten $/M-Zahlen — qualitativ: |
| |
| - **Claude Code (Opus/Sonnet):** Teuer. Lohnt sich für Richtungsentscheidungen, nicht für Bulk-Output. |
| - **Codex (GPT 5.4):** Mittel-teuer. Guter ROI für Polishing, teuer für Exploration. |
| - **Hermes (MiniMax 2.7):** Günstig. Ideal für iterative Arbeit mit vielen Feedback-Schleifen. |
| - **OpenCode (MiniMax 2.7):** Günstig. Aber Scope-Probleme können Tokens verschwenden. |
| |
| Grundregel: Anthropic-Modelle deutlich teurer als MiniMax / Open-Source. |
| |
| --- |
| |
| ## 8. Limitationen & Offene Fragen |
| |
| - Eval basiert auf 1 Session mit 1 Aufgabentyp (Dashboard-Bau) |
| - Modell und Harness nicht isoliert getestet |
| - Hermes und OpenCode liefen beide mit MiniMax 2.7 — Harness-Unterschiede isolierbar, Modell-Unterschiede zu Codex (GPT 5.4) nicht |
| - Weitere Evals mit anderen Aufgabentypen geplant |
| - TODO: Token-Diät und Hermes-Config-Optimierung (separater Plan) |
| |
