GenAI Software Entwicklung: Warum das (noch) ordentlich Schwächen hat

Was kann KI gut programmieren?

Die besten Ergebnisse erzielt man seit den ersten KI gestützten Code-Completions bei “Vervielfältigungsarbeiten”, resp. dort, wo die KI an konkreten Beispielen innerhalb des Codes abschauen kann und es von der Code-Struktur her schon eine Teillösung gibt. Das hat sich auch mit Coding Agents nicht geändert. Des weiteren ist die KI stark in der Kenntnis von öffentlichen Dokumentationen mit Beispielen, was insbesondere bei Scripting-Arbeiten (z.B. für Datenmigrationen oder Infrastruktur) sehr hilfreich ist. Auch komplexe Dependency-Upgrades, wo die KI auf Migrationsanleitungen und ausführlichen (für uns oft eher schwer lesbaren) Compiler-Fehlermeldungen zurückgreifen kann, haben schon gut geklappt.

Wo sind die Schwächen der KI Softwareentwicklung?

Ganz klar beim Umsetzten von grösseren Arbeiten (Stories) und dem Strukturieren des Codes. Die Empfehlung, den Agenten mit möglichst kleinen und gezielten Anweisungen zu füttern ist nicht neu. Hier muss man sich klar überlegen, ob man einen zeitlichen und qualitativen Gewinn erzielen wird und wieviel Zeit man in das ständige Optimieren der KI (Instruction Files) investieren will. Zum Beispiel ein Projekt-Setup würde ich nie komplett generieren lassen – Code Agents sind Meister im skalieren und wer schlecht startet, wird die Kurve nicht mehr kriegen.

Woran hapert es grundsätzlich?

Dass Code Agents gute Instruction-Files brauchen ist Voraussetzung. Das Problem ist das Large Language Model (LLM) selbst und die Art und Weise, wie dieses trainiert wird. Die grundlegende, dem Menschen überlegene Fähigkeit der KI ist Lesen und logisches Interpretieren von Unmengen an Wissen. Den Gebrauch dieses Wissen basiert aber auf Wahrscheinlichkeit und nicht Selbstreflexion oder Erfahrung, weshalb die Modelle immer noch viel manuelle Optimierung benötigen.

Bezogen auf Softwareentwicklung braucht es wenig Vorstellungskraft um zu konstatieren, dass es wohl deutlich mehr “Bad Code” gibt als hervorragenden. Dazu kommt eine riesige Fülle an “Best Practices” aus einem völlig gesättigten Consulting-Markt, vieles oft zweifelhaft und nur mit Erfahrung angewendet ein Mehrwert. Oder kurz: mit “schlank und einfach” füllt man weder Bücher, Blogs noch Konferenzen.

Unterschiede in Front- und Backend Entwicklung

Backend Entwicklung

Aus meiner Erfahrung als Senior Fullstack-Entwickler sind die Code Agents in der Backend Entwicklung (z.B. Java) deutlich besser. Der Vorteil hier ist, dass man seit Jahrzehnten von Entities, Services, Controller etc. spricht und viele Projekte vor allem Create-Read-Update-Delete (CRUD) beinhalten. Es gibt zwar eine Vielzahl von Architekturen und Patterns dafür, aber vieles zielt auf Entkopplung und Modularität ab – also zusätzlicher Code für bessere Wartbarkeit und Weiterentwicklung, sprich: wenig Logik, aber viel Fleissarbeit und damit ideal für die KI.

Frontend Entwicklung

In der Frontend Entwicklung ist die Situation leider ernüchternder, deshalb aber nicht unlogisch. Bis vor 10 Jahren hat sich alles darauf konzentriert, dass der Software Entwickler “nichts mit dem Browser zu tun hat” (IE sei Dank), was sich in den früher populären Frameworks wie jQuery oder Angular widerspiegelt. Und obwohl man die Dynamik von Web Applikationen zunehmend vom Backend in den Browser verlegt hat, setzte man auch dort auf die Model-View-Controller (MVC) Architektur, welche man vom Backend einfach übernommen hat.

Seit 2015 hat sich in den Spezifikationen für Javascript, CSS etc. sehr vieles getan und damit Möglichkeiten für neue Frameworks (z.B. Vue.js oder Solid.js) und Architekturen (Komponenten-basiert mit reaktiven Daten) geschaffen. Ich gehe davon aus, dass hier die Trainingsdaten der LLM zu schwach sind, da mich gerade in diesen Bereichen der generierte Code überhaupt nicht überzeugt. Beispielsweise was die Strukturierung des HTML-Codes (Layouts) betrifft, führen unterschiedliche Entscheidungen (Child-Components, Slots usw.) zu unterschiedlich grosser Komplexität, aber genau diese Komplexität kümmert eine KI natürlich nicht. Ebenso steigt die Lesbarkeit von Layout-Code mit der optimalen Abstraktion zu dem, was man im Browser sieht, was eine optische Beurteilung durch den Entwickler erfordert. Zu guter Letzt ist die aktuelle Entwicklung der Frameworks und UI-Bibliotheken immer noch sehr gross und der effiziente Einsatz bedingt aktuelle Kenntnis derselbigen.

Fazit

Wie so oft gilt auch hier: “use the right tool for the right job”. Wer Code Agents idealistisch anwendet oder sich diesen ganz entzieht wird sich irgendwann Ineffizienz eingestehen müssen. Ebenso gilt: “there is no free lunch”. Wer will, dass die KI Code generiert, der den eigenen Ansprüchen und Vorlieben gerecht wird, muss in entsprechende Instruktionen investieren.

Wichtig ist, sich von dem Gedanken zu lösen, dass “alle anderen” bereits komplette Wunder in Lichtgeschwindigkeit erschaffen und sich von “Wegwerf-Applikationen” nicht blenden zu lassen, auch wenn diese auf den ersten Blick mittlerweile sehr ansprechend wirken. Gleichzeitig wäre es fatal zu glauben, dass man von Hand immer noch alles am schnellsten und besten programmiert.

Chance: Kognitive Entlastung für Entwickler

Wer als Entwickler aktuell Mühe hat, Code Agents als Teil seiner künftigen Arbeit zu sehen, dem möchte ich die Chance auf kognitive Entlastung schmackhaft machen. Selbst für “Fleissarbeit” braucht es entsprechende Konzentration, für Fehlersuche und Refactorings sowieso. Hier können wir Hilfe jeder Art gebrauchen, um uns zu entlasten und Energie für wichtigeres zu haben.

Risiko: Was nichts kostet ist nichts wert

Software Entwickler sind sich der Broken-Windows-Theorie bewusst – wird irgendein Teil des Codes nicht mehr sauber gepflegt, wird das Projekt über kurz oder lang “verfallen”.

Ähnlich könnte es sich verhalten mit “was nichts kostet, ist nichts wert”. Wenn ich als Entwickler erkenne, dass ein Projekt nur noch generierten Code ohne entsprechende Kuratierung beinhaltet ist die Frage, ob ich die intrinsische Motivation zur entsprechenden Pflege des Projekts noch aufbringe? Mit Code Agents kann ich auch im längsten Spaghetti-Algorithmus eine Änderung durchführen und wenn der Unit-Test erfolgreich ist - warum noch ein Refactoring durchführen?

Gleiches gilt für Code Reviews: für den Arbeitskollegen macht man dies ja gerne, man lernt selbst dazu und tauscht sich beim Kaffee aus. Aber Code einer KI überprüfen und ihr helfen, besser zu werden? Erinnert irgendwie an Tamagotchis…