Die Risiken der Black-Box-Programmierung mit KI

In der Qualitätssicherung (QA) und beim Testing ist es üblich, von Black-Box-Tests oder White-Box-Tests zu sprechen. Black-Box-Tests werden durchgeführt, wenn man die interne Funktionsweise des Systems nicht kennt und dessen Funktionalität überprüft. White-Box-Tests werden durchgeführt, wenn man die interne Funktionsweise oder Struktur des Systems kennt und die Tests so konfiguriert, dass die verschiedenen möglichen Fälle geprüft werden, die der Code abdeckt.

Mit den Werkzeugen der künstlichen Intelligenz entsteht das, was wir als Black-Box-Programmierung bezeichnen könnten. Der Benutzer spezifiziert der KI, was er funktionell von einer Anwendung erwartet, und die KI generiert es.
Der Benutzer weiß nicht, wie seine Anwendung intern funktioniert, es interessiert ihn nicht oder er ist nicht in der Lage, die Auswirkungen der Implementierung dieser Lösung zu verstehen.
Dies wäre ein typischer Anwendungsfall für Tools wie Lovable und einige andere, die gerade aufkommen. Aber auch die Akzeptanz von KI-generiertem Code ohne Überprüfung und Verständnis könnte als Black-Box-Programmierung betrachtet werden.

Im Gegensatz zur Black-Box-Programmierung gibt es auch die White-Box-Programmierung mit KI. In diesem Fall gibt es einen technischen Verantwortlichen, der über die Architektur und die Implementierung der Lösung entscheidet und die KI nutzt, um diese schneller umzusetzen. Je nach Kontext und Verständnisvermögen fallen die an die KI delegierten Fragmente größer oder kleiner aus.
Die Aufgabe des Produktentwicklers wandelt sich: Anstatt Codezeilen zu schreiben, entwirft/leitet, orchestriert und überprüft er und trägt die volle Verantwortung für das „Wie“. Daher empfehle ich, dass die von der KI angeforderten Fragmente so klein und präzise sind, dass man sie überprüfen, verstehen und deren spätere Wartung übernehmen kann (meine Empfehlung: nichts, was größer ist als ein Pull Request, den wir selbst prüfen und verstehen können). Obwohl vollständiges Wissen unerreichbar ist und es verschiedene Schattierungen von Weiß gibt, besteht die White-Box-Programmierung darin, die Lösung so vollständig wie möglich zu verstehen; es geht nicht darum, eine große Black Box in eine Vielzahl kleinerer Black Boxes aufzuteilen.

Obwohl ich offensichtlich meine eigene Präferenz habe, ist keine der beiden Methoden per se gut oder schlecht. Man muss sie einfach verstehen, ihre Vor- und Nachteile sehen und vor allem ihre Risiken begreifen.

Im Fall der Black-Box-Programmierung sollten meines Erachtens folgende Risiken abgewogen werden:

Risiko 1: Mangelnde Verantwortung. Wie ich bereits in einem vorherigen Artikel erwähnt habe, darf KI nicht zu einer Verwässerung der Verantwortung führen. Wenn die generierte Software nicht richtig funktioniert, Leistungs-, Sicherheits- oder Stabilitätsprobleme oder unvorhersehbare Nebenwirkungen aufweist, muss der Verantwortliche klar benannt sein. Weder das Wie noch das Warum dieser Probleme zu verstehen, macht die Übernahme von Verantwortung komplizierter.
Risiko 2: Kontrollverlust über die Qualität. Wenn wir nicht wissen, wie die Software generiert wurde, wissen wir auch nicht, ob ein Qualitätsprodukt erstellt wurde oder nicht. Das ist nichts Neues; die meisten Stakeholder wollen einfach, dass die Software funktioniert, unabhängig von der Qualität ihrer Erstellung. Aber diejenigen, die mit Softwarearchitektur arbeiten und sich damit auskennen, wissen, dass sich mangelnde Qualität und technische Schulden am Ende rächen: Erschwerte Wartung, Fehler, Langsamkeit, Komplexität und letztendlich die Notwendigkeit, die gesamte Software neu zu erstellen.
Risiko 3: Unkenntnis der Softwarearchitektur: Die Architektur der Software nicht zu kennen bedeutet, ihre Stärken und Schwächen nicht zu kennen und nicht zu wissen, welcher Teil verstärkt werden muss oder wie sie sich überhaupt weiterentwickeln kann oder sollte. Es bedeutet auch, ihre Abhängigkeiten und potenziellen Schwachstellen nicht zu kennen.
Risiko 4: Leistung: Die Leistung einer Anwendung hängt eng mit ihrer Architektur zusammen. Wir können über Skalierungsprobleme oder „einfach“ über eine ineffiziente Ressourcennutzung sprechen. Aber ohne zu verstehen, wie eine Anwendung aufgebaut ist, ist es unmöglich – nicht nur für uns, es umzusetzen, sondern selbst Optimierungen vorzuschlagen.
Risiko 5: Implizites Wissen: Wenn wir definieren und implementieren, gibt es einen Kontext und ein implizites Wissen aller beteiligten Akteure, das einen Mehrwert schafft. Ein Softwarearchitekt oder -entwickler bringt beispielsweise Wissen über Architektur, Entwurfsmuster, Datensicherheit und auch funktionale Fragen ein, die auf früheren Erfahrungen und Implementierungen basieren. Da dieses Wissen implizit ist, wird vieles davon weder an die KI übertragen noch von ihr gefordert, was zu einer qualitativ minderwertigeren Lösung führt, als wenn mehrere Akteure mit unterschiedlichem Wissen an der Erstellung beteiligt gewesen wären.
Risiko 6: Evolution vs. Revolution (Refactoring vs. Replatforming): Wir müssen bedenken, dass die Softwareentwicklung ein iterativer Prozess ist. Eine Anwendung wird nicht einfach einmal erstellt und das war's. Sie muss weiterentwickelt, repariert, verbessert werden usw. Da das „Wie“ der Erstellung unbekannt ist, kann die Weiterentwicklung bestimmter Aspekte nicht präzise spezifiziert werden. Stattdessen werden neue High-Level-Spezifikationen hinzugefügt. Dabei besteht ein sehr großes Risiko, dass die KI das Bestehende neu erstellt, um die neuen Spezifikationen zu erfüllen, wodurch frühere Anforderungen nicht mehr erfüllt werden, erneut Fehler entstehen und generell all die Probleme auftreten, die beim Neuerstellen von Software anstelle eines Refactorings entstehen.
Risiko 7: Verlust von Chancen durch Wissensmangel: Es gibt Fälle, in denen das Wissen darüber, wie etwas gemacht ist, und das Verständnis der technologischen Möglichkeiten neue Geschäftschancen, neue funktionale Optionen usw. eröffnen. Dies nennt man „Bottom-up“-Produktentwicklung. Wenn man dieses Wissen und die Akteure, die das „Wie“ kennen, übergeht, geht diese kreative Fähigkeit verloren.

In Kenntnis dieser Risiken muss man mit den Auswirkungen der Black-Box-Programmierung vorsichtig sein. Dennoch ist es, wie bereits erwähnt, nicht per se ein schlechter Ansatz. Es gibt Fälle, in denen diese Art der Programmierung interessant sein kann, da sie einen geringeren Verbrauch an menschlichen Ressourcen bedeutet (auf den Token-Verbrauch gehe ich hier nicht ein).

Beispielsweise bei Proofs of Concept, Piloten oder Prototypen kann dies sinnvoll sein, da in diesen Fällen Leistung und Produktivstabilität nicht so notwendig sind wie Geschwindigkeit und die Fähigkeit, Konzepte zu testen. Zudem besteht dabei nicht die Absicht, eine Software zu schaffen, die dauerhaft bleibt, verbessert und weiterentwickelt wird.

Zusammenfassend lässt sich sagen: Wenn wir mit KI programmieren – genau wie wenn wir Software bei einem Beratungsunternehmen in Auftrag geben –, müssen wir uns der Auswirkungen bewusst sein, wenn wir diesen Code nicht kennen, welche Risiken dies birgt und wie wir ihn warten wollen. Wir müssen uns fragen, ob wir die Software als Lösung für ein Problem in Auftrag geben oder ob wir sie selbst implementieren wollen.