Wer weiß noch, was die KI gebaut hat?

Es passiert leise. Ein Team arbeitet ein paar Wochen mit einem KI-Assistenten an einem Projekt, die Funktionen stehen, alles läuft. Einen Monat später kommt eine Fehlermeldung aus einer Ecke, an die sich niemand erinnert. Man öffnet die Stelle und liest Code, den man selbst nie gelesen hat. Er sieht sauber aus, er ist benannt wie der Rest, er funktioniert vermutlich. Nur weiß niemand mehr, welche Annahme darunter liegt und warum es so gebaut wurde und nicht anders.

Bei einem Projekt fällt das kaum auf. Bei vier parallel laufenden wird daraus ein Betriebsrisiko. Genau da stehen wir gerade: Es entsteht pro Woche mehr Code, als ein Mensch in derselben Woche gründlich lesen kann. Der Engpass ist von der Umsetzung zur Kontrolle gewandert.

Warum das Wissen verschwindet

Ein KI-Assistent, der eine Aufgabe löst, trifft dabei Dutzende kleiner Entscheidungen. Wo ein Wert zwischengespeichert wird, welcher Weg bei einem Fehler eingeschlagen wird, wie eine Sache benannt ist. Jede einzelne davon ist für sich plausibel. Zusammen ergeben sie eine Struktur, die niemand entworfen hat.

Nach der Sitzung ist die Begründung weg. Was bleibt, sind der Code und ein Satz in der Änderungshistorie. Beim nächsten Mal fängt die KI wieder bei null an und trifft dieselben Entscheidungen erneut, nur diesmal anders. So bekommt ein Projekt zwei Wege, dasselbe zu tun, und beide sind halb richtig.

Das lässt sich nur verhindern, indem man das Wissen aus der Sitzung ins Projekt zieht, bevor es verdampft. Bei uns landet es an drei Stellen: in einer Regeldatei, in Skills und in Tests.

Das Projektgedächtnis

Jedes unserer Projekte hat eine Datei, die der Assistent vor jeder Aufgabe automatisch mitliest. Darin steht nicht, was der Code tut, das steht im Code. Darin steht das, was man aus dem Code nicht ablesen kann: warum eine Entscheidung so gefallen ist, und welche Falle beim letzten Mal eine Stunde gekostet hat.

Typische Einträge klingen so:

• „Wenn du diese Datei änderst, wirkt die Änderung nicht sofort. Es fehlt ein Zwischenschritt. Das sieht aus wie ein Logikfehler, ist aber keiner."
• „Diese eine Kombination von Einstellungen bringt das Backend zum Absturz. Nimm stattdessen die Variante daneben."
• „Bestimmte Angaben werden bei falscher Schreibweise stillschweigend ignoriert. Es gibt keine Fehlermeldung, es passiert einfach nichts."

Jeder dieser Sätze ist einmal teuer bezahlt worden. Aufgeschrieben kostet er beim nächsten Mal nichts mehr. Der entscheidende Punkt: Die Datei wird automatisch geladen, niemand muss daran denken, sie zu öffnen.

Skills: Wissen, das sich selbst meldet

So eine Regeldatei wird irgendwann zu lang. Bei uns liegt die größte bei rund 560 Zeilen, und das ist ungefähr die Grenze des Sinnvollen. Alles darüber gehört in Skills.

Ein Skill ist ein abgegrenztes Paket Fachwissen mit einer Beschreibung obendrauf, wann es gebraucht wird. Es wird nur dann geladen, wenn die Aufgabe dazu passt. In einem unserer Projekte liegen fünf davon nebeneinander: eines für die Daten aus einem angebundenen Fremdsystem, eines für die Gestaltungskonventionen im Frontend, eines für die Werkzeuge eines KI-Chats, eines für den Chat selbst und eines für dessen Absicherung.

Der Unterschied zu klassischer Dokumentation steckt in der Beschreibung im Kopf. Sie richtet sich an das Werkzeug und sagt ihm, wann dieses Wissen relevant wird. Ein Handbuch, das niemand aufschlägt, wirkt nicht. Ein Skill schlägt sich selbst auf.

Am deutlichsten wird der Nutzen bei Wissen, das ohnehin niemand im Kopf hat. Für eine große öffentliche Fachseite liegt bei uns ein Skill im Projekt, der alle 71 Inhaltsbausteine dieser Website beschreibt: welcher Baustein wofür da ist, welche Felder er hat, wie eine Seite daraus zusammengesetzt wird. Ohne diese Übersicht rät ein Assistent beim Anlegen von Inhalten. Mit ihr trifft er.

Immer derselbe Weg

Der zweite Hebel sind Abläufe, die jedes Mal gleich laufen und die man nicht vergessen kann.

Der wichtigste Grundsatz dabei: Für jede wiederkehrende Aufgabe gibt es genau einen richtigen Weg, und der ist aufgeschrieben. Änderungen an der Datenbank werden nicht von Hand nachgebaut, sondern von einem Werkzeug erfasst, das den Unterschied automatisch aufzeichnet. Einmal aufgezeichnete Schritte werden nie nachträglich verändert. Wenn einer falsch war, kommt ein zweiter, der ihn korrigiert. Das klingt umständlich, bis man einmal ein Live-System hatte, dessen Stand nicht mehr zum Projekt passte.

Genauso beim Veröffentlichen. In einem Projekt geht die Testumgebung bei jeder Änderung automatisch live, das echte System nur auf Knopfdruck und ausschließlich über einen definierten, automatisierten Weg. Der Grund steht in der Regeldatei: Bei einer Veröffentlichung vom eigenen Rechner entscheidet die dort zufällig installierte Software mit darüber, was beim Kunden ankommt. In der automatisierten Umgebung ist das jedes Mal identisch.

Dazu kommt eine kurze Tabelle im Projekt, die eine ganze Klasse von Missverständnissen auflöst:

Vier Zeilen, die verhindern, dass jemand eine halbe Stunde nach einem Fehler sucht, den es gar nicht gibt.

Tests sind die einzige Kontrolle, die nicht müde wird

Wenn man den Code nicht mehr vollständig liest, muss etwas anderes prüfen, ob er stimmt. Wir testen dabei bewusst schmal, aber an den richtigen Stellen.

Geprüft wird die Rechenlogik: Wie werden Adressen zerlegt, wie werden Fremddaten auf unsere Struktur übertragen, wie werden Preise und Kontingente berechnet. In einem Projekt sind das rund 20 solcher Prüfsammlungen, sortiert nach Fachbereich. Bewusst nicht geprüft wird die Verzahnung mit dem Framework darunter. Der Aufwand dafür ist hoch, und am Ende beweisen solche Tests vor allem, dass die Testkulisse funktioniert.

Dazu kommen Prüfungen, die über den einzelnen Baustein hinausgehen. Auf einer öffentlichen Website läuft automatisch eine Barrierefreiheitsprüfung über alle Seiten, weil Barrierefreiheit dort gesetzliche Auflage ist. Ein Assistent, der eine Seitenkomponente umbaut, kann das nicht unbemerkt kaputtmachen.

Der interessanteste Fall sind Tests für die KI-Funktionen selbst. Für einen unserer Chats liegt eine Sammlung gegnerischer Testfälle im Projekt, in drei Gruppen: Versuche, dem Chat interne Anweisungen zu entlocken, Versuche, ihm über eingespielte Texte fremde Befehle unterzuschieben, und eine Kontrollgruppe harmloser Fragen, die sauber beantwortet werden müssen. Nach jeder Änderung an Anweisungen oder Modell läuft die Sammlung erneut. Ohne so etwas ist jede Änderung ein Blindflug, und man merkt den Rückschritt erst, wenn ein Nutzer ihn findet.

Aus Fehlern werden Regeln

Der Teil, der am meisten Zeit spart, sind Hinweise, die eine bekannte Falle beim nächsten Versuch direkt abfangen.

Solche Hinweise entstehen fast immer aus einem konkreten Ärgernis. Etwas ist schiefgegangen, jemand hat eine Stunde gebraucht, um die Ursache zu finden. Der Reflex danach sollte nicht sein, den Fehler zu beheben und weiterzumachen, sondern ihn zu beheben und die Regel aufzuschreiben. Am besten samt fertiger Lösung, damit beim nächsten Mal nicht wieder überlegt werden muss.

Wichtig sind dabei auch Zuständigkeitsregeln. Eine unserer Regeln lautet, dass allgemeine, in vielen Projekten eingesetzte Bausteine nichts über einzelne Kundenprojekte wissen dürfen. Wenn ein Projekt eine Sonderbehandlung braucht, wird sie im Projektteil ergänzt und nicht im allgemeinen Teil. Ohne diese Regel schreibt ein Assistent die Sonderlocke genau dorthin, wo sie am schnellsten wirkt, und man findet sie ein halbes Jahr später in einem völlig anderen Projekt wieder, wo sie nicht hingehört.

Zwei Minuten Aufwand pro Regel. Dafür wird derselbe Fehler nicht in jeder folgenden Sitzung neu erfunden.

Aus Regeln wird Code

Beim Aufbau unserer Bibliotheken für die kommende REDAXO-Generation sehen wir gerade den Endpunkt dieser Kette. Wissen, das man zuerst als Notiz aufschreibt und dann als Skill ordnet, wird irgendwann zu Code. Aus „so baut man hier eine Komponente" wird eine Vorlage mit festen Vorgaben. Aus „so meldet man einen Baustein an" wird ein Mechanismus, der das selbst erledigt.

Was in einer Bibliothek steckt, kann eine KI nicht falsch erfinden. Sie kann es höchstens falsch benutzen, und dafür gibt es Prüfungen. Jede Konvention, die in Code gegossen ist, ist eine Konvention weniger, die man in jedem Projekt neu erklären und durchsetzen muss.

Der Überblick ist Arbeit, die man einplanen muss

Der Aufwand für das Schreiben von Code ist stark gefallen. Der Aufwand für Verstehen, Prüfen und Betreiben ist gleich geblieben. Wer nur den ersten Teil beschleunigt, verschiebt die Kosten nach hinten, in die Wartung und in Fehler, die niemand kommen sieht.

Unsere Antwort darauf ist unspektakulär. Eine gepflegte Regeldatei pro Projekt. Skills für alles, was zu speziell für diese Datei ist. Abläufe mit genau einem richtigen Weg. Tests auf der Logik und auf den KI-Funktionen. Und nach jedem teuren Fehler eine neue Regel im Projekt. Das kostet vielleicht eine Stunde pro Woche und Projekt.

Der Gewinn zeigt sich in dem Moment, in dem man nach vier Wochen wieder in eine Datei schaut und sofort weiß, warum sie so aussieht.