KI-Assistenten produzieren Code, der plausibel aussieht – aber ohne Begrenzung driften sie ab. Das ist die Beobachtung, die Birgitta Boeckeler in ihrem Artikel auf martinfowler.com beschreibt, und sie dürfte jedem Team bekannt vorkommen, das KI-Coding-Assistenten ernsthaft einsetzt. Der Code kompiliert, die Tests laufen grün, und trotzdem verschlechtert sich die interne Konsistenz der Codebasis langsam aber sicher. Naming-Konventionen werden aufgeweicht, Architekturregeln umgangen, und irgendwann ist das Projekt ein Flickenteppich, den kein Mensch mehr überblickt. Das Tückische: Der Verfall ist leise. Er passiert nicht auf einen Schlag, sondern in vielen kleinen, plausibel wirkenden Abweichungen, die keine bestehende Prüfung bemerkt.
Ein Harness für KI-Code: Die Logik der Tests übertragen
Die Lösung liegt in einer Übertragung einer alten Idee. Tests machen Code nicht korrekt, indem sie ihn erstellen; sie erkennen, wenn er aufhört, korrekt zu sein. Ein Test-Harness ist kein Zwang, der den Entwickler einschränkt, sondern ein Mechanismus, der fortlaufend prüft, ob das Geschriebene den Standard erfüllt. Diese Logik lässt sich auf die KI-gestützte Entwicklung übertragen – nur mit einem breiteren Prüfumfang. Während Tests funktionale Korrektheit abfragen, braucht es für KI-generierten Code eine Harness, die auch Architekturentscheidungen, Namenskonventionen, Sicherheitsregeln und strukturelle Vereinbarungen überwacht. Genau das nennt Boeckeler Harness Engineering. Von ihr stammen Begriff und Grundgedanke. Alles Weitere in diesem Text — die drei Säulen, die Reifegrade, die Schleifen — ist die Ausgestaltung des Plugins ai-literacy-superpowers, dessen Dokumentation die Quelle dieses Beitrags ist.
Der Unterschied ist entscheidend. Ein funktionaler Test sagt dir, ob das Programm das tut, was es soll. Er sagt dir nicht, ob die neue KI-generierte Funktion die Abstraktionsschicht für Datenbankzugriffe umgangen hat oder eine veraltete Logging-Bibliothek benutzt, die im Projekt längst abgeschafft wurde. Solche Verstöße bleiben unter dem Radar funktionaler Tests, weil das Programm weiterhin korrekt arbeitet – bis später jemand an der falschen Stelle refactort. Ein Harness für KI-Code schließt genau diese Lücke. Er ist das Sicherheitsnetz, das die unsichtbaren Abweichungen sichtbar macht.
Die drei Säulen: Kontext, Architektur, Entropie
Der Kern von Harness Engineering besteht aus drei Komponenten, die zusammenwirken. Die erste ist Context Engineering: Die KI kann nur mit dem arbeiten, was sie weiß. Kennt sie die projekteigene Logging-Bibliothek nicht, erfindet sie eine eigene. Weiß sie nicht, dass globaler Zustand strikt verboten ist, benutzt sie ihn, sobald es bequem erscheint. Deshalb muss der Harness dem KI-Assistenten eine Wissensbasis liefern – in der Praxis ein Dokument namens HARNESS.md, das den Stack, die Architekturentscheidungen, Namenskonventionen und deren Begründung festhält. Das ist kein README für Menschen, sondern ein Kontextdokument für die Maschine, und es muss präzise und aktuell sein.
Die zweite Säule sind Architektur-Constraints. Dass die KI die Regeln kennt, heißt nicht, dass sie sie befolgt. Ein KI-Assistent ist ein probabilistisches System, das Plausibilität optimiert, kein regelbefolgender Roboter. Context Engineering reduziert Verstöße, eliminiert sie aber nicht. Deshalb braucht es Verifikationsslots – definierte Momente im Workflow, in denen eine Prüfung läuft und entweder grün gibt oder den Fortschritt blockiert. Die entscheidende Frage ist dabei, ob die Prüfung mit einem deterministischen Tool wie einem Linter oder Skript erfolgt oder mit einem agentenbasierten Review durch ein Sprachmodell. Deterministische Checks sind schnell und zuverlässig, wenn sich die Regel präzise ausdrücken lässt. Agenten sind teurer und unzuverlässiger, können aber auch semantische Verstöße erkennen, die kein Skript abbilden kann.
Die dritte Säule ist Garbage Collection, das Aufräumen. Eine Codebasis ist ein lebendes System, in dem mit der Zeit Entropie entsteht: toter Code, veraltete Abhängigkeiten, TODO-Kommentare, die niemand mehr anfasst, Konventionen, die still beerdigt wurden. Anders als die ersten beiden Komponenten arbeitet diese nicht beim Schreiben oder Reviewen, sondern nach Zeitplan. Regelmäßig – täglich, wöchentlich – prüfen Agenten oder Skripte, ob die Codebasis bestimmte Sauberkeitskriterien noch erfüllt. Der Output ist keine PR-Blockade, sondern ein Bericht, der auf akkumulierende Probleme aufmerksam macht, bevor sie kritisch werden.
Der lebendige Harness: Selbstreferenz als Feedback-Schleife
Der wichtigste Unterschied zu statischen Regelwerken ist, dass ein Harness selbst lebendig bleibt. Ein einmal geschriebenes Harness-Dokument spiegelt den Wissensstand des Teams zu einem bestimmten Zeitpunkt. Die Codebasis entwickelt sich weiter, neue Muster entstehen, alte Regeln verlieren ihre Bedeutung, und neue KI-Fehler tauchen auf, die ursprünglich niemand vorhergesehen hat. HARNESS.md ist deshalb selbstreferentiell aufgebaut: Es beschreibt nicht nur die geltenden Constraints, sondern auch deren Status – ob sie ungeprüft, per Agent oder deterministisch durchgesetzt werden. Dieses Dokument deklariert, was wahr sein soll; Agenten, Hooks und CI-Checks verifizieren, ob es wahr ist. Der Harness-Audit, ein geplanter Agent, liest die Ergebnisse und aktualisiert die Statuseinträge – so entsteht eine Feedback-Schleife.
Die Selbstreferenzialität ist das, was einen lebendigen Harness von einem toten Dokument unterscheidet. Weil der Harness selbst Gegenstand der Durchsetzung ist – der Audit prüft, ob HARNESS.md den Realzustand korrekt abbildet – wird Vernachlässigung sichtbar statt unsichtbar. Der Alltagszugang zu dieser Selbstkontrolle ist der Befehl /harness-sync, der die Erkennungslogik des Audits ausführt und eine einheitliche Abweichungstabelle präsentiert. Du siehst dann auf einen Blick, wo deklarierte Regeln und tatsächliche Verifikation auseinanderlaufen, ohne ein separates Diagnosetool bemühen zu müssen. Das ist praktische Transparenz.
Progressive Härtung: Vom Bekenntnis zur harten Regel
Nicht jede Constraint ist von Anfang an bereit für eine deterministische Durchsetzung. Progressive Hardening ist die Karriereleiter, auf der Regeln sich entwickeln. Am Anfang steht der Zustand Unverified: Du hast eine Regel in HARNESS.md notiert, weil du sie für wichtig hältst, aber es gibt noch keinen Mechanismus, sie zu prüfen. Das ist kein Scheitern, sondern ehrliche Buchführung – ein ungeprüfter Constraint ist ein Versprechen, eine Prüfung zu bauen, nicht die Behauptung, dass bereits eine existiert.
Der nächste Schritt ist Agent. Jetzt gibt es einen Agent-Prompt, der die Regel beim PR-Review oder in einer regelmäßigen Inspektion prüft. Der Agent ist ein Sprachmodell, das ein Urteil fällt – er erwischt die meisten Verstöße, ist aber nicht perfekt und braucht menschliche Kontrolle. Irgendwann folgt der Zustand Deterministic: Du hast die Regel präzise genug formuliert, um sie als Skript, Linter-Regel oder Strukturcheck zu kodieren. Sie läuft in CI, gibt entweder grün oder blockiert den Merge – ohne Urteilsvermögen, aber auch ohne Verwechslungsgefahr. Die Bewegungsrichtung ist immer von weich nach hart. Wenn ein Agent immer wieder dieselbe Verletzungsklasse findet, ist das ein Signal: Das Muster ist jetzt verstanden genug für Automatisierung. Schreib das Skript, pensioniere den Agenten für diese konkrete Regel, und aktualisiere den Status in HARNESS.md.
Progressive Härtung verhindert zwei Fehlermodi. Der erste wäre der Versuch, von Anfang an alles deterministisch durchzusetzen – das scheitert an neuartigen oder semantisch komplexen Regeln. Der zweite wäre, Agenten als Dauerzustand zu akzeptieren – das ist teuer und unzuverlässig. Die Leiter gibt dir einen Pfad dazwischen. In der Praxis heißt das: Wer klug härtet, gewinnt mit der Zeit ein Regelwerk, das immer weniger Nachsehen braucht.
Drei Schleifen: Wie die Umsetzung konkret aussieht
Damit das Ganze nicht graue Theorie bleibt, setzt ai-literacy-superpowers die Verifikationsslots in drei Durchsetzungsschleifen um, die sich in Frequenz und Härte unterscheiden. Die innere Schleife arbeitet beraterisch zur Bearbeitungszeit. Wenn du eine Datei speicherst oder eine Coding-Session abschließt, laufen leichte Checks, die potenzielle Probleme als Vorschlag anzeigen – nicht als Blockade. Sie ist auf geringen Reibungsverlust optimiert und soll deinen Fluss nicht unterbrechen, sondern Probleme früh sichtbar machen.
Die mittlere Schleife ist streng und läuft zur PR-Zeit. Beim Öffnen eines Pull Requests kommt eine volle Suite aus Agenten- und Deterministischen Checks zum Einsatz. Diese Schleife darf einen Merge blockieren. Sie ist der Hauptdurchsetzungspunkt für Architektur-Constraints. Fehler hier müssen behoben werden, bevor der Code landet. Die äußere Schleife schließlich ist investigativ und arbeitet nach Zeitplan: Garbage-Collection-Regeln, Fitness-Funktionen und Harness-Audits laufen täglich oder wöchentlich. Sie erzeugt Berichte statt Blockaden, und ihre Erkenntnisse fließen als neue Constraints oder Updates zurück in den Harness.
Die drei Schleifen korrespondieren mit den drei Säulen: Die innere dient dem Context Engineering – sie hält die KI im Moment informiert. Die mittlere dient den Architektur-Constraints – sie erzwingt Standards beim Integration-Zeitpunkt. Die äußere dient der Garbage Collection – sie erkennt langsame Entropie zwischen Integrationsereignissen. Wichtig ist: Agenten im Plugin arbeiten mit begrenztem Vertrauen. Kein Agent hat einseitig die Macht, Produktionscode zu ändern oder Merges zu beschließen. Agenten prüfen, schlagen vor, berichten und markieren. Menschen entscheiden. Das ist eine bewusste Designentscheidung: Der Harness verstärkt menschliches Urteilsvermögen, er ersetzt es nicht.
Dazu kommt eine selbst-verbessernde Dimension. Nach jeder Coding-Session protokolliert der Befehl /reflect, was gut lief, was scheiterte, welche Konventionen verletzt wurden und welche neuen Muster auftauchten. Diese Reflexionen sammeln sich in einem Log, das die Harness-Agenten bei ihren Entscheidungen lesen. So beeinflussen vergangene Fehler die aktuelle Review. Auch die Regressionserkennung wirkt in dieselbe Richtung: Der Harness-Audit prüft nicht nur, ob aktuelle Constraints erfüllt sind, sondern ob die Abweichungsmuster sich wiederholen. Das Harness lernt also aus seiner eigenen Betriebsgeschichte – ein evolutionärer Vorteil, den statische Regelwerke nie haben.
Was das für deine Arbeit bedeutet
Harness Engineering ist keine Zauberei, sondern eine konsequente Anwendung alter Ingenieursprinzipien auf eine neue Generation von Werkzeugen. Du musst keine KI haben, die perfekt ist – du brauchst einen Rahmen, der ihre Schwächen abfängt. Der Preis ist Arbeit: Ein Kontextdokument führen, Constraints formulieren, Checks pflegen, Audits lesen. Der Gewinn ist ein weitgehend ruhigeres Gewissen beim Einsatz von KI-Coding-Assistenten. Der Code bleibt kohärent, nicht weil die KI immer richtig liegt, sondern weil dein Harness die Abweichungen sichtbar macht und in geordnete Bahnen lenkt.
Die konkrete Bedeutung für deinen Alltag: Wenn du mit KI-Assistenten arbeitest, solltest du nicht nur auf Tests vertrauen. Du brauchst eine zweite Ebene aus Kontext, Constraints und regelmäßigem Aufräumen. Starte mit einem HARNESS.md, dokumentiere die wichtigsten Architekturregeln, führe einen einfachen Agent-Check bei PRs ein, und härtete nach und nach die Regeln, die sich wiederholen. So nutzt du die Produktivität der KI, ohne ihre Drift zu erben. Das ist die eigentliche Superpower – nicht die KI selbst, sondern die Disziplin, sie in einen stabilen Rahmen zu zwingen.
Quelle: habitat-thinking.github.io
