Better Harness: Qoders Werkzeug für belastbarere KI-Coding-Workflows

Better Harness ist ein Open-Source-Projekt von Qoder, das den Arbeitsablauf rund um einen Coding Agent überprüft und verbessert. Es bewertet also nicht bloß eine einzelne Modellantwort oder einen Code-Diff. Im Fokus stehen Projektvorgaben, Kontrollmechanismen, Validierungswege, Agent-Konfigurationen und – sofern verfügbar – Aufzeichnungen realer Agent-Sitzungen. Ziel ist es, Schwachstellen im Workflow zu belegen, eine begrenzte Reparatur vorzuschlagen und deren Wirkung in einem späteren Durchlauf überprüfbar zu machen. 124

Laut zeitgenössischen Berichten wurde das Projekt am 28. Juli 2026 auf GitHub als Open Source veröffentlicht. 5

Nicht nur den Agent bewerten, sondern seine Arbeitsumgebung

Ein Coding Agent arbeitet nie isoliert. Seine Ergebnisse hängen auch von Repository-Anweisungen, Spezifikationen, Werkzeugen, Berechtigungen, Skripten, Tests, Review-Vorgaben, Release-Prüfungen und menschlichen Übergaben ab. Qoder bezeichnet diese Umgebung als Harness. Dazu können etwa Regeln, Skills, Hooks, Plug-ins, Konnektoren, Testbefehle und Schritte für menschliche Reviews gehören. 2

Das ist ein wichtiger Unterschied: Auch ein leistungsfähiges Modell liefert unzuverlässige Ergebnisse, wenn die umgebenden Prozesse unklar oder schlecht beobachtbar sind. Ein Repository kann beispielsweise Tests enthalten, ohne festzulegen, wann der Agent sie ausführen soll. Es kann Regeldateien geben, die der Agent in der Praxis nicht nutzt. Oder Erkenntnisse aus fehlgeschlagenen Aufgaben gehen nach Ende einer Sitzung verloren. Better Harness soll solche operativen Schwachstellen sichtbar machen – statt die bloße Existenz einer Konfigurationsdatei mit einem funktionierenden Prozess zu verwechseln. 145

Das dreistufige Framework

Qoder beschreibt Better Harness als dreistufiges Framework, das Engineering-Praktiken, ein Bewertungsmodell und eine ausführbare Umsetzung verbindet. 5

1. Harness Engineering: die praktische Grundlage

Die erste Ebene umfasst die Mechanismen, die die Agent-Arbeit prägen: Sitzungs- und CLI-Muster, Beobachtbarkeit, Regeln, Skills, MCP-Konfiguration, Speicherfunktionen, Hooks und Automatisierung. 5

Praktisch geht es dabei um Fragen wie:

• Bekommt der Agent Ziele, Einschränkungen und Repository-Kontext klar vermittelt?
• Sind Ausführungspfade und Berechtigungen angemessen kontrolliert?
• Sind Tests, Prüfungen und Reviews mit der tatsächlichen Arbeit des Agents verbunden?
• Werden hilfreiche Erkenntnisse als wartbare Projektartefakte festgehalten, statt mit einer Sitzung zu verschwinden?

Zu Beginn kartiert Better Harness die aktuelle Umgebung: Ziele, Kontext, Ausführungseinstiege, Feedback-Schleifen, Auslieferungsmechanismen und die Erfassung von Lernerfahrungen. 1

2. Agent Work Loop: fünf Dimensionen der Auslieferung

Die zweite Ebene übersetzt diese Praktiken in eine Bewertung von fünf zusammenhängenden Dimensionen: Aufgabenverständnis, kontrollierte Ausführung, Validierung von Änderungen, zuverlässige Auslieferung und Erfassung von Lernerfahrungen. 14

Damit verschiebt sich die zentrale Frage von „Hat der Agent plausiblen Code erzeugt?“ zu: Kann der gesamte Workflow wiederholt Änderungen hervorbringen, die verständlich, kontrolliert, validiert, auslieferbar und durch frühere Erfahrungen besser informiert sind?

Das Modell soll Bruchstellen in diesem Ablauf identifizieren – etwa einen fehlenden Mechanismus, eine nicht verbundene Integration, einen nie ausgeführten Schritt oder unzureichende Belege für das Ergebnis. 1

3. Ausführbare Umsetzung statt bloßer Leitlinien

Die dritte Ebene bringt Praktiken und Bewertungsmodell in reale Projekte. Better Harness läuft über einen Coding Agent, sammelt Projekt- und gegebenenfalls Sitzungsnachweise und erstellt priorisierte, überprüfbare nächste Schritte. 4

Die aktuellen Projektmaterialien nennen Unterstützung für zehn Host-Adapter. In Berichten zum Start wurden unter anderem Claude Code, Codex, Qoder und Cursor als unterstützte Coding-Agent-Umgebungen genannt. 56

Der Adapterumfang kann sich ändern. Wer eine bestimmte Integration benötigt, sollte deshalb die aktuelle Adapter-Dokumentation prüfen. Für OpenClaw belegen die vorliegenden Quellen keine Unterstützung.

Drei voneinander getrennte Evidenzperspektiven

Ein Kernmerkmal ist die Trennung von Datensammlung und abschließender Bewertung. Nach Angaben von Qoder sammelt der Hauptablauf zunächst Rohdaten und übergibt sie anschließend an drei unabhängige, nur lesende Sub-Agents, bevor die Ergebnisse zusammengeführt werden. 1

Diese drei Perspektiven sind:

• Project Harness: technische Grundlagen des Repositories, etwa Anweisungen, Skripte, Prüfungen und Auslieferungskontrollen.
• Agent Customization: agent-spezifische Regeln, Skills, Hooks und weitere Konfigurationen.
• Session Evidence: Aufzeichnungen dessen, was der Agent in realen Arbeitsabläufen tatsächlich getan hat – sofern diese Nachweise verfügbar sind.

So lässt sich besser unterscheiden zwischen einem vorgesehenen Prozess und einem beobachteten Prozess. Projekt- und Konfigurationsdaten können belegen, dass eine Fähigkeit vorhanden ist. Sitzungsdaten können dagegen zeigen, ob sie bei einer konkreten Aufgabe auch angemessen eingesetzt wurde. 14

Vorhanden heißt nicht automatisch wirksam

Das zentrale Prinzip lautet: Die Existenz eines Artefakts ist kein Beweis für seine Wirksamkeit.

Ein automatisiertes Testpaket im Repository zeigt zunächst nur, dass die technische Möglichkeit besteht. Es belegt nicht, dass ein Agent nach einer Änderung die relevanten Tests ausgeführt, das Ergebnis richtig eingeordnet und dadurch eine fehlerhafte Auslieferung verhindert hat. Dasselbe gilt für Regeln, Hooks, Skills oder Freigabeschranken. 15

Better Harness soll die Nachweiskette deshalb ausdrücklich sichtbar halten. Berichte übersetzen belegte Lücken in priorisierte Findings mit Auswirkung, erwartetem Ergebnis, begrenzter Reparatur und Akzeptanzprüfungen. Fehlende Nachweise bleiben sichtbar, statt stillschweigend in eine scheinbar sichere Bewertung einzugehen. 46

Für Teams wird ein Finding damit konkret überprüfbar:

1. Was wurde beobachtet? – im Projekt, in der Konfiguration oder in einer Sitzungsaufzeichnung.
2. Warum ist es relevant? – für den Arbeits- und Auslieferungszyklus.
3. Welche eng abgegrenzte Reparatur wird vorgeschlagen? – etwa eine Regel, ein Skill, Hook, Skript, eine Automatisierung oder ein menschlicher Freigabeschritt.
4. Wie lässt sich die Reparatur verifizieren? – nach der Umsetzung in einem erneuten Durchlauf.

Der Verbesserungszyklus: prüfen, reparieren, erneut messen

Better Harness ist nicht als einmaliger Audit gedacht, sondern als iterativer Ablauf:

1. Die aktuelle Harness-Umgebung erfassen.
2. Bruchstellen im Workflow und Evidenzlücken finden.
3. Für einen belegten Befund eine begrenzte Reparaturaufgabe erstellen.
4. Die Reparatur anhand festgelegter Akzeptanzprüfungen validieren.
5. Die Analyse erneut ausführen und die aktualisierten Nachweise bewerten. 14

Das ist die Grundlage des Anspruchs auf kontinuierliche Verbesserung. Das Werkzeug kann zeigen, dass sich ein Workflow verändert hat und ob neue Nachweise eine bessere Bewertung stützen. Es beweist jedoch nicht automatisch, dass eine Reparatur in jedem Projekt oder jeder Host-Umgebung bessere Agent-Ergebnisse verursacht hat. Qoder betont beobachtete Evidenz und explizite Einschränkungen, statt Veränderungen von Bewertungen als Kausalbeweis auszugeben. 46

Was die Auswertung von 30 GitHub-Projekten aussagt – und was nicht

Zum Start wurde berichtet, dass das Framework in einer ersten Übung bei 30 realen GitHub-Projekten eingesetzt wurde. 5 Das sollte als explorative Anwendung verstanden werden, nicht als kontrollierter Nachweis dafür, dass Better Harness jeden Coding Agent oder jedes Repository verbessert.

Die vorliegende Primärdokumentation stützt das Evidenzmodell, die Struktur der Findings und den iterativen Reparaturablauf. Sie liefert jedoch nicht genügend Details, um Auswahl der 30 Projekte, Bewertungsprotokoll oder zusammengefasste Resultate unabhängig zu beurteilen. Das ist wichtig, wenn Better Harness mit formalen Benchmarks verglichen oder daraus weitreichende Leistungsversprechen abgeleitet werden sollen. 14

Ein Schritt zu messbarerem Agent Engineering

Qoders übergeordnetes Argument: Harness Engineering soll zur Qualitätsinfrastruktur für KI-gestützte Softwareentwicklung werden – mit gemeinsamer Sprache für Workflow-Kontrollen, beobachtbaren Nachweisen, vergleichbaren Auslieferungsdimensionen und wiederholbaren Verbesserungszyklen. 12

Better Harness liefert dafür eine praktische Umsetzung. Teams können damit die Bedingungen rund um Agent-Arbeit in unterstützten Umgebungen prüfen, über Evidenz statt über Eindrücke sprechen und testen, ob eine vorgeschlagene Workflow-Reparatur auch in späteren Durchläufen Bestand hat. Der Wert des Werkzeugs liegt nicht in einer Garantie für bessere Ergebnisse, sondern in einem disziplinierteren Verfahren, das Agent-Workflows überprüfbar, begutachtbar und widerlegbar macht. 46