Das Modell kannst du nicht ändern. Ändern kannst du den Harness.
Agent = Model + Harness.

Was sich nicht ändern lässt und was sich bauen lässt

SOFTWARE · 2026

Zuerst ein Rahmen. Heute ist diese Definition üblich: Agent = Model + Harness. Das Modell kannst du nicht ändern; die Zentrale bestimmt und liefert es. Ändern kannst du den Harness: Dokumente, Regeln, Berechtigungen und Überwachung rund um das Modell.

KI richtig arbeiten zu lassen heißt deshalb, einen Harness zu bauen, statt auf ein besseres Modell zu warten. Die Software ist der Verdächtige. Trennen wir die Aufgaben, die sie erledigen muss, von den Vorrichtungen, die sie dazu bringen.

Die Disziplin der Software

SOFTWARE · 2026

Die Mindestdisziplin für eine Maschine. Keine Bitte, sondern fest in den Harness eingebaut.

Keine Mutmaßungen: Zustände von Datenbank, API, Build und Dateien nicht nach eigener Fantasie melden. Ungeprüftes als ungeprüft benennen. Ungemessenes als Schätzung kennzeichnen.

Geständnisse schreiben: Bei einem Fehler hält die Maschine selbst fest, was falsch war, wie es aufgedeckt wurde, was die Grundursache ist und welche Regel Wiederholung verhindert. Vor der Arbeit liest sie das Geständnis erneut.

Ohne Beleg kein Abschluss. Original statt Zusammenfassung. Urteil und Exit-Code statt „Bestanden“. Kein „fertig“ vor bestandener Gegenprüfung. Dazu Ausflüchte verbieten: „wahrscheinlich gut“, „unbestätigt“ und „nicht beurteilbar“ heißen am Ende alle „nicht nachgesehen“.

Menschlicher guter Wille setzt diese Disziplin nicht durch. Das tun die Dokumente und Vorrichtungen der nächsten Sektion.

Aufträge geben = Dokumente, der Körper des Harness

SOFTWARE · 2026

Die Maschine bewegt nicht das Anschreien im Chatfenster, sondern die Dokumente um sie herum. Warum jedes nötig ist, bildet den Kern der Methode. Die folgenden sieben sind das Gerüst, das gut laufende Projekte ausnahmslos teilen.

① Die verbindliche Quelle, SSOT: eine Wahrheit an genau einem Ort, auf den alles andere verweist. Steht dieselbe Tatsache zweimal, werden beide irgendwann abweichen, und die Maschine wählt die bequemere. Deshalb keine festen Anzahlen und Zahlenwerte in Dokumente schreiben, sondern die Befehle zum Zählen.

② Die Pyramidenhierarchie: Änderungen nur von oben nach unten. Planung (Why) → Regeln → Spezifikation → Code → Verlauf. Weitergabe in einer Richtung. Weicht Code von der Planung ab, wird der Code korrigiert. Die Planung ist die richtige Antwort.

③ Fortschritt: Was ist jetzt wahr? Die Maschine schätzt den Zustand. Deshalb den aktuellen Projektstand in einem Dokument fixieren, damit sie nicht schätzen muss.

④ Übergabe: Sitzungen verlieren ihre Erinnerung. Jede ist eine neue Aushilfe. Was die vorige Sitzung tat und was festgeschrieben wurde, muss die nächste zuerst lesen. Ein Stapel Geständnisse, der sie am nächsten Morgen wieder mit Fehlern konfrontiert.

⑤ Gesperrte Entscheidungen (ADR): Neuverhandlungen verhindern. Ohne Festschreibung kippt und diskutiert die nächste Sitzung dieselbe Entscheidung erneut. Entscheidungen an einem Ort sammeln und gegen erneute Debatte sperren.

⑥ Synchronisationsregeln: Kopien laufen auseinander. Teilen mehrere Repositories ein Dokument, seine tatsächliche Gleichheit byteweise abgleichen. Nicht „gleich“ glauben, sondern diff verwenden.

⑦ Branch-Regeln: Schwer Umkehrbares bleibt beim Menschen. feature → develop → main, nur vorwärts. Deployment nach main nur durch Menschen. Keine Umgehung von Prüfungen. Durch alle sieben zieht sich ein Satz: Architekturprinzipien sind wichtig, weil sie Context Rot verhindern, nicht wegen ihrer Eleganz. Kurz halten, eine Sache an einem Ort.

Überwachungsvorrichtungen – Durchsetzung hat Stufen

SOFTWARE · 2026

Dokumente formulieren Regeln, Vorrichtungen setzen sie durch. Doch Erklärung ist nicht Durchsetzung. Zu schreiben, ein Sensor müsse unbedingt laufen, und sein tatsächlicher Lauf sind völlig verschiedene Dinge. Deshalb Durchsetzung in vier Stufen verstehen, von schwach bis stark.

Je wichtiger eine Regel, desto weiter muss sie nach unten auf C oder D. Bleibt sie nur in Prosa auf A, ignoriert die Maschine sie plausibel. Agenten, Skills, Sensoren und Hooks sind die Sprossen dieser Leiter. Und was ist ein Beleg? Urteilszeile, Exit-Code und originales stdout. Bleibt nur eine Zusammenfassung, kann ein falsches PASS darin verschwinden.

Ein lebendiges Beispiel – Warum ADRs ständig vergessen werden

SOFTWARE · 2026

Warum diese Leiter zählt, zeigen Architekturentscheidungsprotokolle, ADRs. Jeder kennt „Architekturentscheidungen aufschreiben“. Doch bei Aufträgen im Chat werden Code und Dokumente geändert, während der ADR immer wieder fehlt. Warum?

Weil ADRs kein Bruchsignal haben. Ohne Code scheitert das Kompilieren, ohne Tests erscheint eine rote Lampe. Ohne ADR bricht nichts. Es hängt nur an der Prosaregel „Aufschreiben“, Stufe A, und bei Zeitdruck überspringt die Maschine sie plausibel. Regelwichtigkeit und Durchsetzungsstufe passen nicht zusammen.

Die Reparatur führt die Leiter hinunter: ein Bruchsignal künstlich erzeugen. Berührt ein Commit Entscheidungsspuren wie Abhängigkeiten, Schema, Einstellungen oder Architekturdokumente, wird er gesperrt, wenn im Entscheidungsordner ein Eintrag vom selben Datum fehlt. Stufe D. Ohne die Entscheidung aufzuzeichnen kommt die Änderung nicht hinein, so wie ohne Tests kein Push möglich ist.

Dieselbe Krankheit hat das erneute Lesen von Geständnissen. Das Schreiben erzwingt ein Hook auf D, das Lesen vor der Arbeit bleibt der Erinnerung auf A überlassen. Bei Zeitdruck wird nicht gelesen. Gleiche Reparatur: Das Geständnis muss dich aufsuchen. Die Lehre lautet: Wichtige Regeln müssen „Kein Durchgang“ heißen, nicht „Daran denken“.

Der eigene Harness genügt nicht

SOFTWARE · 2026

Bis hierher ist es der Selbst-Harness der Software: dokumentarisch beauftragen, in vier Stufen erzwingen und mit Belegen prüfen. Das ist stark, darf aber nicht das Ende sein. Der Theorieteil warnte: Baut der Überwachte die Überwachung, wird sie Theater. Auch diesen Harness baut und pflegt die Maschine selbst. Irgendwann laufen Sensoren nicht, Gates werden leere Dateien und das zuletzt platzierte Red Team wird ignoriert.

Darüber braucht es ein Auge von außen, das prüft, ob der Harness wirklich beißt. Die Bedingungen sind streng: außerhalb des Projekts, ohne die Geschichte des Erbauers zu lesen, nur nach externen Verträgen und allgemeinen Regeln urteilend. Angriffe aus unerwarteten Richtungen: andere Modelle, nicht vorbereitete Eingaben und Probes gegen den tatsächlichen Deployment-Zustand. Dazu am Veröffentlichungstor stehen, Fehler vorher fangen und bei bereits erfolgter Veröffentlichung einen Rollback anordnen.

Das ist kein Selbst-Harness mehr, sondern ein zweiter Vernehmer, der ihn verhört. Selbst dem ersten Vernehmer, dem arbeitenden Claude, wird nicht geglaubt. Deshalb besteht die Methode aus zwei Paketen: eines innerhalb des Projekts für Verhöre während des Baus, eines außerhalb zur Bewachung des Deployment-Tors.

Code, den Menschen und Maschinen lesen können

CODA · 2026

Ein alter Satz über guten Code lautet: Jeder kann Code schreiben, den Computer verstehen; gute Programmierer schreiben Code, den Menschen verstehen. Im Zeitalter des Bauens mit Maschinen lässt er sich umschreiben: Gute Nutzer schreiben Code und Dokumente, die KI und Menschen gleichermaßen verstehen.

Dokumente sind nicht für Menschen da. Sie dienen dem Verhör von Maschinen. Gut geschriebene Dokumente können auch Menschen lesen.