Ein Prompt ist ein Change Request

Zuerst die ehrliche Fassung

Ich möchte zuerst die ehrliche Fassung sagen, denn die einfache Fassung dieses Textes wäre falsch. Die einfache Fassung wäre: Das Werkzeug hat Fehler gemacht und ich habe sie gefunden. So war es nicht. Jede Änderung, um die ich gebeten hatte, wurde ausgeführt, korrekt, beim ersten Mal, auch einige heikle. Falsch war die Beschreibung der Arbeit, und sie war zweimal an einem Nachmittag falsch, auf eine Weise, die mir nicht aufgefallen wäre, wenn ich nicht in die Dateien gesehen hätte.

Ein Prompt ist ein Change Request

Irgendwann im letzten Jahr habe ich aufgehört, Prompts so zu schreiben, wie es in Threads beschrieben wird. Ich frage nicht höflich und ich gebe keine Beispiele. Ich schreibe im Grunde einen Change Request. Ich sage, welche Datei angefasst werden darf. Ich sage, welche Abschnitte sich nicht bewegen dürfen. Ich sage, dass kein Paket hinzugefügt und keine Farbe eingeführt werden darf. Und am Ende verlange ich einen schriftlichen Bericht: jede berührte Datei, jeder geänderte Text wörtlich vorher und nachher, und alles, was nicht auf der Liste stand, mit Begründung.

Dieser letzte Teil ist keine Höflichkeit. Er ist der Unterschied zwischen einem Werkzeug, mit dem man etwas Echtes bauen kann, und einem, mit dem man nur spielen kann. Wer nicht unterscheiden kann zwischen „es hat nicht getan, worum ich gebeten habe“ und „es hat getan, worum ich gebeten habe, und elf weitere Dinge“, zahlt für die elf weiteren Dinge, zahlt noch einmal, um sie rückgängig zu machen, und erfährt nie, welche der drei Runden das eingebracht hat, was jetzt kaputt ist.

Die Prompts haben also funktioniert. Vier davon liefen an diesem Tag, und jeder einzelne kam ohne ungefragte Änderungen zurück. Keine neuen Dateien, keine Versionssprünge, keine abdriftenden Farben, nichts außerhalb des Auftrags berührt. Ich war zufrieden mit mir.

Der erste Bericht, der nicht stimmte

Dann bat ich darum, zwei Abschnitte auf einer Seite zusammenzuführen, und der Bericht kam zurück mit der Aussage, vier der sechs Punkte, um die ich gebeten hatte, seien „bereits aus der früheren Änderung vorhanden“, geprüft, nicht erneut angewendet.

Ich hatte einen Export von sechsunddreißig Minuten zuvor. Ich habe ihn geöffnet. Das Zitat stand weiterhin in halbfetter Kursiver. Das Symbol, das ersetzt werden sollte, war noch das alte, und der Name des neuen kam in der Datei überhaupt nicht vor. Der Abschnitt, der auf der zweiten Seite gelöscht werden sollte, war noch da, alle siebzig Zeilen. Ebenso das Hintergrundfoto, das entfernt werden sollte.

Keiner der vier Punkte war vorhanden. Alle vier wurden in dieser Runde erledigt, korrekt, und dann als Arbeit beschrieben, die früher geschehen und nur noch bestätigt worden sei.

Der zweite, den ich fast durchgehen ließ

Der zweite war leiser. Derselbe Bericht sagte, es sei nichts zusätzlich hinzugefügt, gelöscht oder umgestellt worden, und keine andere Datei sei berührt worden. Aber zwischen den beiden Exporten war aus einer dritten Datei ein Absatz verschwunden.

Hier kommt der Teil, der das schreibenswert macht statt nur beschwerenswert. Diese Löschung war meine. Ich hatte den Absatz von Hand entfernt, weil derselbe Satz an zwei anderen Stellen der Website ohnehin stand und ein dritter direkt unter dem Anmeldeformular zu viel war. Das Werkzeug konnte das nicht wissen. Es hatte keine Möglichkeit, das zu wissen.

Aber es sagte nicht, dass es das nicht wisse. Es sagte, die Datei sei unverändert. Es machte eine Aussage über den Zustand von etwas, das es nicht geprüft hatte, im selben selbstsicheren Ton wie alles andere im Bericht, und hätte ich dem Bericht vertraut, hätte ich eine Datei für unberührt gehalten, die es nicht war.

Warum das passiert

Ich halte beides weder für Nachlässigkeit noch für Lüge, und deshalb wähle ich die Worte sorgfältig. Die Zusammenfassung einer Änderung wird von demselben Vorgang erzeugt, der die Änderung gemacht hat. Sie ist eine Beschreibung dessen, was dieser Vorgang zu tun glaubt. Sie hat keinen unabhängigen Zugang dazu, was auf der Festplatte nun tatsächlich wahr ist. Es selbst prüfen zu lassen heißt, einen Zeugen zu bitten, seine eigene Aussage zu bestätigen.

Damit ist die Zusammenfassung eine Behauptung, und etwas anderes muss der Beweis sein.

Was als Beweis zählt

Für mich ist der Beweis ein Artefakt, das außerhalb dessen existiert, was es erzeugt hat. Der Export. Der Diff zwischen diesem Export und dem letzten. Das Build-Ergebnis. Das Gate, das die gebauten Dateien liest und die Veröffentlichung verweigert, wenn eine verbotene Zeichenfolge darin steht. Keines davon hat eine Meinung darüber, was passiert ist. Sie sind, was passiert ist.

Und die Artefakte fanden weiter Dinge, die in keinem Bericht standen, weil kein Bericht sie hätte finden können. Neun Symbole auf der Startseite hatten Farben im Quelltext stehen, Blau und Violett und Indigo und den Rest, und die Klassennamen wurden zur Laufzeit aus Textstücken zusammengesetzt. Das Stylesheet entsteht, indem der Quelltext nach vollständigen Klassennamen durchsucht wird, und ein Name, der erst beim Ausführen entsteht, wird nie gesehen und nie erzeugt. Diese neun Symbole waren grau, seit sie geschrieben worden waren. Die Farben existierten nur im Code und hatten nie einen Besucher erreicht.

Der Footer existierte achtmal, einmal in jeder Seitendatei, und die Kopien waren auseinandergedriftet, sodass die Tagline je nach Seite zwei verschiedene Dinge sagte. Das Logo bestand zu drei Fünfteln aus leerer Fläche, weshalb die Kopfzeile hundertsechzig Pixel reservierte, um ein Zeichen von etwa sechzig Pixeln Höhe zu zeigen. Kleinigkeiten, jede davon die korrekte Antwort auf eine Bitte, die jemand einmal geäußert hat.

Nichts davon stand in irgendeinem Bericht. Es waren keine Fehler, die jemand in einer einzelnen Runde gemacht hat. Sie haben sich angesammelt, still, über ein Jahr kleiner Anfragen, von denen jede korrekt beantwortet wurde.

Es gilt für meine eigenen Werkzeuge, und für mich

Ich möchte deutlich sagen, dass dies kein Argument über das Produkt einer bestimmten Firma ist. Ich arbeite täglich mit einem Assistenten, und auch er schreibt Zusammenfassungen seiner eigenen Arbeit, und ich lese sie auf dieselbe Weise. Gestern sagte er mir, ein Build sei durchgelaufen, und wenige Minuten später, dass er committet hatte, bevor der Build tatsächlich gelaufen war. Er hat sich selbst korrigiert, was ich geschätzt habe, und die Korrektur ist nicht der Punkt. Der Punkt ist, dass ich es erfahren habe, weil ich nachgesehen habe, nicht weil man es mir gesagt hat.

Es gilt auch für mich. Meine eigene Darstellung dessen, was ich letzten Dienstag geändert habe, ist eine Behauptung. Die Git-Historie ist der Beweis. Ich habe mich oft genug über meine eigene Arbeit geirrt, um zu wissen, welchem von beidem zu trauen ist.

Die Regel

Die Regel, die ich jedem mitgeben würde, der mit diesen Werkzeugen etwas Echtes baut, handelt also nicht davon, wie man Dinge formuliert. Sie lautet: Formuliere die Anfrage so, dass Einhaltung überprüfbar ist. Verlange den Bericht, denn ein Werkzeug, das Rechenschaft ablegen muss, verhält sich besser als eines, das das nicht muss. Und prüfe den Bericht dann gegen etwas, das keine Meinung haben kann, jedes Mal, besonders dann, wenn der Bericht sagt, es sei alles in Ordnung.

Das ist kein Misstrauen. Es ist derselbe Grund, aus dem eine Bank ihre eigenen Bücher abstimmt.