AI Native Software Development

Worum geht es?

Dass die Leistungsfähigkeit von Large Language Models (LLMs) / KI in den letzten Jahren signifikant zugenommen hat, hat mittlerweile jeder mitbekommen. Dass die Weiterentwicklung der LLMs immer schneller voranschreitet wurde genau so vorhergesagt und trotzdem ist es zumindest herausfordernd bei den aktuellen Entwicklungen noch Schritt zu halten und zu verstehen, welche Möglichkeiten bestehen und welche (noch) nicht. Aktuelle KI-Modelle sind besonders effektiv in der Generierung von „Content”, Programmcode ist „Content”. KI-Agenten werden immer mächtiger bei der Bearbeitung von Aufgaben, die über das reine Generieren von Content hinausgehen. Im SWE-Benchmark erreichen die ersten Modelle Quoten über 80 % und dürften damit auf einem Level liegen, das mit dem einer durchschnittlichen Person in der Softwareentwicklung vergleichbar ist. Das Programmieren, im Sinne der Eingabe von Buchstaben, Befehlen, Variablen, Funktionen etc. durch einen Menschen wird so nicht mehr lange existieren. Dies wird tiefgreifende Veränderungen nach sich ziehen und den gesamten Ablauf in der Softwareentwicklung verändern.

Um zu verstehen, was sich in Zukunft in Entwicklungsteams mit allen Jobrollen und Aufgaben um die eigentliche Programmierung der Software verändern wird, lohnt es einen Blick darauf zu werfen, wieso wir Software so entwickeln, wie wir es in den letzten Jahren getan haben.

Programmierung vs. Softwareentwicklung

Entwicklerinnen und Entwickler werden immer wieder von „Außenstehenden” mit der Vorstellung konfrontiert, dass Softwareentwicklung darin besteht, den ganzen Tag am PC zu sitzen und Programmcode zu tippen. Und gleichzeitig gibt es Statistiken darüber, dass pro Person nur wenige Zeilen Code pro Tag erstellt oder überarbeitet werden. Was macht man in der Softwareentwicklung dann den Rest des Tages?

Zur Entwicklung einer Software gehört natürlich viel mehr als nur das eigentliche „Produzieren” von Quellcode. Um ein Softwareprodukt zu erschaffen, das einen genügend großen Mehrwert für User bietet, muss verstanden werden, welche Arbeitsabläufe abgebildet werden sollen. Diese abstrakten Abläufe müssen in ein Softwareprodukt umgeplant werden, mit dem diese möglichst effizient und gut durchgeführt werden können. Dieses geplante Softwareprodukt muss dann in Programmcode abgebildet werden, wofür Architekturentscheidungen getroffen und Akzeptanzkriterien wie Performance oder Fehleranfälligkeiten bedacht und geprüft werden müssen. In geplanten Erweiterungen kann dieser Teil schon herausfordernd sein. Melden User Fehler / Bugs, müssen Entwicklerinnen und Entwickler häufig zur Behebung des Bugs herausfinden, wie die entsprechende Funktionalität ursprünglich gedacht war, ob wirklich ein Programmierfehler oder ein Planungsfehler vorliegt. Wenn dann Programmcode „produziert” wird, finden Code-Reviews statt, in denen die Qualität des erstellten Quellcodes von anderen Personen mit abgesichert wird. Statische Codeanalysen prüfen den Quellcode bezogen auf definierte Regeln und Kriterien. Das erstellte Produkt wird am Ende durch Softwaretester und automatisierte Tests geprüft. Feedback wird weitergegeben und ein Teil des Kreislaufs beginnt erneut. Diesen gesamten Prozess würde ich als „Softwarenentwicklung” bezeichnen. Das reine Eintippen von technisch geplanten Programmteilen dagegen als „Programmieren”.

Die Ursprünge der Softwareentwicklung waren sehr vom reinen Programmieren geprägt. Je mehr Software entstand, desto größer wurden Anforderungen im Bereich Usability, Performance, UX und umso größer wurde der Anteil an Softwareentwicklungsprozessen über das eigentliche Programmieren hinaus.

Software muss gewartet werden, Teams werden größer

Aufgrund der zunehmenden Komplexität und des wachsenden Umfangs von Softwareprodukten im Laufe der Jahre sind auch die Entwicklungs- und Programmierteams, die an einem einzigen Produkt arbeiten, immer größer geworden. Dies hat die Kommunikation zwischen den verschiedenen Beteiligten zu einem immer wichtigeren Faktor gemacht. Verschiedene Personen mussten rasch nachvollziehen, warum bestimmte Softwareteile auf eine gewisse Weise programmiert und entwickelt wurden oder wie spezifische Erweiterungen korrekt umgesetzt werden sollten. Der Bedarf an technischer Dokumentation wurde immer größer und da technische Dokumentation traditionell schneller veraltet ist, als man gucken kann, wuchs die Bedeutung von „Codequalität” immer weiter an.

Use the Source, Luke

Wenn bestehender Quellcode erweitert oder überarbeitet werden muss, der von anderen Personen erstellt wurde, wird im ersten Schritt nach technischer Dokumentation, Architekturdokumenten oder Ähnlichem gesucht. Dokumentation dieser Art ist immer veraltet oder gar nicht vorhanden. Im Zweifel wird in der täglichen Arbeit der Bugfix, das nächste Feature oder Refactoring immer höher priorisiert als die Anpassung der technischen Dokumentation – und Entwicklerinnen und Entwickler zweifeln sehr häufig. Steht man vor diesem Problem, gibt es in der Regel nur eine Lösung: Suche an der Quelle der Wahrheit, dem Quellcode. Im Quellcode steht eindeutig beschrieben, was das Programm macht, was es nicht macht oder nicht machen sollte. Um diese Informationen als Mensch schneller erfassen zu können, ist die Bedeutung der Codequalität immer größer geworden.

Man sollte eine Variable mit der gleichen Sorgfalt benennen, mit der man ein erstgeborenes Kind benennt. (Robert C. Martin)

Die Effizienz von Entwicklungsteams wurde über die letzten Jahre/Jahrzehnte fast vollständig mit der Codequalität in Zusammenhang gesetzt. Da die Codequalität zur effizienten Weiterentwicklung so eklatant wichtig war, wurde immer größerer Aufwand betrieben, um eben diese abzusichern. Regeln wurden definiert, Codequalitätsphilosophien entstanden, die Namen für Variablen und Funktionen wurden immer wichtiger – Programmcode sollte von Menschen gelesen werden können, wie ein Buch. Programmiersprachen selbst haben sich weiterentwickelt, führen neue Syntax- und Sprachelemente ein, um Programmcode immer besser strukturieren zu können. Statische Code-Analysen durch Programme oder Code-Reviews durch andere Menschen liefern Feedback an die Autoren in kurzen Zeitblöcken, um möglichst wenig „Code Smells” entstehen zu lassen, Code-Stellen also, die nicht den festgelegten Qualitätsansprüchen genügen. Je länger Stellen mit schlechter Codequalität in einem System vorhanden sind, desto mehr andere Stellen bauen darauf auf, gleichen sich an und desto schwerer wird es, effizient weiter zu programmieren – so weit die Theorie der letzten Jahre.

DevOps

Die letzte „große” Evolution der Softwareentwicklung war die DevOps-Bewegung. Die eher getrennten Lager „Softwareentwicklung” und „Systemadministration” sollten durch die DevOps-Philosophie vereinigt werden. Der Konflikt zwischen Menschen, deren Auftrag es ist, Softwaresysteme permanent und immer schneller zu verändern und zu erweitern und den Personen, deren Auftrag es ist, diese Systeme möglichst fehlerfrei zu betreiben, sollte gelöst oder zumindest verkleinert werden. Ständige Veränderung (Entwicklung) gegen Stabilität (Administration / Betrieb). Neben vielen anderen (sehr guten) Ansätzen in der DevOps-Philosophie nehmen Automatisierung, schnellere Feedbackschleifen zwischen Entwicklung und Betrieb eine große Bedeutung ein. Schnelle Feedbackschleifen erreicht man durch einen hohen Anteil an automatisierten Tests. Tests der DevOps-Philosophie gehen weit über reine Unit- oder auch Integrationstests hinaus. Hier werden Tests benötigt, die Infrastruktur-Konfiguration oder Sicherheitseinstellungen prüfen. Und diese Ansätze werden jetzt im Zeitalter der KI-nativen Softwareentwicklung nochmal an Bedeutung gewinnen.

Warum wir alles hinterfragen müssen

Wer glaubt, die Arbeit in der Softwareentwicklung beschränke sich auf das Eintippen von Programmcode, geht wohl davon aus, dass der reine Einsatz von KI zur „Produktion” des Quellcodes die Softwareentwicklung beschleunigt. Die anstehenden Veränderungen in Entwicklungsteams gehen aber weiter darüber hinaus, dass Programmcode generiert und nicht mehr menschlich eingetippt wird. Entwicklungsteams müssen sich davon lösen, ihre bekannten Arbeitsabläufe schrittweise durch den KI-Einsatz zu „verbessern”, die Arbeitsabläufe müssen hinterfragt werden. Code-Reviews durch eine KI ergeben keinen Sinn.

Jeder Dummkopf kann Code schreiben, den ein Computer verstehen kann. Gute Programmierer schreiben Code, den Menschen verstehen können. (Martin Fowler)

Das Zitat habe ich selbst viele Jahre gerne verwendet, um die Bedeutung von Codequalität zu unterstreichen – die aktuelle Frage ist aber: Müssen Menschen Programmcode noch lesen können?

Der gesamte Prozess der Softwareentwicklung basiert auf einer Welt, die es (bald|jetzt) nicht mehr gibt. Quellcode muss in Zukunft nicht mehr von Menschen gelesen und verstanden werden, um Softwareentwicklung zu betreiben. Diesen Arbeitsschritt werden LLMs/KI-Agenten übernehmen. Wenn diese Annahme zutrifft, brauchen wir keine Code-Reviews mehr. Lesbarkeit von Code ist unwichtig. Wie eine Variable oder Funktion benannt ist, hat quasi keine Auswirkung mehr auf die Erweiterbarkeit oder Veränderbarkeit von Code. Eine KI kann auch mit abstrakten, kryptischen Namen effizient arbeiten, wir Menschen nicht. Architekturentscheidungen sind deutlich unwichtiger, da sie viel einfacher wieder geändert werden können. Der Overhead, den wir betreiben, damit Anpassungen konsistent durchgeführt werden können, ist in der Form, die aktuell noch betrieben wird, nicht mehr sinnvoll.

Das gilt auch für APIs, die Softwaresysteme miteinander verbinden. API-Dokumentationen müssen nicht mehr von Menschen verstanden werden, APIs müssen von KI-Systemen verstanden und genutzt werden können. Quellcode muss nicht mehr von Menschen gelesen werden, damit er angepasst werden kann, die korrekten neuen Anforderungen reichen als Eingabe aus.

Wie behalten wir trotzdem die Kontrolle?

Was ist aber wichtig? Wir müssen die Kontrolle behalten. Darum ging es in all diesen Abläufen in der Vergangenheit. Wir müssen die Kontrolle über erschaffene Softwaresysteme erhalten, obwohl viele Menschen (mit KI-Agenten) sie gleichzeitig verändern. Die Veränderung wird jetzt aber viel schneller, wir brauchen keine reinen Programmierenden mehr, diesen Beruf gibt es nicht mehr. Softwareentwicklerinnen und -entwickler sind gefragt, die Kundenanforderungen gut verstehen und einem KI-System die richtigen Kriterien vorgeben können, die eingehalten werden müssen. Kriterien sind natürlich funktionale Anforderungen, aber wie schon in der DevOps-Bewegung angestoßen auch Vorgaben bezogen auf Sicherheit oder Performance. Alles weitere ist unwichtig. Wenn diese Kriterien in Form von automatisierten Tests vorhanden sind und generierte Software in kleinen Feedback-Loops auf diese Kriterien geprüft werden kann, entfällt der komplette Overhead, der über die Jahre aufgebaut wurde.

Das wird der eigentliche Effizienz- und Geschwindigkeitsvorteil sein. Und das wird das Berufsbild in der Softwareentwicklung stark verändern. Wir brauchen keine technischen Architekturplanungen mehr, wir brauchen keine Code-Reviews mehr, wir brauchen keine Regeln für Codequalität – wir brauchen möglichst vollständige Tests, die erstellte Programme gegen Kriterien prüfen, die eingehalten werden müssen.

Fazit

Was bedeutet das für die Menschen in der Softwareentwicklung? Der Bedarf an Personen die Kundenanforderungen verstehen, die Domänenwissen haben, die aber nach wie vor ein hohes technisches Verständnis haben und daher in der Lage sind, die Kundenanforderungen in Akzeptanzkriterien zu übersetzen und sie um all das zu ergänzen, was für das entsprechende Softwaresystem über die reine Funktionalität hinaus wichtig ist, wird weiter steigen.

Müssen wir davon ausgehen, dass sich die Welt der Softwareentwicklung ändern wird? Ja, absolut.
Müssen wir Angst haben, dass man in Zukunft keine Entwicklerinnen und Entwickler mehr braucht? Nein, absolut nicht. Die Anforderungen an diese und auch deren Aufgaben werden sich aber ändern.