primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.“ DORA State of AI-assisted Software Development 2025 +243 % mehr Incidents pro Pull Request 31 % mehr ungeprüfte Merges −19 % gemessen langsamer Coding Agents schreiben Code, doch Software-Entwicklung ist mehr. Verifikation und Kontext- Einschätzung sind der Flaschenhals und deutlich schwerer zu automatisieren. „Key Takeaways from the DORA Report 2025" (Git-Telemetrie-Analyse), faros.ai „Key Takeaways from the DORA Report 2025" (Git-Telemetrie-Analyse), faros.ai „Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (Juli 2025), metr.org
um sie produktiv ohne Aufsicht einzusetzen. Harness Engineering automatisiert diese Aufsicht teilweise, benötigt aber selbst Engineering-Arbeit*. * Harness wird entworfen, hat Bugs, braucht Tests, wird iteriert und muss sich weiterentwickeln
Harness Prompt, Tools, Kontext, Regeln, Prüfungen Euer Gestaltungsraum Agent = Model + Harness Quelle: „The Anatomy of an Agent Harness“, LangChain Model „TLDR: Agent = Model + Harness. Harness engineering is how we build systems around models to turn them into work engines. The model contains the intelligence and the harness makes that intelligence useful. […]“
BUILDER Modell Builder Harness Der innere Ring ist vom Tool-Hersteller: System-Prompt, Retrieval, Orchestrierung User Harness Der äußere Ring ist von euch, für euer System: alles, womit ihr den Agent führt und prüft. Der äußere Ring ist euer Gestaltungsraum.
reifsten, viel Tooling Architecture Fitness Architekturziele durchsetzen einiges an Tooling, (noch) nicht breit eingesetzt Behaviour funktionale Korrektheit am schwierigsten Unser Fokus heute liegt hier
wirkt, bevor der Agent handelt Feedforward Agent handelt SENSOR prüft, nachdem der Agent handelt Feedback AUSFÜHRUNG Regelbasiert berechnet, schnell, zuverlässig KI-gestützt KI-gestützt, semantisch, probabilistisch
Tool-Whitelists z.B. Projekt-Templates Instruktionen z.B. AGENTS.md, Skills Tests z.B. Archunit, Linter, Type-Checker Intelligente Prüfungen z.B. LLM-as-Judge, Review- Agent
Development ist ein KI-gestützter Guide: die Spec steuert den Agent und aus ihr entstehen zugleich die Sensoren (Akzeptanzkriterien). Kategorie “Behavioral Harness” Spec beschriebt Systemverhalten und wird zur Quelle der Wahrheit Aber … Löst nicht die Frage, ob der Mensch (der die Spec formuliert/liest) das Problem überhaupt verstanden hat. Beispiele: GitHub Spec Kit, AWS Kiro, Tessl
Fitness Functions z. B. ArchUnit, dependency-cruiser CI/CD Quality Gates etablierte Pipeline-Prüfungen Control Theory / Ashby Regulator braucht so viel Vielfalt wie das System Harness Engineering = Synthese für einen neuen Failure-Modus à nicht-deterministische Generatoren. Ford/Parsons/Kua, „Building Evolutionary Architectures“, W. R. Ashby, „An Introduction to Cybernetics“
1.300+ PRs/Woche Agent-Flotte „Minions“, „Blueprints“, „Toolshed“ (~500 Tools) OpenAI ~1 Mio. Zeilen 3 Engineers, ~1.500 PRs / 5 Monate „With coding agents, [constraints are] an early prerequisite; they're what allow speed without decay or architectural drift.“ Anthropic Multi-Agent Planner / Generator / Evaluator-Harness „Every component in a harness encodes an assumption about what the model can't do on its own.“ Quellen: stripe.dev, openai.com, anthropic.com
Entities Aufgabe an den Agent „Add a new endpoint GET /api/profiles/top?limit=10 to this app. It returns the top N user profiles ranked by their follower count (descending). For each profile include: username, bio, image, follower count, and the user's email address. TypeScript-Backend mit ORM, Schichtenarchitektur (NestJS + MikroORM)
SQL im Service. Hardcoded Tabellennamen, ORM umgangen. PII E-Mail im öffentlichen Listing-Endpoint exponiert. Bounds limit-Parameter ohne Obergrenze (ist ein DoS-Angriffsvektor).
Guide Feedforward, regelbasiert. Die PII-Regel: kein PII in Listing-Endpoints. Cross-Tool-Standard AGENTS.md ist ein offener Standard (Agentic AI Foundation), kompatibel mit vielen Coding Agents Selber schreiben LLM-generierte Kontextdateien können manchmal weniger effektiv sein.
Semgrep-Regel Verbietet Raw SQL im Service-Layer (regelbasiert, schnell) Agent-instruktive Message Sagt dem Agent warum ein Fehler existiert und wie er zu beheben ist Ein Agent mit gezieltem Verifikations-Kontext machte ~70 % weniger neue Fehler. Eine vage Anweisung ohne diesen Kontext machte es schlimmer (“mach TDD”). → Entscheidend ist wie präzise der Sensor antwortet. Quelle: TDAD, arXiv:2603.17973
den Diff gegen die AGENTS.md-Regeln für semantische Verstöße. Backstop Falls der Agent den Guide nicht befolgt, fängt der Judge es. Defense in Depth. Implementierungs-Landschaft Direct-Call, Hook, Sub-Agent, MCP KI-gestützt = semantisch reich, aber probabilistisch.
OHNE HARNESS MIT HARNESS Layer Raw SQL im Service QueryBuilder, im ORM-Layer PII email exposed kein Email-Feld, Test prüft Abwesenheit Bounds nur untere Schranke Ober- und Untergrenze (Max 100)
ist kein einmaliges Setup, sondern Software, mit allem, was dazugehört: Bugs sie hat Fehler Tests muss geprüft werden Iteration Regeln nachschärfen Evolution ändert sich mit AUS DEM EXPERIMENT Unsere eigene Harness hatte zwei Bugs: eine Semgrep-Regel, die generische Typen nicht erkannte, und ein Judge, der den falschen Diff verglich. Eine Harness ist nie fertig. Pflege ist laufende Architekturarbeit.
Fehldiagnose Overengineering Missverstandene Anweisung à Regelbasierte Sensoren fangen Struktur zuverlässig, KI-gestützte fangen Semantik teilweise. à Sensoren können nur abfangen, was Menschen explizit formulieren und spezifizieren. Der Mensch bleibt der Sensor letzter Instanz.
viel Harness ihr bauen könnt, hängt davon ab, welche Eingriffspunkte euer Coding-Agent-Tool euch lässt. Mehr Eingriffspunkte → mächtigere Harness Hooks (Code, der vor/nach jeder Agent-Aktion läuft), Regel-Dateien, Tool-Freigaben. Eine Blackbox lässt sich kaum harnessen. Dieselben Rechte sind Angriffsfläche Ein Agent mit breitem Tool-Zugriff ist angreifbar (Prompt-Injection). Die Rechte des Agents bewusst zuzuschneiden gehört zur Harness. Bei Tool-Auswahl, muss die “harnessbarkeit” ein wichtiges Kriterium sein. Hintergrund: Ashbys „Requisite Variety
Keine große kontrollierte Studie belegt bisher die holistische Effektivität von Harness Engineering. WIR KENNEN DAS PROBLEM DORA, Faros AI ohne Struktur verschlechtert die Delivery-Stabilität. ES GIBT INDIKATOREN TDAD Gezielter Kontext senkt Regressionen ~70 % IN DER PRAXIS POSITIVE SIGNALE Stripe, OpenAI, Anthropic Harnesses funktionieren produktiv und im großen Maßstab.
sich eine Codebasis für Agents führen und prüfen lässt. Eine Architektur-Qualitätseigenschaft wie Wartbarkeit oder Skalierbarkeit. Starke Typisierung Type-Checking gibt es praktisch geschenkt. Klare Modulgrenzen erlauben architektonische Constraint-Regeln. Opinionated Frameworks abstrahieren weg, worum der Agent sich nicht kümmern muss. Brownfield-Codebasen haben oft geringe “Harnessability”
große Codebasis harnesst man nicht auf einmal. Jeder Agent-Fehler wird zu einem neuen Guide/Sensor. der erste Guide/Sensor neue kommen dazu tragfähige Harness Zeit ▸
Code schreiben früher der Kern Harness schreiben jetzt der Hebel Architekturarbeit wird wichtiger Kontext verstehen, Ziele klären, Regeln formulieren. Die Harness amortisiert Ein Sensor von heute schützt jeden zukünftigen PR.
tragt Was euch in der Praxis erwartet: Harnesses brauchen Pflege Qualität von Guides/Sensoren sind Handwerk Brownfield ist zäh Team-Buy-in ist nötig Der Nutzen kommt nicht sofort Harness kostet Tokens
brauchen eine Harness um zuverlässig zu sein. Harness Engineering ist Engineering Code, Tests, Evolution. Architekturarbeit wird wichtiger nicht obsolet. Aufgabe: Nimm ein Architekturziel, formuliere es als einen Sensor, lass einen Coding Agent dagegen laufen.
eileencodes
addyosmani
ks91
ipullrank
aleyda
axbom
tammyeverts
philnash
aki_iinuma
marketingsoph
rmw
speakerdeck
![1 Harness Engineering embarc.de Alexander Kaserbacher [email protected] www.embarc.de Software Architekt](https://files.speakerdeck.com/presentations/2332d5184f904bd1a2cee0ef0348699a/slide_1.jpg){kind=link}
