Was schiefgegangen ist

Ich habe in Teil 2 geschrieben, dass ein Laborbuch, in dem nur Erfolge stehen, gefälscht ist. Hier ist die Gegenprobe.

Der Kollege, der eine Anwendung erfunden hat

Der schwerwiegendste Vorfall bisher, und gleichzeitig der lehrreichste.

Einer unserer Kollegen, zuständig für Architektur, sollte für ein Vorhaben ein Datenmodell entwerfen. Er hat geliefert: Tabellenstruktur, Beziehungen, Zugriffsregeln, ein Berechtigungskonzept, ein Protokollierungskonzept. Sauber begründet, fachlich stimmig, professionell formuliert. Er hat sich dabei auf einen Auftrag bezogen, den es gab, und auf eine Vorarbeit, auf die er aufbaute.

Nur: Diese Vorarbeit existierte nicht. Der Auftrag, auf den er sich berief, existierte nicht. Und die Anwendung, für die er das Datenmodell entwarf, existierte nicht — kein einziger Bestandteil davon war je gebaut worden.

Das Erschreckende daran ist nicht, dass es passiert ist. Das ist ein bekanntes Verhalten von Sprachmodellen. Das Erschreckende ist, wie gut es aussah. Es gab keinen Hinweis, keine Unsicherheit, keine Formulierung im Konjunktiv. Wer nicht nachprüft, ob die referenzierten Dinge existieren, merkt nichts.

Die Ursache haben wir gefunden, und sie war strukturell: Der Kollege konnte nichts schreiben. Er hatte keine Möglichkeit, ein Dokument abzulegen. „Dokumentieren" bedeutete für ihn deshalb: es im Chat ausformulieren. Und wenn Beschreiben und Tun dasselbe sind, dann gibt es keinen Unterschied mehr zwischen einer Sache, die existiert, und einer, die überzeugend beschrieben wurde.

Die Konsequenzen: Es gibt jetzt eine Ablage, in die Kollegen Ergebnisse tatsächlich legen können — und eine Nachweispflicht. Wer behauptet, etwas erstellt zu haben, muss darauf zeigen können. Aussagen über den Bestand („dieser Kollege macht X", „diese Aufgabe existiert") kommen nicht mehr aus dem Gedächtnis, sondern werden bei jedem Nachschlagen aus dem tatsächlichen Stand nachgeladen.

Der Fehler, der sich selbst gerechtfertigt hat

Der zweite Vorfall hängt am ersten und ist mir fast noch unangenehmer.

Als der Fehler aufgefallen war, hat derselbe Kollege ihn in sein Gedächtnis geschrieben — allerdings in einer Fassung, die sinngemäß lautete: Das war kein Fehler, sondern Struktur.

Er hatte sich also nicht gemerkt, was passiert war, sondern seine Rechtfertigung dafür. Und weil das Gedächtnis bei jedem Arbeitsschritt wieder eingelesen wird, hätte ihn dieser Eintrag beim nächsten Mal zuverlässig in denselben Fehler zurückgeführt — mit dem zusätzlichen Nachteil, dass er nun eine Begründung dafür parat gehabt hätte.

Wir haben den Eintrag korrigiert. Aber der eigentliche Punkt ist ein anderer: Ein Gedächtnis ist nur so viel wert wie seine Richtigkeit. Ein falscher Eintrag ist schlimmer als gar keiner, weil er Autorität hat.

Seitdem gibt es eine Regel für das Merken: prüfen, ob es schon dasteht, und Falsches korrigieren statt danebenschreiben. Beim ersten Aufräumen fanden sich in einem einzigen Gedächtnis vier Einträge, die nur aus einer Fehlermeldung bestanden, und derselbe Gedanke viermal in leicht unterschiedlicher Fassung. Jede dieser Zeilen wird bei jedem einzelnen Arbeitsschritt mitgeladen und kostet Geld.

Der Tag, an dem das Konto leer war

Den habe ich in Teil 10 schon beschrieben: eine Kaskade aus Rückfragen, jede einzeln sinnvoll, in Summe ein aufgebrauchtes Guthaben und kein verwertbares Ergebnis.

Was ich dort nicht geschrieben habe, ist der Auslöser. Eine Aufgabe war mit einer leeren Beschreibung angelegt worden — an der Stelle, wo der Inhalt stehen sollte, stand nichts. Der Empfänger konnte damit nichts anfangen, hat nachgefragt, dabei wieder Aufgaben erzeugt, und so weiter.

Ein leeres Feld. Ein fehlender Prüfschritt an genau einer Stelle. Das reicht.

Drei Fehler in der Übergabe, jeder für sich unsichtbar

Als die Kollegen anfingen, sich gegenseitig Aufgaben zu geben (Teil 5), steckten drei Fehler gleichzeitig darin. Ich finde sie deshalb erzählenswert, weil keiner davon eine Fehlermeldung erzeugt hat.

Erstens prüfte die Schnittstelle die Berechtigung des Empfängers statt die des Absenders. Ein Kollege durfte also nur jemandem etwas geben, dessen Zugang er selbst besaß — was niemand tat. Jede Übergabe wurde abgewiesen.

Zweitens wurde beim Anlegen einer Aufgabe der Absender als Zuständiger eingetragen, nicht der genannte Empfänger. Jede Aufgabe, die jemand für einen Kollegen anlegte, landete wieder bei ihm selbst.

Drittens ließ eine Übergabe den Status auf „fertig" stehen. Die Aufgabe wechselte korrekt den Besitzer — nur zog der Empfänger ausschließlich offene Aufgaben, also bekam er sie nie zu sehen.

Drei Fehler, drei völlig verschiedene Stellen, und alle drei mit demselben Ergebnis: Es sieht aus, als sei etwas übergeben worden, und es ist nichts passiert.

Was ich daraus mitnehme: Ich hatte jeden dieser Teile für sich getestet, und jeder für sich war in Ordnung. Was fehlte, war ein einziger Durchlauf von Anfang bis Ende: Einer legt an, ein Zweiter zieht, ein Dritter bekommt. Genau dieser Durchlauf hat alle drei Fehler innerhalb weniger Minuten sichtbar gemacht — und ist seitdem Pflicht, bevor irgendetwas als fertig gilt.

Der grüne Haken, der nichts bedeutete

Ein Fehler aus dem Betrieb, der nichts mit KI zu tun hat und deshalb vermutlich am breitesten anwendbar ist.

Nach einer Änderung an der Konfiguration haben wir geprüft, ob die Anwendung noch läuft. Sie lief: Die Startseite antwortete, der Login antwortete, alles grün.

Was wir nicht geprüft hatten: ob hinter diesen Seiten noch Daten ankamen. Taten sie nicht. Mehrere Bereiche waren schlicht leer — technisch einwandfrei ausgeliefert, inhaltlich ohne Inhalt. Von außen war das nicht zu unterscheiden von „hier ist eben noch nichts".

Was ich daraus mitnehme: Ein erfolgreicher Seitenaufruf sagt nichts darüber aus, ob die Seite ihre Daten hat. Seitdem gilt bei uns nach jeder Änderung an der Umgebung: sich tatsächlich anmelden und die zwei, drei Stellen anklicken, an denen echte Daten stehen müssen. Das dauert eine Minute und ersetzt eine ganze Klasse von Fehlalarmen — in beide Richtungen.

Die Sicherung, die keine war

Der jüngste Fehler, und der einzige, bei dem mir wirklich kurz mulmig wurde.

Vor einem Umbau an der Infrastruktur habe ich eine Sicherung der Datenbank geschrieben. Eigenes kleines Skript, alle Tabellen, alle Zeilen, ordentliche Datei, vernünftige Größe. Ich habe sie mir angesehen, sie sah gut aus, und ich habe mit dem Umbau angefangen.

Beim Einspielen wurden 751 von 854 Anweisungen abgewiesen.

Der Grund war eine Kleinigkeit: Mein Skript hat die Werte selbst in Anführungszeichen gesetzt. Bei normalem Text geht das gut. Bei Feldern, die selbst wieder strukturierte Daten enthalten, geht es schief — und zwar so, dass man es der Datei nicht ansieht. Sie ist lesbar, plausibel und vollständig. Sie ist nur nicht einspielbar.

Nichts ist passiert, weil ich den Umbau so angelegt hatte, dass der alte Stand bis zur erfolgreichen Prüfung unangetastet blieb. Aber der Punkt ist: Ich hätte es nicht gemerkt, wenn ich sie nicht gebraucht hätte. Die Datei hätte monatelang dagelegen, mit Datum und ordentlichem Namen, und wäre in dem Moment wertlos gewesen, in dem es darauf ankommt.

Und es kam noch ein zweiter Fehler dazu, der mir gefällt, weil er zeigt, wie tief das geht: Das Prüfwerkzeug, das ich danach geschrieben habe, hat die Sicherung zeilenweise gelesen. Nur gehen Einträge, die längere Texte enthalten, über mehrere Zeilen — das Werkzeug hat sie mitten im Satz zerschnitten und Fehler gemeldet, die keine waren. Ich hätte um ein Haar eine funktionierende Sicherung verworfen, weil meine Prüfung kaputt war.

Was ich daraus mitnehme, und es ist der älteste Satz der Branche, den ich trotzdem selbst lernen musste: Eine Sicherung, die nie eingespielt wurde, ist keine Sicherung, sondern eine Vermutung. Das Werkzeug lädt sie jetzt tatsächlich in die Datenbank, zählt jede Tabelle nach und rollt alles wieder zurück. Erst wenn das durchläuft, heißt die Datei Sicherung.

Was ich daraus insgesamt gelernt habe

Wenn ich die Vorfälle nebeneinanderlege, haben sie eine gemeinsame Form, und die hat mich überrascht.

Kein einziger davon war ein Fehler des Modells. Keiner ist entstanden, weil ein Sprachmodell zu schwach war. Sie sind alle an den Rändern entstanden: an einer fehlenden Schreibmöglichkeit, an einem fehlenden Pflichtfeld, an einer fehlenden Obergrenze, an einer vertauschten Berechtigungsprüfung, an einer fehlenden Prüfung vor dem Merken.

Und fast keiner davon hat sich wie ein Fehler angefühlt. Das ist der Teil, den ich unterschätzt hatte. In einem normalen Programm bricht etwas ab, wenn es falsch läuft. Hier lief alles weiter — die Protokolle waren vollständig, die Antworten gut formuliert, die Oberfläche grün. Ein System aus Sprachmodellen scheitert nicht laut. Es scheitert zuversichtlich.

Wer so etwas baut, braucht deshalb weniger Fehlerbehandlung und mehr Gegenproben: Ist beim Empfänger wirklich etwas angekommen? Existiert die Datei, von der hier die Rede ist? Steht in dem Feld, das ich nie geprüft habe, vielleicht nichts drin?

Das deckt sich unangenehm genau mit dem, was die MIT-Untersuchung als Grund dafür nennt, dass 95 Prozent der Projekte versanden (Teil 4): nicht die Fähigkeit, sondern die Einbettung.

Und es hat eine zweite Folge, über die ich mich noch nicht gefreut habe: Ein Agent, der nicht bauen kann, kann auch nicht liefern. Das hat zwei Kollegen ihre Rolle gekostet (Teil 11) und unsere Arbeitsweise verändert — die Kollegen konzipieren, spezifizieren und prüfen, gebaut wird unter menschlicher Aufsicht.

Ob das eine Zwischenlösung ist oder der Dauerzustand, weiß ich noch nicht. Ich halte es derzeit für ehrlicher, das offen zu lassen, als so zu tun, als hätte ich es geplant.