Den größten Effekt hat AI dort, wo niemand auf den Code schaut
Einer der größten Hebel von AI liegt fast nie da, wo programmiert wird.
An anderer Stelle habe ich argumentiert, dass AI in Organisationen vor allem als Verstärker wirkt: Sie verstärkt nicht das, was eine Organisation sein will, sondern das, was sie ist (AI als exponentieller Verstärker). Mein aktueller Auftrag liest sich auf den ersten Blick wie ein Widerspruch zu dem Thema, ist aber die beste Bestätigung dieser These, die ich bisher erlebt habe: Ich soll mit einer kleinen Gruppe von Experten AI breit in der Softwareentwicklung verankern, und Code spielt in meiner Rolle dabei keine Rolle. Nicht das Werkzeug anwerfen, nicht Pipelines bauen, sondern das Ganze betrachten — wie die Disziplinen ineinandergreifen und wo Wirkung im Unternehmenskontext verloren geht.
Aus dieser Perspektive wird etwas sichtbar, das sich aus der Nähe schwer erkennen lässt: Einer der größten Effekte von AI liegt fast nie da, wo programmiert wird.
Das klingt zunächst ungewohnt, weil Coding das Sichtbarste am ganzen Prozess ist — die Stelle, an der die spektakulären Demos passieren. Aber der Software Development Lifecycle, also Business-Analyse, Entwicklung, Testing, Betrieb und dann von vorn, wird meistens als Kette gedacht, Glied für Glied, und in dieser Logik schaut man immer nur auf das Glied, in dem gerade gearbeitet wird. Die Hebel mit der größten Wirkung liegen aber an den Stellen, die diese Kettensicht übergeht: in der Phase, bevor die Kette beginnt, in den Übergängen zwischen den Gliedern und in den Schichten unterhalb des eigentlichen Entwickelns.
Die teuersten Entscheidungen fallen, bevor die erste Zeile gedacht wird
Wenn die Entwicklung beginnt, sind die folgenreichsten Weichen längst gestellt: Was bauen wir überhaupt, was kostet es wirklich, wovon hängt es ab. Diese Fragen gehören in die Konzeption und die Portfolioplanung, und schon hier kann AI augmentierend wirken, lange bevor sie irgendeine Zeile Code berührt.
Entscheidend ist, dass sich ein neues Vorhaben in die bestehende Landschaft einbetten muss, statt isoliert geplant zu werden. Wenn man der AI verfügbar macht, was im Unternehmen ohnehin vorliegt — Zielbilder, Target Landscape, Strategieziele, all die Dokumente, die selten jemand zusammen liest — brechen die Silosichten auf. Man erkennt früh, ob eine Fähigkeit vielleicht schon existiert, wo sich Vorhaben überschneiden und wo Abhängigkeiten lauern, die sonst erst im Schmerz sichtbar werden. Eine AI-gestützt erzeugte Capability Map ist dafür ein gutes Beispiel: Sie ist zugleich Werkzeug, um ein Vorhaben überhaupt in der Landschaft zu verorten, und Grundlage, auf der weitere Prozesse wiederum AI-gestützt aufsetzen können. Damit bekommt man realistischere Einschätzungen, bevor irgendwer committet, und sieht Bottlenecks früh genug, um zu reagieren — etwa wenn alle Vorhaben auf dasselbe Partnerteam zulaufen. Im Big Room Planning ließe sich das zwar auch noch erkennen, aber je früher es sichtbar wird, desto billiger ist die Korrektur.
Dokumentation und Governance sind die Datengrundlage, nicht das Beiwerk
Dokumentation, Architektur und Governance tauchen im klassischen SDLC für die meisten kaum auf — lästige Pflicht, schon veraltet bevor sie überhaupt geschrieben wurde - und ungeliebt. Dabei sind das die Artefakte, auf denen im Unternehmenskontext weitere Prozesse und Facetten aufsetzen.
Sobald sie an den richtigen Stellen automatisch entstehen, ändert sich ihr Charakter grundlegend: Aus der manuellen Aufgabe, die nach zwei Wochen veraltet ist, werden Daten, mit denen Governance, Security oder das Architekturteam tatsächlich arbeiten können. Die Kolleginnen und Kollegen sehnen sich längst nach diesen Daten und nach ihrer Verknüpfung; was ihnen fehlte, war die Möglichkeit, sie aktuell zu halten, ohne dafür auf Dritte angewiesen zu sein, für die diese Pflege nie oben auf der Liste steht. Genau diese Abhängigkeit ist der Grund, warum solche Daten chronisch veralten — nicht mangelnder Wille, sondern eine Systemlogik, in der die Pflege immer an jemandem hängt, für den sie verständlicherweise nie dringend ist.
Artefakte müssen über die eigene Disziplin hinaus nutzbar sein
Wir sind in skalierter, agiler Entwicklung organisiert, und trotzdem nutzen kaum Business-Analysten die neuen Werkzeuge, im Testing schaut kaum jemand darauf, und Tester und BAs arbeiten weitgehend nebeneinander her, jeder in seinem Kettenglied. Dabei läge gerade hier eine Gelegenheit, die kaum jemand hebt.
Ein Beispiel: Die BA schreibt ihre Akzeptanzkriterien als Fließtext in Jira, die Testseite übersetzt sie anschließend von Hand ins Test-Tool. Derselbe Fall wird zweimal formuliert, von zwei Rollen, und dabei oft zweimal unterschiedlich verstanden. Ein Artefakt, das die Business-Analyse erzeugt, könnte im Testing unmittelbar weiterlaufen, sofern man es von vornherein so anlegt, dass die spezialisierten Werkzeuge entlang der Kette sauber daran andocken. Die Kettenlogik selbst ist dabei nicht das Problem; sie wird erst dann eines, wenn man die erzeugten Artefakte nur für den nächsten Schritt denkt und ihre weitere Nutzbarkeit aus dem Blick verliert. Wer sie von Anfang an als wiederverwendbares Material begreift und die Kette zugleich in die übergreifenden Hintergrundstrukturen des Unternehmens einbettet — Architektur, Governance, Datenhaushalt — erweitert sie um genau die Dimension, die ihr in der reinen Abfolgesicht fehlt.
Kosten sind ein Maßstab für Wirkung, aber nicht der einzige
Woran messen wir Wirkung überhaupt? Fast immer an Automatisierung und Kosten: Zeit gespart, also Geld gespart, ein sauberer KPI, den jeder versteht und der sich problemlos ins Deck schreiben lässt.
Nur erfasst er bei Weitem nicht alles. Tech Debt aufzulösen ist ein Hebel, Qualität ein weiterer. Einen Hebel verschweigt fast jeder Business Case: AI legt offen, wo es längst brennt. Beispiel: Lässt man AI über Bestands- und Legacy-Systeme laufen, zeigt sich, wo überall noch Sicherheitslücken stecken — was gerade jetzt zählt, weil dieselben Werkzeuge auch der Gegenseite zur Verfügung stehen und mit der Angriffsfläche auch deren Werkzeugkasten wächst. Das Problem dahinter ist, dass die KPIs und Baselines fehlen, an denen man solche Effekte festmachen könnte, und dass verschiedene Rollen ohnehin Verschiedenes sehen: Der CFO schaut auf Kosten, der COO auf Operations und Auslastung, der CIO auf einen stabilen und sicheren Betrieb, Governance auf einen regulatorisch tragfähigen Prozess. Wer Wirkung nur über die Kostenschiene erzählt, redet an dreien dieser vier Menschen vorbei.
Die Schere zwischen Enthusiasten und Abgehängten wächst schneller als jedes Programm
Während über die richtige Kennzahl noch diskutiert wird, zieht ein Teil der Mannschaft einfach davon. In dem Umfeld, in dem ich gerade arbeite, orchestrieren die einen bereits Multi-Agenten-Systeme, während die anderen noch damit hadern, einen simplen Chat in ihren Alltag einzubauen. Und diese Lücke schließt sich nicht von selbst, sondern wächst schneller, als jedes Enablement-Programm hinterherkommt — gerade weil die intrinsisch Motivierten sich aus eigenem Antrieb rasant weiterentwickeln. Auch das ist der Verstärker am Werk, diesmal auf der Ebene der Menschen: Vorhandene Fähigkeit und vorhandener Antrieb werden potenziert, fehlende eben nicht.
Das ist die unbequeme Stelle, an der ich ehrlich sein will: Man nimmt nicht alle mit. Man kann versuchen, die Richtigen mitzunehmen, was etwas grundlegend anderes ist als der Anspruch, niemanden zu verlieren — und vor allem das Ehrlichere.
Die verschobene Rolle öffnet Räume, die vorher verschlossen waren
Dass Code in meiner Rolle nur eine untergeordnete Bedeutung hat, ist kein Mangel an dieser Rolle, sondern ihr eigentlicher Punkt. Sobald AI das Programmieren-Können von der Fähigkeit entkoppelt, etwas Gutes zu bauen, verschhieben sich die Aufgaben und Verantwortungen (und Rechte). Wer immer ein Gespür für Abstraktion, sauberes Design und Qualität hatte, am Handwerk des Codens aber scheiterte, kann jetzt beauftragen, prüfen und Innovation treiben. Kurzfristig sieht das nach eingesparten Stellen aus; mittelfristig halte ich es für etwas anderes, weil Kapazitäten frei werden, Rollen zusammenrücken und im Netto ein Spielraum entsteht, den es vorher nicht gab — weniger eine Einsparung als eine Hebung von Potenzial. (Natürlich auch Komplexität der Systemlandschaft und Risiko, diese Governance- und Betriebsaspekte möchte ich hier aber an dieser Stelle nicht betrachten).
Auf der insureNXT in Köln im Mai 2026 berichtete ein Vortrag zum Inputmanagement, dass sechzig Prozent der Fälle in eine Handvoll Standardkategorien fallen, die klassisches Machine Learning schnell und günstig abräumt, sodass erst die übrigen vierzig Prozent das schwerere AI-Geschütz brauchen (das konnte aber an dieser Stelle erst durch den Einsatz von AI zu verprobt und dann sinnvoll umgebaut werden).
Oder die Pflege der Enterprise-Architektur, bei der sich aus Logdateien herauslesen lässt, welche Systeme tatsächlich noch auf eine Software zugreifen — was wirklich benutzt wird und was nur im Repository weiterlebt. Lauter Anwendungsfälle, die vor Kurzem undenkbar waren.
Den Code als das Eigentliche an der Softwareentwicklung zu sehen, war nicht bloß zu klein gedacht, sondern schlicht falsch. Code ist das Werkzeug, Information das Material, und das eigentliche Entwickeln ist die Abstraktion von Realitäten und Prozessen. AI verschiebt nur die Grenze, wer diese Abstraktion in lauffähige Systeme übersetzen kann — sie ersetzt die Abstraktion nicht. Die Hebel liegen dort, wo der SDLC sie strukturell nicht abbildet — vor der Kette, zwischen den Gliedern, unter dem Code. AI erschafft sie nicht, sie macht sie sichtbar und nutzbar.
Das meiste, was AI im Unternehmen wirksam macht, ist Arbeit außerhalb von AI: Prozesse beschreiben, Kontext externalisieren, Ergebnisse so fassen, dass eine Maschine sie verwerten kann. Der spannende Teil liegt selten im Modell, sondern in der Vorbereitung, die ihm vorausgeht. Aber das ist ein eigener Gedanke für ein anderes Mal.