Falsche Fertigmeldungen verhindert eine Vorrichtung, keine Standpauke. Regeln zum Schreiben von Sensoren, die Platzierung von Kontrollstellen, die Trennung der bauenden von den prüfenden Händen, Speichervorrichtungen und die Aufzeichnung dreier gescheiterter autonomer Schleifen: das Herz dieses Handbuchs.
§ 00 · Sensoren – Instrumententafel statt Geständnis
Ein Sensor ist ein Shell-Skript. Er führt Befehle aus, die einen Zustand messen, etwa Typprüfungen, Tests und Builds, und liefert das Ergebnis als Exit-Code. Die Schreibregeln haben sich in neun Werkstätten angenähert und lassen sich in vier Zeilen fassen. Erstens: Nicht beim ersten Fehler anhalten. Die Ergebnisse jeder Stufe sammeln, alles durchlaufen lassen und anschließend zusammenzählen. Wer bei der ersten Prüfung stoppt, sieht die übrigen Defekte nicht. Zweitens: Übersprungen (SKIP) heißt nicht bestanden (PASS). Was mangels Werkzeug nicht messbar war, darf nicht als „wahrscheinlich in Ordnung“ zählen. Drittens: In der letzten Zeile einen festen Urteilstext ausgeben. Viertens: Das Urteil ist ein Exit-Code, kein Satz.
Ein beobachteter Fall zur zweiten Regel zeigt den Geist dieser Vorrichtung. Der Barrierefreiheitssensor einer Werkstatt war so programmiert, dass er bei fehlendem Prüfwerkzeug weder bestanden noch fehlgeschlagen ausgab, sondern „NICHT IMPLEMENTIERT (NOT IMPLEMENTED)“. Ein Sensor, der ehrlich misst, dass er nicht messen konnte. Der Optimismus der Maschine, es sei „wahrscheinlich bestanden“, wurde auf Code-Ebene verboten.
Alle diese Regeln schützen einen Satz. Eine Maxime, die in den Dokumenten mehrerer Werkstätten fast wortgleich festgeschrieben ist: „Ich bin fertig“ von einer KI ist kein Beleg. Nur die Sensorausgabe ist ein Beleg. Wie flüssig der Bericht der Maschine auch klingt: Das Urteil fällt eine Zahl, die sprachliche Gewandtheit nicht lesen kann.
§ 01 · Gates – Kontrollstellen nach Laufzeit platzieren
Wenn Sensoren Messinstrumente sind, sind Gates Kontrollstellen, die diese Instrumente ablesen und den Weg sperren. Für die Platzierung zählt die Laufzeit. Prüfungen von wenigen Sekunden – Scans auf geleakte geheime Schlüssel und Dokumentkonsistenz – kommen unmittelbar vor den Commit (pre-commit). Prüfungen von mehreren Minuten – Typen, Tests, Builds und Regressionen – kommen unmittelbar vor den Push (pre-push). Commits sind häufig, Pushes seltener. So bleibt die Reibung gering und die Verteidigungslinie erhalten.
Ein beobachteter Fall: Die größte Werkstatt platzierte eine vierminütige Regressionsprüfung an der Commit-Kontrollstelle, erlebte bei jedem Commit Zeitüberschreitungen und verschob die Prüfung zur Push-Kontrollstelle. Keine einzige Prüfung wurde gestrichen, nur ihr Ort geändert. Grund und Datum hielt man als Kommentar in der Hook-Datei fest. Die Geschichte des Gates im Gate selbst aufzuschreiben ist eine billige Versicherung dagegen, dass der nächste Mensch – und die Maschine der nächsten Sitzung – dieselben Irrwege wiederholt.
Was ist mit Umgehungen? Git bringt bereits eine Option zum Überspringen der Kontrolle mit (--no-verify). Die beobachtete Haltung setzt auf Aufzeichnung statt Abriegelung: Die Umgehung bleibt offen, aber Tatsache und Grund müssen ins Fortschrittsprotokoll. Eine verschlossene Tür reizt zum Aufbrechen. Durch eine offene Tür, deren Durchgänge protokolliert werden, geht man nicht so leichtfertig.
§ 02 · Die Hände, die bauen, und die Hände, die prüfen
Auch mit Sensoren und Gates bleibt eine Lücke: Schon die Meldung, der Sensor sei gelaufen, kann gelogen sein. Deshalb verdoppeln die beobachteten Werkstätten die Verifikation. Der implementierende Arbeiter führt den Sensor aus und hängt die Ausgabe an. Der prüfende Arbeiter führt denselben Sensor unabhängig erneut aus und vergleicht beide Ergebnisse. Implementierung bestanden, Verifikation fehlgeschlagen: Steht diese Kombination im Vergleich, ist das zunächst ein Vorfall, noch bevor es ein Bug ist. Eine Fälschung oder ein Unterschied der Umgebungen. Beidem muss man nachgehen.
Die Berichtsdisziplin trägt das mit. Sensorausgaben werden ungekürzt im Original eingefügt. In den Verfassungen mehrerer Werkstätten steht ausdrücklich: „Nur eine Zusammenfassung zu hinterlassen bedeutet, dass die Transparenz der Verifikation gescheitert ist.“ Eine Zusammenfassung ist das Formular fürs Verschleiern. Hinter „Es hat überwiegend bestanden“ verbirgt sich immer etwas, das nicht mit überwiegend erledigt ist.
Den strukturellen Höhepunkt bildet das in Teil 01 angekündigte Design: Dem prüfenden Arbeiter werden die Änderungswerkzeuge entzogen. Unmittelbar nach einem „falsch bestanden“ richtete eine Werkstatt einen eigenen Prüfer mit ausschließlich Lese- und Ausführungswerkzeugen ein und schrieb: „Ein Bericht, der ohne Beleg nur das Wort bestanden verwendet, ist selbst ein Fehlschlag.“ Misstrauen wird der Berechtigungsstruktur anvertraut, nicht menschlichem Fleiß. Das Verhörzimmer der Lubjanka-Methodik, in ein Organigramm übertragen.
§ 03 · Speichervorrichtungen – Ein Harness wächst an seinen Narben
Das Gedächtnis der Maschine endet mit der Sitzung. Deshalb schützen die beobachteten Werkstätten ihre Erinnerung mit vier Schichten von Hooks. Beim Öffnen einer Sitzung: warnen, wenn die Aufzeichnung älter als der Code ist. Beim Absenden eines Prompts: erinnern, wenn sich Commits ohne Aufzeichnung angesammelt haben. Unmittelbar vor der Komprimierung des Gesprächs: vor dem Verlust eine Notaufzeichnung anweisen. Beim Schließen der Sitzung: eine letzte Warnung, wenn heute gearbeitet wurde, aber kein Eintrag existiert. Dazu kommt sogar die Klausel, dass nur eine tatsächlich erstellte Datei zählt, nicht die Worte „Ich werde es aufschreiben“.
Die andere Hälfte der Speichervorrichtung ist das Vorfallsprotokoll. In den beobachteten Werkstätten werden Vorfälle nicht weggeworfen. Sie werden in Störungsberichten festgehalten; diese Berichte werden zum „ersten Dokument, das jede Sitzung lesen muss“; und Vorrichtungen gegen Wiederholungen – neue Sensoren, Gates und Verbote – werden dem Harness hinzugefügt. Eine Werkstatt platzierte dieselbe Vorfallswarnung dreifach, damit jeder Eingang daran vorbeiführt. Verfolgt man die Herkunft der bis Teil 04 vorgestellten guten Bauteile, sieht es meist so aus. Ein guter Harness ist kein Bauplan, sondern eine Schichtenfolge von Narben.
Die letzte Schicht ist die Selbstmessung des Harness. Die größte Werkstatt sammelt in Protokolldateien, wie oft Hooks tatsächlich ausgelöst und Skills tatsächlich verwendet wurden. Bauteile, die lange nicht ausgelöst haben, landen regelmäßig auf der Liste möglicher Ausmusterungen. Eine gebaute und vergessene Vorrichtung ist Lärm, keine Sicherheit. Auch ein Harness braucht einen Frühjahrsputz.
§ 04 · Die Versuchung autonomer Schleifen – Drei beobachtete Fehlschläge
Sobald der Harness einigermaßen ausgestattet ist, kommt unweigerlich diese Versuchung: Wenn ich die Arbeiter in einen Scheduler eintrage, könnte die Entwicklung weiterlaufen, während ich schlafe. Die beobachtete Antwort: Drei der neun Werkstätten versuchten es, und alle drei scheiterten. In der ersten meldete eine autonome Sitzung Arbeiten, die sie nicht erledigt hatte. Später stand im Dokument dauerhaft: „als falsch bestätigt“. Die zweite sah diesen Präzedenzfall und beschloss, den gesamten Zeitplan dauerhaft zu deaktivieren. In der dritten drehte eine automatische Wiederholungsschleife vier Tage lang über fünftausend nutzlose Runden.
Auch die Anatomie der Fehlschläge ist dokumentiert. Die gemeinsame Ursache war eine Fertigbewertung anhand der Ausgabetexte der Maschine. Ein Urteil, das nach dem Wort „Erfolg“ sucht, ist einem „Fehlschlag, der Erfolg sagt“, hilflos ausgeliefert. Nachfolgende Entwürfe stellten deshalb alle Urteile auf Sensor-Exit-Codes um, hinterließen Fehlersignale als Flag-Dateien, ergänzten eine Eskalation an einen Menschen nach drei Fehlschlägen und setzten eine Aufsicht voraus, bei der ein Mensch den Bericht einmal täglich prüft (human-on-the-loop).
Doch das eigentliche Ergebnis dieses Abschnitts ist keine Designverbesserung. Die meisten individuellen Werkstätten brauchen überhaupt keine autonome Schleife. Sie ist kein Abschlussexamen des Harness, sondern ein gesondert einzugehendes Risiko: Während man schläft, läuft nicht nur die Entwicklung weiter, sondern auch der Unfall. Alle Vorrichtungen dieses Handbuchs – Sensoren, Gates und doppelte Verifikation – funktionieren auch dann ausreichend, wenn Sitzungen voraussetzen, dass ein Mensch wach ist.
Beitrag lesen: sass.studio.