Wenn das Modell sich sicher ist: Bibliotheksversionen, die es nie gab

Ein Agent hat mir einmal erklärt, eine Bibliothek sei inzwischen in einer neueren Hauptversion verfügbar, und diese löse genau mein Problem. Die Beschreibung war schlüssig, die vorgeschlagene Nutzung passte zum Rest des Codes. Die Version existierte nicht. Auf Nachfrage kam keine Korrektur, sondern eine Bekräftigung.

Das ist der Fehlertyp, der mich bei fremden Bibliotheken beschäftigt. Nicht der Code, der nicht kompiliert, sondern der, der falsch ist und dabei souverän klingt.

Warum das anders liegt als eigener Code

Im eigenen Projekt hat ein Agent die Wahrheit vor sich. Er kann die Datei öffnen, in der die Funktion steht, und sehen, welche Parameter sie nimmt. Ein Irrtum darüber fällt beim Übersetzen auf.

Bei einer fremden Bibliothek fehlt diese Rückkopplung. Was das Modell über sie weiß, stammt aus dem Zeitpunkt, an dem sein Training endete, und aus allem, was seither über sie geschrieben wurde, ohne Datum und ohne Rangfolge. Eine Methode, die vor zwei Jahren üblich war und inzwischen entfernt wurde, ist in dieser Sicht genauso präsent wie ihr Nachfolger.

Beide sind belegt, nur eben nicht gleichzeitig.

Dazu kommt, dass die Fehler in dieser Klasse spät auffallen. Ein falscher Methodenname bricht sofort. Ein Aufruf mit der richtigen Signatur, aber der Semantik der Vorgängerversion, läuft durch, liefert etwas Plausibles und wird erst auffällig, wenn jemand das Ergebnis nachrechnet.

Am unangenehmsten sind stillschweigende Annahmen: dass eine Bibliothek Zeitzonen mitschleppt, dass ein Aufruf idempotent ist, dass ein Standardwert der ist, der er vor drei Versionen war. Solche Annahmen stehen nirgends. Sie fallen auf, wenn eine Zahl nicht stimmt.

Was ich daraus gemacht habe

Die Konsequenz ist nicht, Antworten zu misstrauen und jede einzeln nachzuschlagen. Sie besteht aus zwei Festlegungen, die beide vor der Arbeit greifen.

Die Dokumentation kommt von außen, nicht aus dem Gedächtnis. Wenn eine fremde Bibliothek im Spiel ist, bekommt der Agent die aktuelle Dokumentation gereicht: entweder als Verweis, den ich selbst heraussuche, oder über einen Zugang, der die Dokumentation zur Laufzeit abruft. Der Unterschied ist nicht Bequemlichkeit. Erinnertes Wissen hat kein Datum, abgerufenes schon.

Versionen sind der Entscheidung des Agenten entzogen. Das steht als Regel in den Leitplanken des Projekts: Abhängigkeiten und ihre Versionen ändert er nicht. Braucht eine Aufgabe eine neuere Version, ist das ein Befund, den er meldet, keine Änderung, die er vornimmt.

Die zweite Regel ist die wichtigere, und zwar aus einem Grund, der erst auf den zweiten Blick sichtbar wird: Sie macht die erfundene Version wirkungslos. Ein Modell, das eine Version halluziniert, aber nichts an der Abhängigkeitsdatei ändern darf, produziert höchstens einen Vorschlag, über den jemand entscheidet. Ein Modell, das dieselbe Halluzination selbst einträgt, produziert einen Fehler beim Installieren, im besten Fall, oder ein Paket mit ähnlichem Namen, im schlechteren.

Damit verschiebt sich die Prüfung an eine Stelle, an der sie billig ist. Statt Aufrufe gegen mein eigenes Gedächtnis zu lesen, beantworte ich eine einzige Frage: Woher stammt diese Angabe. Steht sie in der Dokumentation, die vorlag, oder ist sie zwischen den Zeilen entstanden.

Der Unterschied zum Prüfen von Absicht

Beim Thema überflüssiger Abstraktionen habe ich geschrieben, dass Werkzeuge nicht helfen und ich selbst hinschauen muss. Hier ist es umgekehrt, und das ist der Grund, warum beides getrennt gehört.

Ob eine Abstraktion angemessen ist, kann kein Werkzeug beantworten, weil die Antwort vom Vorhaben abhängt. Ob eine Methode existiert, kann jedes Werkzeug beantworten, das die Dokumentation liest. Wo eine externe Instanz recht behalten kann, ist mein Urteil das schwächere Werkzeug, nicht das stärkere. Das gilt auch für mich, nicht nur für das Modell: Auch ich erinnere mich an APIs, wie sie vor zwei Jahren waren.

Wofür ich das bezahle

Den ersten Preis zahlt die Versionsregel. Ein Agent, der Abhängigkeiten nicht anfassen darf, hebt auch keine an, wenn es richtig wäre. Aktualisierungen sammeln sich und werden von Hand gemacht. Ich habe falsche Änderungen gegen aufgeschobene getauscht, und aufgeschobene Aktualisierungen sind eine Schuld, die still wächst.

Der zweite Preis liegt im Ablauf. Dokumentation bereitzustellen heißt, vorher zu wissen, welche Bibliothek gebraucht wird, oder mitten in der Aufgabe anzuhalten und sie zu holen. Das ist kein großer Zeitposten, aber es unterbricht, und Unterbrechungen fühlen sich teurer an, als sie in Stunden sind.

Wo das Problem klein bleibt

Bei etablierten Bibliotheken, deren Schnittstelle sich seit Jahren kaum bewegt, trifft das Modell fast immer richtig. Dort ist reichlich beschrieben, was gilt, und was gilt, hat sich nicht geändert. Der ganze Aufwand richtet sich gegen einen anderen Fall: junge Projekte, schnelle Veröffentlichungszyklen, Bibliotheken, die ihre Schnittstelle zwischen zwei Hauptversionen umgebaut haben.

Genauso ist die Rechnung eine andere, wenn eine falsche Annahme sofort bricht. Wo der Übersetzer den Fehler findet, braucht es keine vorgelagerte Prüfung. Interessant wird es dort, wo eine veraltete Annahme durchläuft und sich als Zahl im Ergebnis versteckt.

Erinnert oder nachgeschlagen

Die nützlichste Frage bei fremden Bibliotheken lautet nicht, ob der Code richtig aussieht. Sie lautet: Woher stammen seine Angaben. Erinnertes Wissen und nachgeschlagenes Wissen sehen im Ergebnis identisch aus, und nur eines von beiden hat ein Datum.

Alles, was ich hier gebaut habe, dient dieser einen Unterscheidung. Nicht weil das Modell unzuverlässig wäre, sondern weil seine Zuverlässigkeit von außen nicht ablesbar ist.