Harness Engineering
Aktualisiert:
Was ist ein Harness, und warum zählt er mehr als das Modell?
Unsere Position: Der Harness ist wichtiger als das Modell. Das Modell ist ein Parameter, der Harness ist das System, in dem es läuft. Kommt ein neues Modell, ändert sich dieser eine Parameter. Umgebung, Regeln, Gates und Feedback-Schleifen bleiben, und sie bestimmen, was am Ende herauskommt.
Ein Harness listet auf, was das Modell allein noch nicht zuverlässig kann. Ein guter Harness benennt deshalb ehrlich, wo er dem Modell nicht traut, nicht mehr und nicht weniger. Er darf also auch kleiner werden: Ein schlanker Harness baut Scaffolding ab, sobald ein neues Modell-Release zuverlässig beherrscht, was bisher abgesichert werden musste.
Warum müssen Gates schneller wachsen als die Code-Erzeugung?
Agenten optimieren darauf, die Gates zu bestehen. Sind die Gates schwach, entsteht viel Output, der nicht zu gebrauchen ist. Gates und Validierung müssen deshalb schneller wachsen als die Erzeugung.
Damit ändert sich die Arbeit der Engineers. Ihr schreibt das Produkt nicht mehr selbst, ihr baut die Factory, die es baut.
Zeichnet jeden Agentenlauf und jede Änderung durch einen Agenten auf, damit ihr den Harness nachschärfen könnt. Dann könnt ihr die Factory debuggen, auditieren und verbessern. Sicherheit und Isolation zur Laufzeit liegen unterhalb des Agenten, und die ersetzt ein Harness nicht.
Wie wird aus einem Harness eine Software Factory?
Was dabei entsteht, ist eine Software Factory: ein System, das dauerhaft läuft. Es nimmt Arbeit an, verteilt sie an Agenten, prüft ihren Output an Gates, liefert aus, was besteht, und lernt aus jedem Lauf. Die Modelle reichen von Pipelines, die aus einem Ticket einen Pull Request machen, über Dark Factories bis zu Agenten-Unternehmen, die als autonome Geschäftseinheiten arbeiten.
Wie weit das reicht, zeigen drei Beispiele aus unserem Ressourcenkatalog. Clipboard beschreibt eine Pipeline, die Backlog-Tickets über Nacht in reviewte Pull Requests umsetzt, während das Team schläft. Onas öffentliches Memo-Experiment baut ein Produkt vollständig über verkettete Automationen wie Feature Planner, Builder, Verifier und Incident Responder. Die Absicht geben Menschen vor. Paperclip führt Teams aus KI-Agenten als autonome Geschäftseinheiten, mit Organigramm, Budget, Governance-Gates und Audit-Log.
Einen einzelnen Agenten zu bauen gehört zu Methoden und Frameworks, viele Agenten zu koordinieren zur Multi-Agent-Orchestrierung. Die Software Factory liegt eine Schicht darüber.