KI-gestützte Dokumentationsprüfung bezeichnet den Einsatz von Sprachmodellen als simulierte Nutzer-Personas, die eine Dokumentation nicht nur bewerten, sondern aktiv damit arbeiten. Eine Persona wie ein Junior-Entwickler versucht, anhand der Dokumentation eine Aufgabe umzusetzen. Scheitert sie daran, zeigt das konkrete Lücken im Dokument.
Das Wichtigste in Kürze
- KI-Agenten mit simulierten Personas prüfen Dokumentation praktisch: Ein als Junior-Entwickler konfigurierter Agent verbrauchte 1,8 Millionen Token beim Scheitern, der Senior-Entwickler-Agent löste dieselbe Aufgabe mit 300.000 Token.
- Persona-Simulationen über LLMs kippen ins generische Modellverhalten zurück, sobald die Rollenbeschreibung nicht strikt genug formuliert ist, was sie vom Prototypen-Stadium trennt.
- Der Temperaturparameter eines LLMs steuert, wie stark die Ausgabe vom wahrscheinlichsten Pfad abweicht: niedrig für reproduzierbare, deterministische Ergebnisse, hoch für unerwartete Testergebnisse.
- Domainwissen und Architekturentscheidungen, die nicht dokumentiert sind, kann kein LLM rekonstruieren, weil sie schlicht nicht im Code stecken.
- Semantische Anker wie MECE erhöhen die Wahrscheinlichkeit strukturierter, überlappungsfreier KI-Ausgaben messbar, garantieren sie aber nicht.
KI-Personas als Prüfinstrument für Dokumentation
Eine KI-gestützte Dokumentationsprüfung funktioniert, indem ein Sprachmodell eine konkrete Persönlichkeit erhält und damit versucht, die Aufgaben aus der Dokumentation tatsächlich umzusetzen. Statt eine Anleitung nur zu bewerten, soll der Agent sie nutzen. Ingo Eichhorst nennt einen solchen Agenten zum Beispiel einen Junior-Entwickler: frisch im Job, ohne Lust, alles zu lesen, der die Dokumentation überfliegt und herumprobiert.
Der Prüfgedanke dahinter ist simpel. Wenn jemand mit wenig Hintergrundwissen die Software schnell zum Laufen bringen will, muss die Dokumentation das hergeben. Schafft der simulierte Junior-Entwickler es nicht, liegt ein echtes Problem in der Anleitung vor, nicht beim Anwender.
Den Ansatz baute Ingo bereits vor zweieinhalb Jahren mit einem Payment-Anbieter aus Saudi-Arabien und Dubai. Damals wurden über Sprachmodelle Menschen simuliert, um zu prüfen, wie gut diese die Dokumentation finden und ob sie damit implementieren können. Aus dieser Idee entstand ein Prototyp, der dieselbe Logik in eine bestehende Pipeline einsetzt.
Wie der Prüfagent in die Pipeline passt
Die Persona-Prüfung ist ein Rückwärtsweg: Es ist schon etwas da, und die KI bewertet, wie gut es ist. Ingo unterscheidet zwei Wege, wie KI bei Code und Dokumentation hilft. Der Vorwärtsweg erzeugt etwas, der Rückwärtsweg überprüft das Vorhandene.
Viele Teams betreiben bereits CI/CD-Pipelines für ihre Dokumentation. Die Doku läuft durch Quality Gates, wird getestet und muss bestimmte Bedingungen erfüllen. Der Persona-Agent ist ein zusätzlicher Baustein in genau dieser Kette. Er gibt am Ende eine Art Feedbackbogen aus, der zeigt, an welchen Stellen nachgebessert werden müsste, bevor die Dokumentation akzeptiert wird.
Während die Prüfung schon KI-gestützt läuft, bleibt das Erstellen der Dokumentation bei diesem Ansatz noch weitgehend manuell. Der Prototyp muss erst reifen, bevor er produktionsfähig ist.
Personas decken Lücken auf, die echte Testgruppen verfehlen
Verschiedene Personas finden unterschiedliche Schwächen, weil sie unterschiedlich an die Aufgabe herangehen. Neben dem Junior-Entwickler gibt es einen Senior-Entwickler. Ingo hat sogar seine Mutter als Persona simuliert.
Der Reiz liegt darin, Gruppen abzubilden, die in normalen Tests fehlen. Ein Usability-Test an der Uni liefert vor allem Studenten als Probanden. Die wissen, was KI ist, und wissen, wo sie klicken müssen, damit ein Ergebnis herauskommt. Solche Ergebnisse sind verzerrt. Mit simulierten Personas lassen sich auch Ausreißer und ungewohnte Denkhaltungen abdecken.
Das gilt besonders bei der Frage, ob ein Produkt in ein anderes Land überführt werden soll. Welche Denkhaltungen herrschen dort, wie unterscheidet sich die Kultur? Diese Szenarien lassen sich vorab simulieren, statt sie erst nach dem Launch zu entdecken.
Bei der Simulation gibt es eine technische Hürde. Das Modell fällt leicht in seine Trainingsdaten zurück. Ingos simulierte Mutter konnte irgendwann doch PHP schreiben, weil das Modell in seinen ursprünglichen Modus zurückkippte. Eine Persona muss deshalb sehr starr und genau vorgeschrieben werden.
Warum ein simulierter Junior-Entwickler an einer URL scheitert
Der Junior-Entwickler scheiterte an einem Detail, das ein Mensch kaum bemerkt hätte. Die Aufgabe lautete, anhand der Dokumentation des Ionos Model Hub das günstigste KI-Modell zu finden, es nach der Antwort auf eine Frage aus “Per Anhalter durch die Galaxis” zu fragen und zu prüfen, ob “Adams” in der Antwort steht. Ein Pass bedeutet, die Dokumentation war gut genug.
Der Junior-Agent rief eine Seite auf und bekam einen 404-Fehler. Die URLs bei OpenAI folgen einem bestimmten Schema, die Ionos-URL ist anders aufgebaut. An dieser Stelle fehlte eine klarere Anleitung. Der Agent probierte immer wieder, lag immer wieder falsch und verbrauchte dabei massiv Ressourcen.
Der Unterschied wird im Tokenverbrauch sichtbar:
| Persona | Tokenverbrauch | Verhalten |
|---|---|---|
| Senior-Entwickler | rund 300.000 Token | sauber implementiert, fertig |
| Junior-Entwickler | rund 1,8 Millionen Token | Trial and Error, RTFM ausgeschaltet |
Solche Fehler sind aufschlussreich, weil moderne Modelle einen Browser bedienen können. Im Hintergrund läuft ein Prozess mit, in dem das Modell mit sich selbst spricht. Diesen Denkprozess kann man analysieren und so erkennen, wo ein Gedankengang komplett falsch abbiegt.
Ein Agent beschwerte sich einmal, er könne das JavaScript nicht lesen, weil er die falsche Seite heruntergeladen hatte. Diese Seite ist nur für Maschinen relevant. Ein Mensch hätte das Problem nie gehabt. Sobald aber eine KI eine VM hochfährt statt eines Menschen, wird zu viel JavaScript in der Dokumentation auf einmal zum echten Problem.
Beim Generieren von Dokumentation gibt es keine 100-Prozent-Garantie
Wer mit Sprachmodellen Dokumentation erzeugt, muss sich vom Gedanken des sicheren Outputs verabschieden. Ein Taschenrechner liefert auf 1 plus 1 immer 2, sonst ist er kaputt. Ein LLM antwortet anders. Bei GPT-3.5 kommt auf 1 plus 1 mit rund 55,7 Prozent Wahrscheinlichkeit die 2 heraus.
Diese Streuung ist gewollt. Der Temperaturparameter steuert, wie stark ein Modell vom wahrscheinlichsten Token abweicht. Hoch gesetzt klingt das Modell menschlicher und produziert eher unerwartete Ausgaben, was sich für einen verrückten Tester eignet. Niedrig gesetzt klingt es robotermäßiger und liefert auf dieselbe Anfrage immer dasselbe.
Auch bei niedriger Temperatur kann eine kleine Änderung im Input zu einem ganz anderen Ergebnis führen. Deshalb braucht der Vorwärtsweg Grenzen von außen. Beim Coding ist das eine Regeldatei, vergleichbar mit einer Entwicklerdokumentation, in der steht, wie entwickelt wird. Sie garantiert nichts, sie erhöht nur die Wahrscheinlichkeit, dass sich das Modell daran hält.
Semantische Anker erhöhen die Wahrscheinlichkeit guter Ergebnisse
Semantische Anker sind Begriffe mit starker Anziehungskraft im neuronalen Netz, an denen sich die Ausgabe ausrichtet. Ingo nutzt häufig MECE: Mutually Exclusive, Collectively Exhaustive. Die einzelnen Teile überschneiden sich nicht und sind zusammen vollständig.
Soll die KI Testfälle für ein System auflisten, liefert die Anweisung “mach eine Liste, die MECE ist” eine Liste, die nach Qualitätsattributen oder klaren Funktionen abgrenzt, ohne Überschneidung und ohne Lücken. Solche Anker verschieben das Ergebnis von brauchbar in vielleicht 20 Prozent der Fälle auf brauchbar in 80 Prozent der Fälle.
Domänwissen steckt nicht im Code, und KI nimmt es dir nicht ab
Das eigentliche Wissen, warum eine Software existiert, lässt sich nicht aus dem Code zurückgewinnen. Man kann Code zu Pseudocode abstrahieren und daraus die Funktion ableiten. Das Domänwissen und die Business-Anforderungen stehen dort aber nicht.
Bei gutem Code finden sich in Kommentaren gelegentlich Begründungen, warum etwas so gelöst wurde. Diese Überlappung der Abstraktionsebenen ist hilfreich, aber ein LLM hat sie nicht, auch nicht im generierten Code.
Wenn man keine Architectural Decision Records führt und sich nicht aufzeichnet, warum man eine Entscheidung getroffen hat, dann mutmaßt man später. Man kann das LLM zwar fragen, was der wahrscheinlichste Grund war. Aber das ist Glaskugellesen, nur eine bessere Glaskugel.
Ingo Eichhorst
Wer Entscheidungen nicht dokumentiert, hat sie in zwei Jahren verloren. Diese Aufgabe nimmt dir keine KI ab.
Eine Zwischenebene übersetzt zwischen Technik und Management
Ein KI-generierter Report kann eine gemeinsame Diskussionsbasis zwischen Entwicklern und Management schaffen. In einem Startup fasst ein Agent zusammen, was alle Entwickler, menschliche wie KI-gestützte, am Vortag gemacht haben. Grundlage sind das Git-Diff und die zugehörigen Tickets, verdichtet zu einem einminütigen Report.
Die Persönlichkeit hinter dem Agenten ist als leicht überqualifizierter Software-Engineer angelegt, mit der Nase ein wenig oben. Genau dieser Bruch erzeugt Wirkung. Der Report ist im Business-Text formuliert, technische Fachbegriffe sind erklärt. Ein wenig technikaffiner CEO kann damit nachvollziehen, was passiert ist.
Die Zwischenebene zwingt beide Seiten, sich aufeinander zuzubewegen. Entwickler wissen, was sie gebaut haben, und können die Bewertung des Agenten auf ihre Arbeit beziehen. Das Management versteht den Text ohne Übersetzung. Vorher fehlte die gemeinsame Sprache.
Der Effekt hat auch eine kritische Seite. Als der Agent eine Entscheidung als suboptimal bewertete und der CEO nachfragte, mussten die Entwickler eingestehen, dass die Entscheidung tatsächlich schlecht war. Solche Momente sind nützlich, weil aus Fehlern am meisten gelernt wird.
