Schon sehr lange war ich für verschriftliche Dokumentation, konnte allerdings nur begrenzt damit überzeugen. Nun wollen auch Leute ohne technischen Hintergrund Informationen für KI erreichbar machen und sind plötzlich für das Dokumentieren von Dingen. Eine faszinierende Wendung.
Wenn ich Software schreibe, achte ich auf möglichst selbsterklärende Bezeichnungen. So kann man die Software direkt verstehen, ohne sie erst mit Kommentaren entschlüsseln zu müssen. Nicht-triviale Algorithmen beschreibe ich als Fließtext außerhalb vom Code. Mit dieser Mischung komme ich insgesamt gut klar.
Viele Entwickler:innen dokumentieren ihren Code fast gar nicht. Sie wüssten ja schließlich, was der tut! Und wenn jemand anderes das nicht weiß, kann die Person ja einfach fragen! Man würde so viel Zeit damit sparen, keine Dokumentation zu schreiben.
Und nun hat sich das Berufsbild von Softwareentwickler:innen komplett gedreht. Anstelle selbst Code zu schreiben, lasse ich nur noch die KI Code schreiben. Mein Job ist es, meinen Job zu automatisieren. Alles, was ich noch an Schritten händisch machen muss, versuche ich ebenfalls durch die KI zu erledigen lassen.
Einarbeitung neuer Mitarbeiter:innen
Dabei komme ich immer wieder an das Problem des Kontextes. Die Sprachmodelle sind zwar sehr fähig in vielen Programmiersprachen und können auch den vorhandenen Code lesen und interpretieren. Sie wissen allerdings nichts über den Kontext, in dem dieser Code entstanden ist, welches Problem er lösen muss und was die Strategie der Firma ist. Somit verhält sich die KI wie neue Mitarbeiter:innen, die zwar Wissen und Erfahrung mitbringen, in ihrer konkreten Rolle allerdings eingearbeitet werden müssen.
Die Einarbeitung neuer Kolleg:innen war früher so ein arkaner Prozess. Man hat ihnen ein Dokument mit allem gegeben, was sie einrichten müssen. In der Zwischenzeit haben sich allerdings diverse Systeme weiterentwickelt, sodass die neuen Leute nicht weiterkommen. Sie fragen jemanden, der ihnen dann einen Tipp gibt. Wenn es gut läuft, wird die Dokumentation angepasst.
Bei AI Coding muss man nun in jeder Sitzung die KI neu einarbeiten. Damit man nicht immer den gleichen Prompt schreiben muss, sollte man seine Systeme so dokumentieren, dass die KI sich schnell den Kontext erarbeiten kann.
Prozeduren, bei der Leute mal hier klicken mussten, dann dort was einfügen und nochmal da ein Kommando ausführen mussten, skalieren auch nicht so wirklich sinnvoll. Früher hat man immer die eine Kollegin oder Kollegen gefragt. Meist hat die andere Person das »schnell für einen gemacht«. Man hat weder gelernt, wie es geht, noch wurde die Prozedur verschriftlicht.
Damit aber die KI das kann, ist man plötzlich bereit das aufzuschreiben. Man ist sogar bereit es in einen KI »Skill« aufzubereiten, einer Markdown-Datei mit Instruktionen für die KI.
MCP anstelle von API
Ich würde viele Dienste zuerst als API entwickeln und dann eine Nutzeroberfläche gegen diese API bauen. Das hat den Vorteil, den Dienst auch programmatisch nutzen zu können. Da wurde aber häufig nicht der Vorteil gesehen, wer schreibt schon Software um Dinge zu automatisieren?
Mit KI braucht man aber plötzlich einen Weg, die Dienste nutzen zu lassen. Man bietet für seinen Dienst also ein Model Context Protocol (MCP) an, damit die KI das nutzen kann. Das ist eine API, aber eine die mit Englisch und nicht direkt HTTP-Requests funktioniert. Es ist wohl nur cool, weil es jetzt KI und neu ist.
Dokumentation hauptsächlich für KI
Ich sehe nun Initiativen, die Dokumentation viel stringenter zu pflegen als vorher. Das Argument ist, die KI würde so viel besser mit dem Code klarkommen. Dass seit Jahrzehnten Menschen mit Code besser klarkommen, wenn es Dokumentation gibt, war nicht überzeugend.
Es kann auch nicht daran liegen, dass man Arbeit an die KI delegieren kann, schließlich konnte man das auch schon vorher mit Menschen machen.
Der große Unterschied zwischen Menschen und der aktuellen KI ist der fehlende Lernprozess. Menschen tun etwas und merken sich das. Die KI ist aktuell wie eine Person, die jeden Morgen alle konkreten Erfahrungen davor vergessen hat. Generische Fähigkeiten bleiben, aber die Erinnerungen an die Arbeit in dieser Firma sind alle weg. Wie in Filmen, bei denen die Protagonisten keine neuen Erinnerungen formen können und sich überall Klebezettel mit Hinweisen hinterlassen, wird nun alles für die KI verschriftlicht.
Wir erreichen nun den Zustand, den ich an sich schon vorher gerne als Mensch gehabt hätte. Aber durch diesen Kontext-Reset von KI ist der Unterschied von aktueller und fehlender Dokumentation für alle sichtbar genug um auch zu handeln.
Claude Skills
Bei Claude gibt es noch das Konzept der Skills. Man kann Claude Dinge beibringen, indem man einen Skill anlegt. Auch hat Claude schon einen eingebauten Skill, der beim Erstellen von neuen Skills hilft.
Aber was ist so ein Skill konkret? Es ist eine Markdown-Datei, in der steht, welche Schritte man machen muss und was am Ende rauskommt. Es hat kein festes Format, es ist einfach nur natürliche Sprache. Und damit ist das ganze letztlich einfach nur ein How-To-Artikel, wie man schon immer in Dokumentation geschrieben hat.
In einer Dokumentation auch How-Tos zu schreiben, ergibt ja total Sinn. So können Leute einfach den Anweisungen folgen und ihr Ziel erreichen. Aber Dokumentation schreiben wurde ja als langweilig und unproduktiv abgestempelt.
Die wahrscheinlich gleichen Leute haben jetzt allerdings eine Sammlung an »Skills«, die sie untereinander austauschen, damit jeweils »ihr« Claude davon profitieren kann. Die Austauschstelle heißt »Skills Marketplace«. Ich hätte es ja einfach als How-To-Sammlung einer Dokumentation bezeichnet, der neue Name hilft wohl ein etabliertes Konzept »cool« wirken zu lassen.
Fazit
Als Pflanzenfett mit Stärke und gelbem Farbstoff noch »Analogkäse« hieß, fanden die Leute das doof. Unter dem Namen »veganer Käse« kann man die gleiche Idee nun zu einem höheren Preis verkaufen und die Zielgruppe fühlt sich ganz inspiriert, nachhaltig und öko.
Und jetzt haben How-To-Artikel einen neuen Namen und plötzlich ist Dokumentation schreiben ein ganz cooler Bestandteil der Arbeit von Entwickler:innen.