Harness Engineering: die Architektur-Disziplin der Stunde

Vom Prompt zum System

Die erste Welle der KI-Entwicklung drehte sich um Prompts. Die zweite um Tools und Kontext. Die dritte, in der wir jetzt stehen, dreht sich um das System, in dem Agenten arbeiten.

Wer einen Coding-Agenten ohne Leitplanken auf ein Projekt loslässt, bekommt Output, der plausibel aussieht und in jeder Iteration anders ausfällt. Mal liegt das Repository im Domain-Layer, mal in der Infrastruktur. Mal gibt es Tests, mal nicht. Das geht schnell, lässt sich aber nicht wiederholen: der nächste Durchlauf entscheidet wieder anders. Genau darum landen viele Teams nach ein paar Wochen Begeisterung wieder bei «wir machen es lieber von Hand».

Das liegt selten am Modell. Es liegt daran, dass niemand das System um das Modell herum gebaut hat.

Was ein Harness ist

Ein Harness ist die Sammlung von Dateien und Tools, die definiert, wie sich Agenten in einem Projekt verhalten. Menschen bauen es, Agenten führen es aus. Es liegt im Repository, es wird reviewt, versioniert und weiterentwickelt wie jeder andere Code auch.

Konkret besteht ein Harness aus mehreren Schichten:

Zwei Zeilen brauchen einen Halbsatz mehr. Quality Gates sind zum grössten Teil klassisches Handwerk, das auch ohne KI schon lief: Commit-Hooks, Pipelines, Tools wie SonarQube. Und MCP steht für Model Context Protocol, die offene Schnittstelle, über die ein Agent Systeme ausserhalb des Repositories erreicht, etwa ein Ticketsystem oder eine Datenbank.

Der entscheidende Satz dahinter lautet: Wenn dir der Output eines Agenten nicht gefällt, verbessere den Harness, nicht den Output.

Das ist ein Perspektivwechsel. Wer eine generierte Datei von Hand nachbessert, behandelt ein Symptom. Wer die Regel ergänzt, die zur falschen Datei geführt hat, löst das Problem für alle künftigen Durchläufe.

Drei Modelle, wie Mensch und Agent zusammenarbeiten

Es hilft, die eigene Position auf einem Spektrum zu verorten.

Outside the loop, im Volksmund «Vibe Coding». Der Agent produziert, du akzeptierst oder startest neu. Keine systematische Qualität, keine Nachvollziehbarkeit, unvorhersehbar, sobald mehrere Leute damit arbeiten. Für einen Prototyp am Freitagnachmittag reicht das, für einen Geschäftsprozess in einer Verwaltung nicht.

In the loop. Du gibst jedes Artefakt frei, der Agent pausiert bei jeder Unklarheit. Die Kontrolle ist hoch, der Durchsatz hängt an dir. Bei drei parallelen Agenten kommst du zu nichts anderem mehr als zu Reviews.

On the loop. Du gestaltest und pflegst den Harness, der Agent arbeitet darin autonom. Trifft er auf eine Lücke, entscheidet er auf Basis bestehender Muster, dokumentiert die Entscheidung und macht weiter, statt zu pausieren. Du reviewst anschliessend die dokumentierten Entscheidungen.

Wir arbeiten bei Puzzle auf das dritte Modell hin. Der Mensch bleibt im «Why Loop»: Idee, Feature-Entscheidung, Harness-Pflege, Bewertung der Resultate. Der Agent übernimmt den «How Loop»: Spec, Design, Code, Tests, Quality Gate.

Der Puzzle Harness

Wir betreiben einen eigenen Harness und pflegen ihn wie ein Produkt. Er läuft auf Claude Code und auf OpenCode, zwei CLI-Agenten, die dieselben Markdown-Artefakte lesen. Diese Wahl ist bewusst so gefallen, dazu weiter unten mehr.

Was drinsteckt:

Eigene Agents. Spezialisierte Reviewer für Architektur-Compliance, für Security entlang der OWASP Top 10 (der Standardliste der häufigsten Schwachstellen in Webanwendungen), für die Spec-zu-Test-Abdeckung und für den Puzzle-QM-Guide. Dazu Agents für Konzeptarbeit, Implementierung und die Pflege des Harness selbst.

Eine Spec-Ebene. Anforderungen stehen als GIVEN/WHEN/THEN-Szenarien da: Ausgangslage, Auslöser, erwartetes Resultat. Statt «das System soll benutzerfreundlich sein» steht dort ein Abnahmekriterium, gegen das ein Agent testen kann. Als Werkzeug dafür nutzen wir OpenSpec, ein offenes Format für spec-getriebene Entwicklung.

Ein Quality Gate, das sich nicht überspringen lässt. Nach jeder Implementierung laufen Architektur-, QM-Guide- und Testabdeckungsprüfung parallel. Der Security-Review läuft immer zuletzt und nie parallel, damit ihn keine Teilresultate beeinflussen. Befunde werden nach Schweregrad behandelt: CRITICAL eskaliert an den Menschen und blockiert, HIGH behebt der Agent im Rahmen der bestehenden Spec selbst, MEDIUM und INFO landen im Bericht.

Shift Left statt Endkontrolle. Der Agent wartet nicht auf das Gate, um Probleme zu finden. Nach jedem Task läuft das Testkommando, jede THEN-Klausel der Spec wird gegen die Implementierung geprüft, und abgehakt wird nur, was grün ist. Läuft das Gate dann, findet es im Idealfall nichts mehr.

Skills mit Puzzle-Wissen. OpenShift, Argo CD, GitLab CI, Harbor, Monitoring, Renovate: das operative Wissen, das sonst in Köpfen und Wiki-Seiten liegt, als ladbares Kontextmodul.

Ein Feedbackkanal vom Agent zum Menschen. Jede Entscheidung, die der Agent mangels expliziter Regel selbst treffen musste, landet in einer Notizdatei im Repository, zusammen mit dem Vorschlag, welche Regel diese Unklarheit künftig verhindert. Diese Datei ist der Punkt, an dem der Mensch wieder einsteigt: durchlesen, entscheiden, als Regel in den Harness schreiben.

So ist das Schwungrad angelegt: Agent arbeitet, dokumentiert Entscheidungen und Lücken, Mensch verdichtet sie zu Regeln, der nächste Zyklus braucht weniger eigene Entscheidungen. Wie viele Runden es braucht, bis kaum noch etwas Undokumentiertes übrig bleibt, sehen wir gerade in den ersten Projekten.

Warum das Architektur ist und nicht Prompting

Ein Harness zu bauen verlangt genau die Fähigkeiten, die gute Softwarearchitektur schon immer verlangt hat, nur an einer neuen Stelle angewendet:

• Abstraktionsebenen trennen. Was gehört in immer geladene Grundregeln, was in einen Skill, der nur bei Bedarf geladen wird, was in die Spec eines einzelnen Features? Kontextfenster sind ein knappes Gut und werden budgetiert wie Speicher.
• Schnittstellen definieren. MCP-Server sind die Systemgrenze eines Agenten. Wer welche Tools bekommt, ist eine Sicherheitsentscheidung.
• Qualität messbar machen. Evaluations-Frameworks sind für Agenten das, was Testpyramiden für Code sind. Erst damit lässt sich zeigen, dass eine Harness-Änderung wirklich etwas verbessert hat.
• Nichtfunktionale Anforderungen durchsetzen. Security, Nachvollziehbarkeit und Reproduzierbarkeit werden von Anfang an eingebaut, im Harness genauso wie im Code.

Das ist Architekturarbeit. Das Ergebnis ist ein Regelwerk, das ausgeführt wird.

Neue Rollenbilder

Daraus entstehen konkrete Rollen. Drei Muster begegnen mir in Ausschreibungen und Anfragen der letzten Monate immer wieder:

Der Harness Engineer trägt die technische Gesamtverantwortung für die Agentenplattform: Coding-Agenten produktiv machen, MCP-Server betreiben, Kontext-Engineering, Security, Evaluations-Frameworks. Eine Plattform-Engineering-Rolle, bei der ein Teil der Nutzung von Maschinen kommt.

Der Forward Deployed Engineer arbeitet nah an der fachlichen Problemstellung, mit End-to-End-Verantwortung und selbst produktiv mit Coding-Agenten. Erfahrene Ingenieur:innen, die den Qualitätsmassstab setzen. Die entscheidende Fähigkeit ist dabei, zu beurteilen, ob generierter Code trägt, und dazu gehört eine belastbare Test- und Qualitätspraxis.

Der Specification Engineer baut die Spec-Ebene: Spec-Driven Development in der Praxis, maschinell prüfbare Abnahmekriterien, saubere Requirements. Auffällig ist, dass klassische Requirements-Engineering- und Business-Analysis-Kompetenz hier plötzlich wieder hohen technischen Hebel bekommt. Eine unpräzise Anforderung kostete früher eine Nachbesserungsrunde. Heute kostet sie zwanzig statt zwei generierte Dateien.

Für diese Rollen braucht es keine neue Ausbildung. Es braucht die Einsicht, dass jetzt das System das Produkt ist.

Der Souveränitätsaspekt

Ein Harness ist ein Asset, das dir gehört.

Unserer besteht aus Markdown-Dateien, YAML-Konfiguration und offenen Konventionen wie AGENTS.md, MCP und OpenSpec. Er liegt im Git-Repository des Projekts. Er läuft auf Claude Code und auf OpenCode. Wenn sich morgen das bevorzugte Modell oder das bevorzugte CLI ändert, wandert das gesammelte Projektwissen mit: Architekturregeln, Qualitätskriterien, Domänenbegriffe, Betriebswissen.

Das ist der Unterschied zwischen «wir nutzen ein KI-Tool» und «wir bauen eine Fähigkeit auf». Das Tool ist austauschbar, und genau deshalb darf der Harness es nicht sein. Wer sein Agenten-Setup in der proprietären Oberfläche eines einzelnen Anbieters aufbaut, legt sein Prozesswissen dort ab.

Open Source ist hier die technische Voraussetzung dafür, dass die Investition in den eigenen Harness auch in fünf Jahren noch etwas wert ist.

Fazit

Coding-Agenten sind ein System, das gebaut, gepflegt und weiterentwickelt werden will. Das ist Architekturarbeit.

Wer heute anfängt: Schreib die Spielregeln auf. Dokumentiere den Stack, die Architektur, die Konventionen, die Domänenbegriffe und was eure Entwicklungskultur sonst noch ausmacht. Lass einen Agenten damit arbeiten. Notiere jede Stelle, an der er raten musste. Verdichte diese Notizen zu Regeln. Wiederhole. Es ist Vergleichbar mit dem Junior im ersten Arbeitsjahr. Alles was du ihm mündlich, musst du der KI schriftlich beibringen.

Das ist der ganze Trick. Der Rest ist Ausdauer.

PS: Was dieser Beitrag auslässt, sind die Kosten. Wie viele Tokens ein Quality Gate frisst, wann sich ein lokales Modell lohnt und wie man Evaluations für Agenten sauber aufsetzt, ist einen eigenen Beitrag wert.