The AI Build Trap
An sich klingt es erst einmal wie etwas Positives: mit Hilfe der immer besseren und intuitiveren KI-Tools ist es heute so einfach wie nie, Software zu erstellen. Sei es als Programmier-Unterstützung, wie im Fall des Github Copilot, oder als ein Programm, dass einem den Grossteil der Arbeit abnimmt, wie Lovable - es gibt eine ganze Reihe von Möglichkeiten, die eigene Produktivität in bisher ungeahnte Höhen zu schrauben. Und doch steckt auch ein Risiko dahinter.
Vereinfacht gesagt: wenn es auf einmal so einfach ist, neue Programme und Features zu erstellen, wird das auch mit grösserer Bereitwilligkeit getan werden als bisher. Statt aufgrund der begrenzten Kapazität der IT-Abteilungen nur die wirklich wichtigsten Anforderungen umzusetzen, kann jetzt jeder Kundenwunsch, jede einzelne Stakeholder-Anforderung und jede Entwickler-Idee in Produktion gebracht werden. Und das ist bei weitem nicht so positiv, wie es klingen mag.
Die offensichtlichste Folge eines derartigen bereitwilligen Umsetzens aller Wünsche ist die Entstehung von Bloatware, also von Anwendungen, die derartig mit Funktionen überladen sind (von denen viele nur eine sehr kleine oder ggf. sogar lediglich eine hypothetische Anwendergruppe haben) dass sie unübersichtlich werden, schlecht zu bedienen sind, hohe Ladezeiten haben und viel Speicherplatz einnehmen. Mit anderen Worten - es wird ein aus Kundensicht schlechtes Produkt.
Und auch unterhalb der Benutzeroberfläche führt das massenhafte Erzeugen von Funktionalitäten (und damit von Code) zu Problemen. Auch hier ist die Unübersichtlichkeit ein zentrales Problem. Je grösser die Codebase wird, desto schwieriger wird es zu sagen, an welcher Stelle was passiert. Die Überprüfung der KI-Ergebnisse durch einen Menschen (deren Verzicht einem Kontrollverlust gleichkäme) wird immer schwieriger und irgendwann sogar unmöglich.
Diese Phänomene erinnern nicht ohne Grund an die Build Trap (sinngemäss die Produktivitäts-Falle), die 2019 von Melissa Perri in ihrem gleich benannten Buch beschrieben wurde. Auch ihr selbst ist diese Parallele aufgefallen, und sie hat sie in mehreren Social Media-Posts thematisiert. Von ihr stammt auch die Erweiterung des ursprünglichen Begriffs zu dem der AI Build Trap, der damit als zusätzliche und spezifische Ausprägung dieses Antipatterns beschrieben ist.
Um auch hier zu einem konstruktiven Ausblick zu kommen: in die AI-Produktivitäts-Falle zu geraten, ist zum Glück kein Naturgesetz, man kann (und sollte) es auf verschiedene Weisen verhindern. Zum einen, indem man durch kleine, schnell veröffentlichte Incremente überprüft, ob es für die neuen Funktionen überhaupt Bedarf oder Akzeptanz gibt, zum anderen indem intern regelmässig sichergestellt wird, dass der Code von Menschen verstanden wird und ggf. verändert werden kann.
Das kann sich natürlich wie eine Entschleunigung der gerade erst gewonnenen Programmier-Höchsgeschwindigkeit anfühlen - und es ist auch eine. Trotzdem ist es sinnvoll, sich darauf einzulassen, wenn man nicht riskieren will, sich in der Build Trap wiederzufinden, und Produkte gebaut zu haben, die vom Kunden nicht gewollt und von den eigenen Entwicklern nicht verstanden werden.
