Der Begriff „Harness“ bezeichnet alles, was ein KI-Modell innerhalb eines Agenten umgibt. Birgitta Böckeler schlägt ein konzeptuelles Rahmenwerk vor, das speziell für Nutzer von Coding-Agenten gilt, und unterscheidet zwischen dem internen Harness (vom Ersteller des Agenten gebaut) und dem externen Harness (das Nutzer für ihren eigenen Kontext bauen).
Das Modell ist um zwei komplementäre Mechanismen organisiert. Guides (Feedforward-Kontrollen) antizipieren das Verhalten des Agenten und lenken es, bevor er handelt: Coding-Konventionen, Spezifikationen, Skills, MCP-Server. Sensoren (Feedback-Kontrollen) beobachten nach der Handlung und ermöglichen dem Agenten eine Selbstkorrektur: Linter, Tests, statische Analyse, KI-Code-Reviews. Jeder Mechanismus kann computational (deterministisch, schnell, zuverlässig) oder inferentiell (semantisch, kostspieliger, nicht-deterministisch) sein. Beide sind notwendig: ohne Feedback wiederholt der Agent seine Fehler, ohne Feedforward kodiert er Regeln, ohne zu wissen, ob sie funktionieren.
Der Artikel wendet das Shift-Left-Prinzip an: Kontrollen so früh wie möglich im Entwicklungszyklus verteilen. Schnelle Kontrollen (Linter, Unit-Tests) laufen vor dem Commit, während kostspieligere (Mutation Testing, architektonisches Review) in der Integrationspipeline laufen. Kontinuierliche Sensoren überwachen Code-Drift und Produktionsmetriken.
Es werden drei Regulierungskategorien identifiziert. Das Harness für Wartbarkeit ist am ausgereiftesten und stützt sich auf bestehendes Tooling (Linter, Komplexitätsanalysatoren, Testabdeckung). Das Harness für architektonische Eignung greift auf das Konzept der Fitness-Funktionen für nicht-funktionale Eigenschaften zurück. Das Harness für Verhalten bleibt die größte Herausforderung: Wie lässt sich verifizieren, dass die Anwendung das tut, was sie tun soll? KI-generierte Testsuiten sind noch nicht zuverlässig genug.
Das Konzept der Harnessability unterstreicht, dass nicht alle Codebasen gleichermaßen für ein Harness geeignet sind. Typisierte Sprachen, abstrakte Frameworks und modulare Architekturen bieten mehr Ansatzpunkte. Ashbys Gesetz der Kybernetik rechtfertigt Harness-Templates: Durch Reduzierung der Vielfalt möglicher Topologien (Dashboard, CRUD, Event-Prozessor) wird ein vollständiges Harness erreichbarer.
Die Autorin kommt zu dem Schluss, dass menschliche Erfahrung ein unersetzliches „implizites Harness“ bleibt. Das Ziel ist nicht, den Menschen zu eliminieren, sondern seine Aufmerksamkeit auf das Wesentliche zu lenken. Harness Engineering ist eine kontinuierliche Engineering-Praxis, keine einmalige Konfiguration, und viele Fragen zu Konsistenz, Bewertung und Orchestrierung des Harness bleiben offen.