Ersetzt KI die Softwareentwickler?

In meinem letzten Blogartikel habe ich geschrieben, was KI-Tools wie ChatGPT heute schon leisten können, wenn es darum geht, fachliche Anwendungen in ausführbaren Programmcode zu übersetzen.

Ich habe erfahren, dass die Ergebnisse zwar noch nicht zu 100 % korrekt sind, sondern immer noch überprüft und in vielen Fällen angepasst werden müssen. Aber trotzdem ist heute schon die Arbeitserleichterung so groß, dass ich nicht mehr auf den Einsatz solcher Hilfsmittel verzichten möchte. Ebenso wenig übrigens, wie ich auf meine leistungsstarke IDE verzichten möchte, die mir bei der Erstellung von Code auf andere Weise hilft.

Wir stehen erst ganz am Anfang dieser Entwicklung. ChatGPT und andere LLMs (LLM=large language model) befinden sich gerade in der Wachstums- und Ausprobierphase. Ich kann mir gut vorstellen, dass z. B. eine Firma wie JetBrains daran arbeitet, eine speziell auf Programmieren in Kotlin trainierte Lösung bereitzustellen, die fehlerfreien Code auf Basis normalsprachlicher Anweisungen erstellt. Google wird sicher dasselbe für Go tun, oder Microsoft für .NET und C#.

Werden wir also demnächst überflüssig? Braucht es bald gar keine Programmierer mehr, weil jeder Nutzer oder Product Owner selbst mithilfe dieser Systeme die gewünschten Anwendungen erstellen kann?

(Image generiert mit stable diffusion)

Die Suche nach dem „Citizen Developer“

Es hat immer wieder Ankündigungen gegeben, dass diese oder jene Technologie professionelle Entwickler überflüssig machen würde. Bei der ältesten dieser Ankündigungen, von der ich mal gelesen habe, ging es um COBOL: Mit dieser Programmiersprache, deren Syntax der normalen englischen Ausdrucksweise angelehnt ist, sollten Business-Menschen selbst ihre Programme und Datenabfragen schreiben können. Was meines Wissens aber nie passiert ist. In den Jahrzehnten danach wurden unter anderem zu Visual Basic, Microsoft Access, Power Builder, Blue Prism oder AWS Amplify, Google App Sheet oder anderen Low-Code-Plattformen vergleichbare Ankündigungen gemacht.

Fakt ist: Ich habe noch keinen „Citizen Developer“ in großem Stil gesehen. Ein gutes Beispiel hierfür ist MS Access, nach meiner Wahrnehmung das erfolgreichste Low-Code-Tool bisher. Natürlich wurden in vielen Abteilungen Access-Lösungen in sehr unterschiedlicher Größe von Nicht-Informatikern erstellt. Doch sobald diese Lösungen mehrere Jahre benutzt und weiterentwickelt werden, treten die normalen Probleme jeder Softwareentwicklung auf:

• Die Anwendung wird komplexer, die Wartung und Weiterentwicklung zunehmend schwerer.
• Sobald die wesentliche, Wissen tragende Person die Abteilung oder das Unternehmen verlässt, geht sehr viel Know-how verloren, das die übrigen Kolleginnen und Kollegen in der Regel nicht haben.
• Sobald die Datenmenge eine gewisse Größe überschritten hat, wird die Anwendung spontan langsamer.
• Auf neue Access-Versionen zu wechseln, ist häufig mit aufwändigen Umbaumaßnahmen verbunden.
• und so weiter …

In die Jahre gekommene, große Access-Lösungen wurden meistens entweder abgeschafft oder irgendwann in die Hände der IT-Abteilung des Unternehmens gegeben – und dort abgeschafft.

Ich glaube, dass es hilfreich und sinnvoll ist, derartige Low-Code-Systeme für Prototypen oder Experimente zu verwenden, oder um spontan und unaufwändig eine Ad-hoc-Lösung für ein akutes Problem zu erstellen. Aber geschäftskritische Anwendungen benötigen eine entsprechende Vorbereitung und professionelle Begleitung. Zumindest ist es so bis heute.

Übertragen auf KI-Tools zur Softwareentwicklung

Ich denke, dass wir bei KI-Tools zur Softwareentwicklung einen ähnlichen Fall haben. Im Moment sind die Systeme zwar noch nicht so weit, dass sie ganze Anwendungen erstellen können – aber das ist nur eine Frage der Zeit. Demnächst wird es so sein, dass man einem LLM sagen kann, was die Software können soll, und das System wird kompletten Code ausspucken, oder sogar die Lösung direkt in den Kubernetes-Cluster oder das Serverless-Cloud-Environment installieren. Keine Frage, das wird kommen, und auch früher, als manch einer glaubt oder hofft. Dass diese Systeme jetzt schon so gut sind, dass man ohne großes Vorwissen in zwei bis drei Stunden eine lauffähige Anwendung bauen kann, zeigt das sehr deutlich (siehe meinen letzten Blogartikel zu diesem Thema).

Ich persönlich erwarte allerdings eine ähnliche Entwicklung wie bei den bisherigen Ankündigungen zum Citizen Developer: Es werden schnell und unaufwändig Anwendungen gebaut. Aber sobald sie komplex werden, häufig geändert werden müssen oder einfach sehr lange leben, muss es jemanden geben, der oder die die Anwendung mit professionellen Kenntnissen betreut.

Von der Kunst, Anforderungen zu beschreiben

Jeder, der oder die schon einmal zu einer komplexen Fragestellung versucht hat, mit dem Fachbereich die wirklich exakten Anforderungen zu ergründen, weiß, dass es eine bestimmte Arbeitsweise und viel Erfahrung und Ausbildung braucht, um Edge-Cases und andere Feinheiten greifen zu können. Es dauert lange und erfordert viel Geschick, um eine Anforderung vollständig zu definieren.

Business-Analysten wird es also immer weiter geben (müssen). Doch auch mithilfe von guten Business-Analysten erleben wir häufig, dass erst beim Codieren – dem Übertragen der verbalen Beschreibung in eine unzweideutige, formale Schreibweise – Lücken in eben dieser Beschreibung sichtbar werden.

Normale Sprache ist in vielen Fällen zu mehrdeutig, schwammig oder – wenn man das Problem wirklich vollständig beschreiben möchte – zu langatmig, als dass es praktikabel wäre, komplexe und völlig neue Aufgabenstellungen ausschließlich damit zu beschreiben. Formalisierte Sprachen sind in der Regel besser geeignet, komplexe Sachverhalte auszudrücken. Die mathematische Formelsprache ist dafür ein gutes Beispiel.

Nur braucht man dafür eben auch eine Ausbildung. Und diese Ausbildung wird künftig Teil des Berufsbildes „Softwareentwickler“ sein, da bin ich sicher.

Ebenso ist es für Laien meist äußerst schwierig, vollständige Tests zu formulieren. Wenn aber die Software selbst in großen Teilen nicht mehr von einem Menschen mit dessen Verständnis erstellt wird, dann ist es nochmal so wichtig, das korrekte Funktionieren der Software sorgfältig zu testen.

Vielleicht übertragen wir als Software Developer demnächst Anforderungen nicht mehr in Programmcode, sondern in eine andere Formelsprache, die dann ausführbare Tests erzeugt. LLMs können dann „solange programmieren, bis alle Tests grün sind“.

In jedem Fall können wir uns als Entwicklerinnen und Entwickler mittelfristig nicht mehr darauf zurückziehen, „nur Code zu schreiben“. Ein großer Teil dieses Codes wird in Zukunft nicht mehr von einem Menschen geschrieben werden.

Fazit

Die Arbeitsweise eines Entwicklers, einer Entwicklerin wird sich ändern, das steht wohl fest. Aber das ist im Berufsbild „Software Developer“ immer schon Teil des Deals. Ich habe mal gelesen, dass die allerersten Programmierer schon die Erfindung eines Assemblers unnötig fanden, da man den Code ja auch direkt in Maschinensprache eingeben kann. Assembler waren ihnen damals viel zu „hochsprachig“ und zu wenig technisch. Das war vermutlich die erste Auseinandersetzung darüber, was einen „Real Programmer“ auszeichnet.

Vielleicht (be-)schreiben Developer in der Zukunft nur noch die Requirements und LLMs programmieren dann einen Großteil der Software. Viele Standardaufgaben werden demnächst sogar komplett von LLMs erstellt. Aber darauf freue ich mich, ehrlich gesagt. Ich habe wirklich keine Lust, die 100. Login-Maske mit immer gleicher Logik zu schreiben, oder die exakte Spezifikation von OAuth2 nachzulesen, wenn mir ein Tool das direkt richtig erzeugen kann.

Wird es dadurch weniger Developer geben? Ich glaube das nicht. In den 80er und 90er Jahren, vor den zig Million kostenlosen Frameworks der Open-Source-Bewegung, musste man jede Bibliotheksfunktion entweder teuer einkaufen oder – häufiger – selbst schreiben. Damals haben Entwickler und Entwicklerinnen stundenlang immer wieder ähnliche Datenstrukturen und Funktionen entwickelt, die heute selbstverständlich zur Grundausstattung einer jeden Programmiersprache gehören.

Haben wir heute weniger Entwickler als damals? Benötigen wir weniger Entwickler als damals? Eher im Gegenteil.

Ich bin gespannt.

Weitere Informationen

Wer tiefer in diese Thematik einsteigen möchte, dem empfehle ich die Blog-Serie meines Kollegen Uwe Friedrichsen, der sich ebenfalls und sehr intensiv genau mit dieser Frage auseinandergesetzt hat: ChatGPT already knows