Generative KI verändert die Softwareentwicklung in einer Geschwindigkeit, die etablierte Annahmen über Wertschöpfung und Wettbewerbsfähigkeit in Frage stellt. Die öffentliche Diskussion konzentriert sich heute vor allem auf die Automatisierung der Implementierung und die damit verbundenen Produktivitätsgewinne. Aus meiner Sicht greift diese Perspektive zu kurz. Generative KI beseitigt den Engpass professioneller Softwareentwicklung nicht, sondern verlagert ihn. Wettbewerbsvorteile entstehen künftig weniger durch die Erzeugung von Quellcode als durch die Fähigkeit, komplexe Softwaresysteme langfristig verständlich, beherrschbar und verantwortungsvoll weiterentwickelbar zu halten.
01 Einleitung
Generative künstliche Intelligenz verändert die Softwareentwicklung in kurzer Zeit spürbar. Sprach- und Codemodelle können aus natürlichsprachlichen Beschreibungen Softwareartefakte erzeugen, vorhandenen Code bearbeiten und Aufgaben in unterschiedlichen Phasen der Softwareentwicklung unterstützen (Hou u. a. 2024; Zhang u. a. 2026). Der Wunsch, Programme nicht vollständig manuell zu schreiben, ist jedoch fast so alt wie die Informatik selbst. Bereits frühe Arbeiten untersuchten, wie sich Programme aus logischen Aussagen und formalen Spezifikationen ableiten lassen oder schrittweise aus einer Problembeschreibung entwickeln lassen (Green 1969; Manna und Waldinger 1971; Wirth 1971). Später wurde dieses Ziel mit Codegeneratoren, modellgetriebener Entwicklung und Low-Code-Plattformen weiterverfolgt. Generative KI steht damit in einer längeren Entwicklungslinie. Neu sind vor allem die Breite ihrer Einsatzmöglichkeiten und der geringe Aufwand, mit dem sich auch aus unvollständigem Kontext ausführbarer Code erzeugen lässt.
Für Softwareentwicklungsunternehmen ist das mehr als ein weiterer technischer Fortschritt. Ihr Wertversprechen beruhte lange auf knappen Entwicklungskapazitäten und der Fähigkeit, kundenspezifische Systeme zuverlässig zu entwerfen und umzusetzen. Wenn sich Implementierungsarbeit schneller und kostengünstiger erledigen lässt, verliert die reine Codeerzeugung einen Teil ihrer bisherigen Knappheit. Professionelle Softwareentwicklung wird dadurch nicht überflüssig. Es verändert sich jedoch, wofür Kunden bezahlen und womit sich Anbieter voneinander unterscheiden können.
Ich betrachte diese Entwicklung aus zwei Perspektiven. Als Professor für Wirtschaftsinformatik beschäftige ich mich wissenschaftlich mit Softwareentwicklung und ihrer wirtschaftlichen Bedeutung. Zugleich bin ich seit vielen Jahren Mitgesellschafter eines Softwareentwicklungsunternehmens und erlebe die Veränderungen unmittelbar im Projektgeschäft. Aus beiden Blickwinkeln stellt sich für mich dieselbe Frage: Konzentriert sich die gegenwärtige Diskussion zu stark auf die Erzeugung von Code und zu wenig auf das, was danach mit diesem Code geschieht?
Ich vertrete die These, dass generative KI das Wertversprechen professioneller Softwareentwicklung verändert. Die Umsetzung funktionsfähiger Software bleibt ein wesentlicher Teil dieses Wertversprechens. An Bedeutung gewinnt jedoch die Fähigkeit, wachsende und sich schneller verändernde Softwaresysteme dauerhaft beherrschbar zu halten.
02 Der neue Engpass der Softwareentwicklung
Viele Untersuchungen befassen sich mit Produktivitätsgewinnen und kürzeren Bearbeitungszeiten (Peng u. a. 2023; Paradis u. a. 2024; Becker u. a. 2025). Diese Perspektive ist wichtig, erfasst aber nur einen Teil der Veränderung. Automatisierung beseitigt die grundlegende Komplexität der Softwareentwicklung nicht (Brooks 1987). Sie verlagert vielmehr den Engpass weg von der verfügbaren Implementierungskapazität hin zur Fähigkeit, ein wachsendes und sich schneller veränderndes Softwaresystem zu verstehen und kontrolliert weiterzuentwickeln.
Je mehr Code in kürzerer Zeit entsteht, desto schwieriger wird es, ein verlässliches Verständnis des Systems zu erhalten. Software besteht nicht allein aus Quellcode. Sie beruht auf fachlichen Anforderungen, Architekturentscheidungen und Qualitätszielen. Hinzu kommen die Wechselwirkungen zwischen Menschen, Organisationen und technischen Systemen. Werkzeuge können die Implementierung erheblich beschleunigen. Diese Zusammenhänge erfassen und beherrschen sie jedoch nicht automatisch.
Mit sinkendem Aufwand für die Implementierung gewinnen daher diejenigen Entscheidungen an Bedeutung, die den langfristigen Umgang mit dem System bestimmen. Die Struktur eines Softwaresystems beeinflusst, wie gut spätere Änderungen verstanden, umgesetzt und überprüft werden können. Bereits Parnas zeigte, dass die Modularisierung eines Systems dessen Änderbarkeit und Wartbarkeit wesentlich prägt (Parnas 1972). Wenn mehr Code schneller entsteht, wird es umso wichtiger, seine Auswirkungen auf das Gesamtsystem abschätzen zu können.
Ich beobachte das bereits heute im eigenen Projektgeschäft. Die höhere Geschwindigkeit der Codeerzeugung erhöht den Druck, architektonische Entscheidungen bewusst zu treffen, statt sie im Tempo der Werkzeuge einfach mitlaufen zu lassen. Wo sich neue Funktionen mit wenigen Eingaben erzeugen lassen, wächst zugleich die Gefahr, dass Inkonsistenzen, Redundanzen und schnelle Zwischenlösungen dauerhaft in ein System eingehen. Für solche langfristigen Folgen kurzfristiger Entscheidungen haben Cunningham sowie Kruchten et al. den Begriff der technischen Schulden geprägt (Cunningham 1993; Kruchten u. a. 2012).
Der neue Engpass liegt daher nicht mehr primär in der Erstellung von Quellcode. Er liegt zunehmend darin, trotz wachsendem Codeumfang und höherer Änderungsgeschwindigkeit ein verlässliches Verständnis des Systems zu bewahren und es über viele Jahre kontrolliert weiterzuentwickeln.
03 Die langfristige Beherrschbarkeit von Softwaresystemen
Der Wert eines Softwaresystems zeigt sich nicht nur bei seiner ersten Auslieferung, sondern vor allem im weiteren Betrieb. Viele Systeme bleiben über Jahre oder Jahrzehnte im Einsatz. Sie werden erweitert, technisch modernisiert und an neue fachliche oder regulatorische Anforderungen angepasst. Entscheidend ist deshalb nicht allein, wie schnell Software entsteht, sondern ob sie auch langfristig verstanden, verändert und zuverlässig betrieben werden kann. Für diese Fähigkeit greife ich im Folgenden den etablierten Begriff der Softwaregesundheit (Software Health) auf.
Die bereits erwähnten technischen Schulden prägen die Diskussion über die langfristigen Folgen technischer Entscheidungen seit mehr als drei Jahrzehnten. Sie beschreiben die späteren Kosten kurzfristiger technischer Kompromisse. Eine schnelle Lösung kann zunächst Zeit sparen, spätere Änderungen aber erschweren und zusätzlichen Aufwand verursachen. Unter den Bedingungen generativer KI reicht diese Perspektive allein nicht mehr aus. Wenn in kurzer Zeit mehr Code entsteht, hängt die langfristige Beherrschbarkeit eines Systems nicht nur von seiner technischen Qualität ab. Ebenso wichtig ist, ob das Wissen über seine Zusammenhänge erhalten bleibt und ob die Gründe früherer Entscheidungen noch nachvollzogen werden können.
Storey erweitert die Betrachtung technischer Schulden um Cognitive Debt und Intent Debt (Storey u. a. 2026). Damit richtet sich der Blick nicht mehr allein auf Code und Architektur, sondern auch auf das im Team vorhandene Systemverständnis und die Nachvollziehbarkeit fachlicher und technischer Entscheidungen. Für die Betrachtung von Softwaregesundheit ist diese Erweiterung hilfreich, weil ein System technisch gut aufgebaut und dennoch schwer veränderbar sein kann. Diese Perspektive knüpft an Naur an. Programmieren bedeutet bei ihm nicht nur, einen Programmtext herzustellen, sondern eine Theorie darüber aufzubauen, wie ein System einen Ausschnitt der Welt abbildet und weshalb es auf eine bestimmte Weise gestaltet wurde (Naur 1985). Der Quellcode kann erhalten bleiben, während diese Theorie im Team allmählich verloren geht. Generative KI kann diesen Prozess beschleunigen, weil sie Code erzeugt, ohne dass die beteiligten Entwickler beim Schreiben notwendigerweise dasselbe Verständnis aufbauen.
Von Cognitive Debt spreche ich, wenn das im Team vorhandene Systemverständnis nicht mehr mit dem Wachstum und der Veränderung der Software Schritt hält. Je größer ein System wird, desto schwerer lassen sich Architektur, Abhängigkeiten und die möglichen Folgen einer Änderung noch überblicken. Wissen zerfällt dann in Inselwissen einzelner Personen oder bleibt nur noch indirekt im Quellcode erkennbar. Geht es verloren, steigen Aufwand und Risiko jeder späteren Änderung - auch dann, wenn der vorhandene Code für sich genommen einwandfrei funktioniert. Intent Debt setzt an anderer Stelle an. Hier sind es die fachlichen Ziele, die Einschränkungen und die Gründe hinter einer Entscheidung, die sich nicht mehr nachvollziehen lassen. Mit der Zeit wird unklar, weshalb eine bestimmte Lösung gewählt und welche Alternative verworfen wurde. Aus dem Quellcode lässt sich vielleicht noch ablesen, wie sich das System verhält. Ob dieses Verhalten so überhaupt noch gewollt ist, bleibt offen. Das wird besonders relevant, wenn KI-Systeme selbst Änderungen vornehmen. Auch sie sind auf verfügbaren Kontext angewiesen. Fehlen Zielzustände und Entscheidungsgründe, kann ein Modell eine bestehende Implementierung technisch verbessern und dabei gerade jene fachliche Annahme festigen, die eigentlich verändert werden sollte.
Eine mögliche Entwicklung scheint diese Argumentation zunächst infrage zu stellen. Wenn KI hinreichend zuverlässig vollständige Anwendungen erzeugen kann, muss bestehender Quellcode bei einer Änderung möglicherweise nicht mehr im Detail verstanden oder weiterbearbeitet werden. Im Grenzfall wird nicht der vorhandene Code angepasst, sondern das System aus einer überarbeiteten Spezifikation vollständig neu erzeugt. Der Quellcode wäre dann kein dauerhaftes Artefakt mehr, sondern eine jederzeit regenerierbare Umsetzung fachlicher und technischer Vorgaben. Monperrus zeigt dieses Prinzip am Beispiel eines Coding Agents, das sich auf Grundlage seiner Spezifikation neu implementiert. Er leitet daraus die These ab, dass die Spezifikation und nicht die jeweilige Implementierung zum stabilen Artefakt wird (Monperrus 2026). Das Spec-Driven Development verfolgt eine ähnliche Richtung. Es behandelt die Spezifikation als verbindliche Grundlage, aus der Code erzeugt oder gegen die er überprüft wird (Piskala 2026). Noch weiter geht das Konzept der Ephemeral Software. Software gilt darin als vorübergehende Materialisierung einer versionierbaren und ausführbaren Absicht (de-Camino-Beck u. a. 2026).
Damit wird Systemverständnis jedoch nicht entbehrlich. Es verlagert sich vom Quellcode auf die Wissensbasis, aus der die Software entsteht. Fachliche Absichten, Datenmodelle, Schnittstellen, Qualitätsanforderungen und Prüfkriterien müssen so genau beschrieben sein, dass aus ihnen eine geeignete Implementierung erzeugt werden kann. Bei zustandsbehafteten oder stark integrierten Systemen reicht eine neue Codebasis ohnehin nicht aus. Daten, Schnittstellen und betriebliche Zustände müssen erhalten, übernommen oder kontrolliert migriert werden. Auch vollständig neu erzeugte Software muss deshalb daraufhin geprüft werden, ob sie dieselben fachlichen Aufgaben erfüllt und unter realen Bedingungen zuverlässig arbeitet. Eine unvollständige oder widersprüchliche Spezifikation wird durch die Neuerzeugung nicht behoben. Sie kann vielmehr zu einer neuen Implementierung führen, die technisch plausibel erscheint, aber wesentliche Absichten nicht mehr erfüllt. Gerade in einem solchen Entwicklungsmodell wird Intent Debt zum unmittelbaren Risiko.
Technical Debt, Cognitive Debt und Intent Debt wirken daher nicht unabhängig voneinander. Unklare Absichten erschweren den Aufbau eines tragfähigen Systemverständnisses. Fehlendes Verständnis begünstigt lokale technische Entscheidungen, deren spätere Folgen nicht ausreichend berücksichtigt werden. Schwer verständliche technische Strukturen erhöhen wiederum den Aufwand, Absichten und Zusammenhänge nachträglich zu rekonstruieren. Wird Code regelmäßig neu erzeugt, kann sich ein Teil der technischen Schulden verändern oder vorübergehend verschwinden. Defizite im Verständnis und in der Beschreibung der beabsichtigten Wirkungsweise bleiben jedoch bestehen und werden möglicherweise in jede neue Fassung übernommen.
Daran anknüpfend verstehe ich Softwaregesundheit als die Fähigkeit, ein Softwaresystem auch unter fortlaufender Veränderung verständlich, steuerbar und wirtschaftlich weiterentwickelbar zu halten. Diese Fähigkeit liegt nicht allein im System. Sie hängt ebenso davon ab, ob eine Organisation technisches und fachliches Wissen bewahrt, Entscheidungen nachvollziehbar macht und Verantwortung für die langfristigen Folgen von Änderungen übernimmt. Sollte Quellcode künftig häufiger neu erzeugt statt fortgeschrieben werden, verliert Softwaregesundheit daher nicht an Bedeutung. Ihr Schwerpunkt verschiebt sich von der Implementierung hin zur Qualität und Nachvollziehbarkeit der Wissensbasis, aus der das System immer wieder entstehen kann. Unter den Bedingungen generativer KI gewinnt Softwaregesundheit deshalb für Softwareentwicklungsunternehmen an strategischer Bedeutung.
04 Das künftige Wertversprechen der Softwareentwicklung
Für Softwareentwicklungsunternehmen hat diese Entwicklung eine weitreichende Folge, denn es wird schwieriger, den eigenen Wert allein mit der Fähigkeit zu begründen, Software zu implementieren. Kunden kaufen allerdings auch heute nicht bloß Quellcode. Sie erwarten, dass ein Anbieter fachliche Anforderungen versteht, tragfähige Entscheidungen trifft und für das Ergebnis einsteht. Generative KI verändert daher weniger die Bestandteile dieser Leistung als deren Gewichtung.
Vieles, was bislang zusammen mit der Implementierung erbracht wurde, tritt nun deutlicher als eigenständiger Wert hervor. Dazu gehören die Klärung des eigentlichen Problems, die Beurteilung technischer Folgen und die Sicherung eines Systems über seine erste Auslieferung hinaus. Je leichter sich Code erzeugen lässt, desto weniger genügt es, eine gewünschte Funktion technisch umzusetzen. Entscheidend wird, ob die Lösung in ihrem konkreten Umfeld dauerhaft funktioniert und kontrolliert verändert werden kann.
Agentische Entwicklungswerkzeuge verstärken diese Verschiebung. Sie können nicht nur Code vorschlagen, sondern zusammenhängende Arbeitsschritte übernehmen und Änderungen selbstständig in Projekte einbringen (GitHub 2025). Dadurch entfällt menschliche Verantwortung nicht. Sie richtet sich stärker auf die Gestaltung des Handlungsspielraums, die Bewertung der Ergebnisse und die Entscheidung darüber, welche Änderungen tatsächlich übernommen werden.
Damit verändert sich auch die Beziehung zwischen Auftraggeber und Softwareentwicklungsunternehmen. Bei einfachen und gut prüfbaren Aufgaben wird die reine Bereitstellung von Entwicklungskapazität leichter vergleichbar. Bei geschäftskritischen oder über lange Zeit gewachsenen Systemen bleibt dagegen entscheidend, wer die Folgen technischer Entscheidungen über den Projektabschluss hinaus überblickt und verantwortet. Der Wert eines Anbieters liegt dann nicht nur in der Lieferung einer funktionsfähigen Lösung, sondern auch in der Verlässlichkeit, mit der er ihre weitere Entwicklung begleitet.
Ich erwarte deshalb, dass rein zeitbasierte Leistungsmodelle stärker unter Begründungsdruck geraten. Sie werden nicht verschwinden, weil Aufwand weiterhin gemessen und vergütet werden muss. Geleistete Stunden erklären jedoch immer weniger überzeugend, welchen Wert ein Unternehmen geschaffen hat, wenn vergleichbare Ergebnisse mit unterschiedlich hohem Automatisierungsgrad entstehen. Wichtiger werden Leistungsmodelle, bei denen die Verantwortung für ein nutzbares, stabiles und veränderbares System sichtbar Teil des Angebots ist.
Auch die Rolle von Softwareingenieuren verändert sich dadurch. Technische Kompetenz verliert nicht an Bedeutung, denn die Ergebnisse agentischer Systeme müssen eingeordnet, überprüft und bei Bedarf korrigiert werden. Neuere empirische Arbeiten deuten darauf hin, dass sich der Schwerpunkt von der unmittelbaren Codeerzeugung stärker hin zur Steuerung, Überwachung und Verifikation verlagert. Vella und Blincoe fassen diese Tätigkeiten als supervisory engineering work zusammen. Dhanorkar et al. unterscheiden präventive Kontrolle, gemeinsame Planung, laufende Überwachung und nachträgliche Prüfung (Vella und Blincoe 2026; Dhanorkar u. a. 2026). Technische Tiefe wird dadurch nicht ersetzt, sondern zur Voraussetzung für eine belastbare Beurteilung der erzeugten Ergebnisse.
Sollte Quellcode künftig häufiger vollständig neu erzeugt statt schrittweise fortgeschrieben werden, wird diese Verantwortung noch deutlicher. Ein Softwareentwicklungsunternehmen müsste dann nicht mehr jede frühere Implementierungsentscheidung bewahren. Es müsste jedoch sicherstellen, dass die Wissensbasis, aus der eine neue Fassung entsteht, vollständig und widerspruchsfrei bleibt und dass die neu erzeugte Software zuverlässig geprüft werden kann. Der professionelle Wert läge damit zunehmend in der Fähigkeit, fachliche Absicht und technische Umsetzung auch über wechselnde Implementierungen hinweg zusammenzuhalten.
Ich sehe das künftige Wertversprechen professioneller Softwareentwicklung deshalb nicht in einer Abkehr von der Implementierung. Software muss weiterhin gebaut, geprüft und betrieben werden. Ihr eigentlicher Wert liegt in der Übernahme von Verantwortung dafür, dass ein Softwaresystem seinen Zweck erfüllt, unter Veränderung verlässlich bleibt und auch künftig wirtschaftlich nutzbar ist.
05 Fazit und Ausblick
Generative KI verändert die Softwareentwicklung nicht allein, weil sie Quellcode schneller erzeugt. Sie verschiebt den Engpass. Je mehr Software in kürzerer Zeit entsteht, desto anspruchsvoller wird es, das notwendige Systemverständnis zu bewahren, Änderungen zuverlässig zu beurteilen und die langfristigen Folgen technischer Entscheidungen zu verantworten. Darin liegt aus meiner Sicht die zentrale Veränderung für Softwareentwicklungsunternehmen. Die Implementierung bleibt Teil ihrer Leistung, verliert aber als eigenständiges Differenzierungsmerkmal an Gewicht. Wertvoller wird die Fähigkeit, fachliche Absichten in verlässliche Systeme zu übersetzen und deren Weiterentwicklung über längere Zeit zu begleiten. Softwaregesundheit wird damit zu einem wesentlichen Bestandteil des Leistungsversprechens.
Das gilt nicht nur für externe Dienstleister. Auch interne Entwicklungsorganisationen müssen klären, wie sie generative und agentische Systeme in ihre Arbeitsweise einbinden, ohne Kontrolle und Wissen über ihre Software zu verlieren. In regulierten oder geschäftskritischen Bereichen wird diese Aufgabe besonders sichtbar. Dort reicht es nicht, dass erzeugte Software funktioniert. Ihr Verhalten und ihre Entstehung müssen auch nachvollziehbar, prüfbar und verantwortbar bleiben.
Offen ist, welche Rolle der Quellcode dabei langfristig spielen wird. Sollte Software künftig häufiger aus Spezifikationen, Tests und weiteren Wissensartefakten neu erzeugt werden, könnte die einzelne Implementierung an Beständigkeit verlieren. Das Systemverständnis wird dadurch jedoch nicht entbehrlich, sondern verlagert sich auf die zuvor beschriebene Wissensbasis. Softwaregesundheit würde sich dann weniger an der Beständigkeit des Codes als an der Verlässlichkeit dieser Wissensbasis zeigen.
Die weitere Entwicklung ist schwer vorherzusagen. Modelle, Werkzeuge und Arbeitsformen verändern sich schneller als die dafür notwendigen organisatorischen Strukturen. Umso wichtiger wird es, Produktivitätsgewinne nicht isoliert zu betrachten. Zu untersuchen bleibt, wie sich KI auf den gesamten Lebenszyklus eines Softwaresystems auswirkt und wie sich Cognitive Debt und Intent Debt erkennen lassen, ohne Verständnis und Absicht auf einfache Kennzahlen zu reduzieren. Die Zukunft professioneller Softwareentwicklung entscheidet sich daher nicht an der Frage, ob Menschen oder KI den Code schreiben. Entscheidend ist, ob Organisationen auch unter wachsender Automatisierung fachliche Absicht, technische Umsetzung und Verantwortung zusammenhalten können. Darin sehe ich das künftige Wertversprechen von Softwareentwicklungsunternehmen.
Über den Autor. Prof. Dr. Peter Mandl lehrt Wirtschaftsinformatik an der Hochschule München, ist Gründer der iSYS Software GmbH und Partner bei evaltech. Verantwortlicher der evaltech-Boutique für Tech Due Diligence, AI Exposure & Resilience und AI-driven Software Development.