Zwei Fragen für das Enterprise Engineering: Muss sich die Art und Weise, wie wir Software entwickeln, ändern, und worin sollte sie sich verändern?
Seit 50 Jahren gibt es einen Beruf, der offen sichtbar ist: den Programmierer. Was dieser Beruf hervorbringt, ist still und leise zu dem geworden, worauf alles andere läuft.
Das Ausmaß dieses Wandels lässt sich leicht unterschätzen. Im Jahr 1980 gab es in den Vereinigten Staaten laut Daten des Bureau of Labor Statistics, berichtet von Fortune, 2025, etwa 300.000 Arbeitsplätze in der Computerprogrammierung, und die Maschinen, für die diese Menschen programmierten, standen in Räumen, die die Öffentlichkeit kaum je betrat. Ein Auto dieser Zeit verfügte über einen Single-Function-Chip, der den Zündzeitpunkt steuerte.
Heute sind laut ITU, 2025 etwa 6 Milliarden Menschen, rund 74 Prozent der Menschheit, online. Die weltweiten IT-Ausgaben werden in diesem Jahr laut Gartner, 2026 voraussichtlich 6,37 Billionen US-Dollar erreichen, davon allein mehr als 1,47 Billionen US-Dollar für Software. Weltweit programmieren laut SlashData, 2025 rund 36,5 Millionen Menschen beruflich, während weitere etwa 10 Millionen dies als Hobby, im Studium oder als Nebenkompetenz tun. Und dieses Auto wird heute mit rund 100 Millionen Codezeilen ausgeliefert, verteilt auf mehr als hundert Steuergeräte – eine Schätzung aus dem Jahr 2021, die heute mit ziemlicher Sicherheit noch höher liegt.
Irgendwann wurde Software von einer Produktkategorie zu dem Medium, über das Menschen ihr Geld, ihre medizinische Versorgung und ihre Regierung erreichen. Niemand kann sich dem entziehen. Und mit KI, die selbst Software ist und zugleich als Motor für die Produktion noch mehr Software dient, wird die Kurve steiler, nicht flacher.
Das wirft zwei Fragen auf. Die erste ist offensichtlich. Die zweite ist die, für die sich Ihre Zeit lohnt.
Muss sich die Art und Weise, wie wir Software produzieren, ändern?
Ja. Nicht weil die Werkzeuge besser geworden sind, sondern weil die Anforderungen gestiegen sind – und weil es problematisch wird, ein schnelles Werkzeug an einen langsamen Prozess zu koppeln.
Eine Frau reichte im vergangenen Frühjahr ihre Steuererklärung über ein neues staatliches Portal ein. Es stürzte zweimal ab. Die Fehlermeldung machte „hohen Traffic“ dafür verantwortlich. Das war nicht der Traffic. Die Behörde hatte Code schneller ausgeliefert, als irgendjemand ihn testen oder überprüfen konnte. Sie reichte die Erklärung per Post erneut ein. Niemand bezeichnete das als Fehler. Die Pull Requests wurden weiterhin als Fortschritt gezählt.
Dieser Fehler ist strukturell, nicht zufällig. Anforderungen werden so geschrieben, dass Menschen sie langsam lesen können. Review-Gates sind auf die Menge ausgelegt, die ein menschliches Team innerhalb eines Sprints produziert. Testpläne gehen davon aus, dass eine Person den Code geschrieben und eine andere ihn sorgfältig gelesen hat, bevor er ausgeliefert wird. Wenn man einen KI-Coding-Assistenten in diese Pipeline einfügt, hat man die Einschränkung nicht beseitigt, sondern nur verlagert. Code kommt jetzt schneller an, als Review, Tests, Sicherheitsfreigaben und Deployment-Genehmigungen ihn verarbeiten können. Der Bürger sieht keine dieser Stationen. Er sieht den Timeout.
Die Zahlen sagen dasselbe. Laut Gartner, 2025 erzielen Unternehmen, die KI nur für die Codegenerierung einsetzen, auf Systemebene etwa 10 Prozent Produktivitätssteigerung, während Teams, die KI konsequent über den gesamten Lebenszyklus hinweg einsetzen – von den Anforderungen bis zum Betrieb – bis 2028 voraussichtlich 25 bis 30 Prozent erreichen werden. Die Einführung war nie das schwierige Thema: Laut Gartner, 2025 werden bis 2028 voraussichtlich 90 Prozent der Enterprise Engineers KI-Code-Assistenten nutzen, gegenüber weniger als 14 Prozent im Jahr 2024.
Entwicklerproduktivität und Bürgererfahrung sind nicht dasselbe Maß. Die eine misst den Output pro Person. Die andere misst, ob eine reale Person das bekommen hat, wofür sie gekommen ist. Ein Team kann die erste Zahl ein Jahr lang verbessern und gleichzeitig beobachten, wie sich Beschwerden kaum verändern.
Worin sollte es sich verändern?
Nicht in einen weiteren Coding-Assistenten. Die Aufgabe besteht darin, zu steuern, was die Agenten tun dürfen, sobald sie sich bereits innerhalb der Pipeline befinden. Vier Schritte, in dieser Reihenfolge.
- Die Grenze festlegen, bevor der Agent das Repository berührt. Was er ändern darf, wer seine Ergebnisse überprüft und wie diese Entscheidung protokolliert wird. Die meisten Unternehmen haben keine dieser Entscheidungen getroffen. Sie haben die Tools aktiviert und gehofft, dass der Prozess nachzieht.
- Reviews nach Risiko statt nach Gewohnheit priorisieren. Routinemäßige Änderungen mit geringem Risiko erhalten eine automatisierte Validierung. Alles, was die Daten einer Person, eine Zahlung oder eine Compliance-Grenze betrifft, behält eine menschliche Freigabe mit dokumentierter Begründung. Das bedeutet weder, alles manuell zu prüfen, noch gar nichts zu überprüfen – es ist die eigentliche Neugestaltung.
- Eine Rückverfolgbarkeit bewahren, die auch sechs Monate später noch die schwierige Frage beantwortet. Was der Agent geändert hat, warum und in wessen Auftrag. Erklärbarkeit hört dort auf, ein Forschungsthema zu sein, wo eine Aufsichtsbehörde, ein Prüfer oder ein Kunde nachfragt.
- Die Person am anderen Ende messen. Ermitteln, wo KI-generierte Arbeit tatsächlich stecken bleibt, nicht wo sie am schnellsten läuft. Die relevante Kennzahl ist, ob sie ihre Steuererklärung einreichen konnte.
„Erfordert von Software-Engineering-Führungskräften, ihre Strategien zu überdenken“, so beschrieb Joachim Herschmann, VP Analyst bei Gartner, was die LLM-basierte Entwicklung heute von Engineering-Organisationen verlangt.
Genau auf dieser Ebene ist Calsofts Praxis für die Entwicklung intelligenter Systeme im großen Maßstab aufgebaut: agentische KI-Entwicklung mit kontrollierter Autonomie, nicht Agenten, die ohne klar definierte Grenzen auf Produktionssystemen arbeiten. Governance ist nicht der Teil, den Unternehmen nachträglich an einen funktionierenden AI-Native-SDLC anbauen. Sie ist der Teil, der die Person am anderen Ende der Transaktion schützt.
1980 war der Output eines Programmierers ein Produkt. Heute ist er eine Infrastruktur, auf die 6 Milliarden Menschen nicht verzichten können. Eine schnellere Testsuite spielt keine Rolle, wenn der Bürger weiterhin auf ein fehlerhaftes Formular stößt. Eine schnellere Pipeline spielt keine Rolle, wenn niemand erklären kann, warum ihre Einreichung zweimal fehlgeschlagen ist.
Die Unternehmen, die dies richtig umsetzen, werden nicht diejenigen sein, die bis Dezember den meisten KI-generierten Code produziert haben. Es werden diejenigen sein, bei denen Bürger und Kunden die Software nicht mehr bemerken, weil sie einfach funktioniert.
FAQs
Warum muss die Softwareproduktion jetzt neu strukturiert werden?
Weil sich die Abhängigkeit verändert hat. Software wurde von einer Produktkategorie zu dem Medium, über das Milliarden Menschen Geld, Gesundheitsversorgung und staatliche Leistungen erreichen. KI generiert Code jetzt schneller, als Review, Tests, Sicherheitsfreigaben und Deployment-Genehmigungen ihn verarbeiten können – all diese Prozesse sind weiterhin auf das Volumen vor der KI-Ära ausgelegt. Die Einschränkung hat sich nachgelagert verschoben; der Prozess wurde nicht angepasst.
Was ist ein AI-Native-SDLC?
Ein Softwareentwicklungslebenszyklus, der rund um KI-Agenten neu aufgebaut wurde, die in jeder Phase arbeiten – von den Anforderungen bis zum Betrieb – statt einen Assistenten an einen Prozess aus der Vor-KI-Zeit anzubauen. Er ersetzt sequenzielle, vom Menschen bestimmte Workflows durch risikobasierte Reviews und kontinuierliche Validierung, sodass die Person, die die Software nutzt, weniger Fehler erlebt, anstatt lediglich schneller Code zu erhalten.
Wie sollten Unternehmen den SDLC für KI neu strukturieren?
Agentengrenzen festlegen, bevor Agenten das Repository berühren. Reviews nach Risiko sortieren: automatisierte Validierung für routinemäßige Änderungen, menschliche Freigabe mit Audit-Trail für alles, was Daten, Zahlungen oder Compliance betrifft. Rückverfolgbarkeit bewahren, die auch Monate später Bestand hat, und Kundenergebnisse statt Entwickler-Output messen.
