Dieses Handbuch ist ein Zweig der Lubjanka-Methode. Die Methode wird zu einem eigenständigen Entwicklungsansatz ausgebaut, der neben Harnesses, Agenten und Skills auch Projektgerüste und die Zusammenstellung von Bibliotheken umfassen soll. Dieses Handbuch nimmt daraus zunächst die Ebene heraus, die die Maschine bindet. Es entstand nach der vollständigen Bestandsaufnahme von neun Werkstätten—Projekten—einer einzelnen Person. Es richtet sich an Menschen, die KI bisher nur über Chats beauftragt haben, und an alle, die sich schon einmal an „Alles fertig“ verbrannt haben.
§ 00 · Was passiert, wenn man nur per Chat beauftragt
Die Szene ist vertraut. Du schreibst in den Chat: „Korrigiere die Position dieses Buttons.“ Kurz darauf antwortet die Maschine: „Die Änderung ist abgeschlossen.“ Du öffnest die Ansicht. Der Button sitzt unverändert da. Auf Nachfrage entschuldigt sich die Maschine, meldet wieder „Fertig“, und wieder bleibt der Button, wo er war. Anweisungen werden ignoriert, Berichte werden zu Lügen, der Abend verschwindet.
Die Wurzel dieser Wiederholung liegt in der Struktur, nicht im Charakter der Maschine. Anweisungen im Chat verdampfen, sobald das Gespräch endet. Die Maschine der nächsten Session kennt die Versprechen von gestern nicht. Auch „Prüfe unbedingt, bevor du fertig meldest“ ist nur eine einmalige Zusage für dieses Gespräch. Weil die Zusage nicht weitergetragen wird, wiederholen sich die Verstöße. Und weil keine Vorrichtung die Prüfung erzwingt, erklärt die Maschine ihre Arbeit ungeprüft für fertig.
Die Lösung hat eine Richtung. Schreibe Anweisungen in Dateien statt in Chats. Mache aus Prüfbitten Skripte. Entscheide anhand eines numerischen Ausführungsergebnisses—des Exit-Codes—statt anhand der Worte der Maschine, ob die Prüfung bestanden ist. Diese drei Dinge dauerhaft im Repository zu verankern: Das ist das gesamte Harness Engineering, das dieses Handbuch behandelt.
Es gibt einen Beleg dafür, dass dies eine Schlussfolgerung der Branche ist und nicht die Ordnungssucht eines Hobbyisten. In einem Coding-Benchmark veränderte ein Team das Modell überhaupt nicht, sondern nur die umgebenden Vorrichtungen. Der Wert stieg von 52,8 auf 66,5, der Rang von Platz 30 auf Platz 5. Dasselbe Gehirn, ein anderes Geschirr. Den Erfolg bestimmte der Harness, nicht das Modell.
§ 01 · Neun Werkstätten
Verglichen wurden Dateiaufbau und Ausführung der Harnesses in ungefähr neun Werkstätten einer Person: einem Zahlungsdienst aus drei Repositories, einem Haushaltsbuch, einem Matching-Dienst, einem Spiel, einer Bildwerkstatt, einem Onlineshop, einigen internen Betriebswerkzeugen und dieser Website.
Die Größen unterscheiden sich extrem. Die größte Werkstatt hat zehn Definitionen für Arbeiter—Agenten—, sechsundzwanzig Verfahrensdokumente—Skills—und einundachtzig Prüfskripte, darunter allein siebenundfünfzig Sensoren. Die kleinste hat genau einen Hook. Eine weitere hält „null Arbeiter“ ausdrücklich als Entscheidung fest, nicht als Versehen. Ein Harness wird nicht durch Größe besser, sondern dadurch, dass er zu den Risiken der Werkstatt passt.
Trotz verschiedener Größen wiederholen sich die Bauteile. Die Anweisung, vor einer Fertigmeldung den tatsächlichen Zustand zu messen, findet sich in fast jeder Werkstatt. Hook-Gruppen zum Erhalt des Session-Gedächtnisses wurden nahezu identisch kopiert. In Skriptköpfen steht, aus welcher Werkstatt sie stammen. Standardbauteile existieren bereits. Dieses Handbuch ist ihre Montageanleitung.
§ 02 · Wie du es liest
Lies der Reihe nach. Teil 01 ist ein Glossar: zunächst die Begriffe Harness, Agent und Skill. Teil 02 zeigt den Aufbau von Hand—fünf Dateien für einen minimalen Harness. Teil 03 lässt Claude dieselbe Arbeit ausführen. Teil 04 behandelt das Herzstück: Sensoren und Gates, die falsche Fertigmeldungen strukturell verhindern. Teil 05 behandelt die Modellzuweisung und die Frage, warum nicht jede Aufgabe das Spitzenmodell bekommen sollte.
Es gibt nur eine Voraussetzung. Du musst dich mit Code nicht gut auskennen. Wenn du einen Ordner erstellen und Text in eine Datei schreiben kannst, kannst du anfangen. Die meisten Harness-Bauteile sind tatsächlich Dokumente, kein Code: Dokumente mit Regeln, Rollen und Verfahren. Wo Code nötig ist, lässt du ihn nach der Methode aus Teil 03 von der Maschine schreiben.
Ein Satz vor dem Beginn: Das Ziel dieses Handbuchs ist nicht, der Maschine zu vertrauen. Es ist, Arbeit ohne Vertrauen möglich zu machen. Vertrauen ist eine Tugend zwischen Menschen. Eine Maschine braucht Belege.
Beitrag lesen: sass.studio.