Ein Agent wird falsch liegen. Nicht oft, wenn der Bau ordentlich war, aber er wird es. Interessant sind die zwanzig Minuten danach. Jemand in der Abteilung sieht, dass eine vorformulierte Antwort im falschen Ton geschrieben ist, oder dass eine Rechnungsposition als Ausnahme abgelegt wurde, obwohl sie sauber durchgelaufen wäre. Diese Person hat zwei Möglichkeiten. Die Datei öffnen, in der die Regel steht, und sie ändern. Oder demjenigen schreiben, der das System verkauft hat, und warten. Nur eine der beiden lässt den Agenten eingeschaltet.
Eine Übergabe ist deshalb nicht die Feierstunde am Ende eines Builds. Sie ist der Teil, der entscheidet, ob der Build seinen ersten Fehler überlebt. Was darin steckt und warum jedes Stück darin steckt, steht hier.
Ein System, das Sie nicht ändern können, wird beim ersten Fehler abgeschaltet
Eine Automatisierung, die die Abteilung nicht selbst ändern kann, ist eine Abhängigkeit, und mit Abhängigkeiten, die sie blamieren, gehen Abteilungen hart um. Der Ablauf ist immer derselbe. Am Dienstag liegt eine Regel falsch. Die Person, der es auffällt, kann sie nicht reparieren, also umgeht sie den Agenten für diesen Fall, macht die Arbeit von Hand und sagt der Kollegin, sie solle es genauso machen. Zwei Wochen später bearbeitet der Agent noch ein Drittel dessen, wofür er gebaut wurde. Abgeschaltet hat ihn niemand. Er hat aufgehört, eine Rolle zu spielen.
Die Konsole eines Anbieters ist meistens der Anfang davon. Eine geschlossene Oberfläche mit einem Textfeld für Anweisungen sieht nach Kontrolle aus und ist keine. Sie sehen den aktuellen Prompt, Sie sehen seine Geschichte nicht, Sie können nicht feststellen, wie er während des schlechten Laufs im letzten Monat aussah, und Sie können nicht auf die Fassung zurück, die funktioniert hat. Zwei Leute können dort auch nicht parallel arbeiten, weil es nichts zu vergleichen und nichts zusammenzuführen gibt.
Meine Ansicht dazu ist deutlich. Genauigkeit ist die kleinere Hälfte von Vertrauen. Die größere Hälfte ist Korrekturgeschwindigkeit. Ein Agent, der in vierundneunzig von hundert Fällen richtig liegt und den Ihr Team an einem Nachmittag korrigiert, ist mehr wert als einer mit achtundneunzig, für dessen Anpassung Sie drei Wochen und eine Rechnung brauchen. Die Übergabe ist der Teil, mit dem Sie sich diesen Nachmittag kaufen.
Die Prompt-Bibliothek liegt in Ihrem Repository
Jede Anweisung, die einen Agenten steuert, liegt als einfache Textdatei im git-Repository des Kunden. Eine Datei pro Agent für die Regeln dieses Workflows, dazu eine gemeinsame Datei für die Regeln, die alle Agenten befolgen. In den Dateien stehen Kommentare, die sagen, wozu eine Regel da ist, denn eine Regel ohne Begründung löscht der Nächste, dem sie im Weg steht.
Änderungen gehen durch denselben Pull-Request-Ablauf wie der übrige Code. Das bringt vier Dinge, die sich lohnen. Einen Diff, an dem Sie genau sehen, welche Formulierung sich geändert hat. Eine zweite Person, die draufsieht, damit eine Regeländerung keine private Angelegenheit ist. Ein Zurücknehmen, das Minuten kostet. Und eine Versionsnummer im Laufprotokoll, damit Sie zu einem seltsamen Lauf sagen können, welche Fassung des Prompts ihn erzeugt hat.
Wir schreiben die Bibliothek so, dass die Änderungen, die Menschen wirklich vornehmen wollen, oben stehen. Der Ton einer Antwort, die Schwelle für eine Eskalation, die Formulierung einer Ablehnung, die Liste, an wen ein bestimmter Fall geht. Die Mechanik steht weiter unten. Wer zweihundert Zeilen lesen muss, um einen Satz Tonfall zu ändern, ändert ihn nicht.
Leitplanken im Code, und absichtlich schwerer zu ändern
Der zweite Teil ist die Umkehrung des ersten. Die Prompt-Bibliothek ist gebaut, damit Ihr Team sie ändert. Die Leitplanken sind gebaut, damit eine Änderung auffällt. Nie externe Post ohne menschliche Freigabe. Nie im Hauptbuch buchen. Nie einen Datensatz löschen. Diese Regeln liegen in eigenen Dateien, ihre Änderung braucht die Zustimmung von zwei Personen, und zu jeder gehört ein Test, der die verbotene Aktion anfordert und eine Ablehnung erwartet.
Sie bekommen die Liste außerdem in normalen Sätzen, die auch jemand ohne Technikhintergrund lesen kann, und hinter jedem Satz steht, an welcher Stelle im Code die Regel erzwungen wird und welcher Test sie prüft. Eine Leitplanke, von der nur wir wissen, ist für Ihre Revision nichts wert.
Zwei Workshops, beide aufgezeichnet
Der erste liegt vor dem Go-live. Er hat keine Folien. Am geteilten Bildschirm ändert jede Person einmal selbst eine Regel, öffnet den Pull Request, sieht sich den Lauf danach an und nimmt die Änderung wieder zurück. Wer das nicht mit eigenen Händen gemacht hat, wird es im Ernstfall nicht tun.
Der zweite liegt drei Wochen nach dem Go-live, weil das Team dann echte Fragen hat statt gedachter. Wir gehen durch die Fehlläufe aus dem Protokoll, nicht durch Beispiele, und ändern die Regeln, die sich als zu streng oder zu lasch herausgestellt haben.
Beide Termine werden aufgezeichnet, mit Zeitmarken und einem Inhaltsverzeichnis, und die Aufzeichnung liegt dort, wo auch das Repository liegt. Der Grund ist einfach. Die Person, die diese Erklärung im siebten Monat am dringendsten braucht, saß im Raum nicht dabei. Sie fängt im November an.
Eine namentlich benannte Person und ein wöchentlicher Termin
In der Übergabe steht ein Name, keine Sammeladresse und kein Ticketsystem als erste Stufe. Für neunzig Tage geht diese Person ans Telefon, und in unserem Fall ist es dieselbe Person, die die Map geschrieben und die Agenten gebaut hat.
Dazu ein Termin von dreißig Minuten pro Woche mit fester Tagesordnung. Der Durchsatz der Woche. Der Anteil der Fälle, die in der Warteschlange für Menschen gelandet sind, und ob er steigt oder fällt. Jede Aktion, die jemand zurückdrehen musste. Die Änderungen, die Ihr Team an der Bibliothek vorgenommen hat, und was sie bewirkt haben.
Der eigentliche Zweck dieses Termins ist, dass kleine Fehler gemeldet werden, solange sie klein sind. Ohne festen Termin meldet niemand eine Kleinigkeit, und Kleinigkeiten sammeln sich drei Monate lang an, bis jemand entscheidet, dass das Ding nicht funktioniert.
Woran Sie merken, dass die Übergabe stattgefunden hat
Es gibt einen Test dafür, und er ist unbequem. Sehen Sie am Ende der neunzig Tage in die Änderungshistorie der Prompt-Bibliothek. Stehen unter den letzten drei Wochen nur unsere Namen, hat die Übergabe nicht stattgefunden, ganz gleich wie viele Dokumente übergeben wurden und wie freundlich die Workshops waren. Stehen dort Namen aus Ihrer Abteilung, gehört das System Ihnen.
Zum Abschluss geben wir die Zugänge zurück. Jeder Schlüssel, den wir für den Bau bekommen haben, wird entzogen, und die Liste dieser Schlüssel steht als Aufgabenliste im Übergabedokument, damit Sie das abhaken und nicht glauben müssen. Ein Anbieter, der nach der Übergabe noch Zugänge hält, hat einen Grund dafür, und der Grund ist selten Ihrer.