Wie KI agile Entwicklungsteams verändert, warum sie sie nicht ersetzt – und warum das gut ist.

Dieser Standpunkt ist gemeinsam entstanden mitLucas Heckmann. Vielen Dank für deine Gedanken, Diskussionen und Perspektiven!

Hinweis: Dieser Artikel bezieht sich auf geschäftskritische Unternehmenssoftware, die von professionellen Teams in großen Organisationen entwickelt wird. Nicht auf den 47. „Workflow-Designer" oder das nächste Social-Media-Start-up. Auch nicht auf Online-Marketing-Agenturen.

Generative und agentische KI wird als Heilmittel für so ziemlich alles in der Wissensarbeit vermarktet: schnellerer Code, weniger Meetings, sofortige Dokumentation, sofortige Erkenntnisse, unglaubliches Wachstum mit weniger Menschen. Und in schmalen Ausschnitten der Arbeit sind diese Versprechen real. Kontrollierte Studien zu KI-Coding-Assistenten (z. B. GitHub Copilot) zeigten, dass Entwicklerinnen und Entwickler eine definierte Programmieraufgabe mit KI-Unterstützung deutlich schneller abschlossen.

Aber die Softwarelieferung im Unternehmen wird selten durch „Code tippen" begrenzt. Sie wird begrenzt durchdas Liefersystem rund um den Code: Governance, Risikoverantwortung, Architektur, Security und Compliance sowie Betreibbarkeit.

1) Die Prototypen-Falle: „Es läuft" ist nicht dasselbe wie „Es ist auslieferbar"

KI macht es einfacher denn je, etwas zu erzeugen, dasaussieht wie ein Produkt: eine Oberfläche, Endpunkte, ein Ablauf, der auf dem Happy Path funktioniert. Was oft fehlt, ist das unsichtbare Fundament im Unternehmen: Identitäten und Zugriffe, Observability, Data Governance, Resilienzmuster, Abhängigkeitsmanagement, sichere Standardkonfiguration und eine Architektur, die sich weiterentwickeln kann, ohne brüchig zu werden.

KI kann schnell Code erzeugen. Sie kann nicht automatisch garantieren, dass das Systemsicher, betreibbar, compliant, wartbar und wirtschaftlich tragfähig ist.

2) Was KI in agilen Teams verändern wird

KI ist dort am wertvollsten, wo sieReibung undVerschwendung rund um die eigentliche Arbeit reduziert:

• Weniger Formatieren, mehr Denken: Ein Product Owner sollte keine Zeit damit verbringen, die Syntax einer Story zu perfektionieren. KI kann Struktur und Vorlagen für Akzeptanzkriterien vereinheitlichen und so Zeit für Problemzuschnitt und Validierung freimachen.

• Schnellerer Zugang zu Spezialwissen: KI kann unbekannte technische Konzepte auf Abruf erklären und die Kosten senken, „einfache" Fragen zu stellen.

• Besserer Entwickler-Flow: KI kann Tests entwerfen, fremden Code zusammenfassen, Refactorings vorschlagen und bei Dokumentation helfen – besonders stark bei Boilerplate und Routinetransformationen.

• Automatisierung im Lebenszyklus: Fehlerberichte zusammenfassen, Incidents clustern, Release Notes entwerfen, Kundenfeedback verdichten – das sind realistische Anwendungen mit hoher Hebelwirkung im Unternehmen.

Ein breiteres Muster der „Augmentation" zeigt sich auch außerhalb von Software: Eine groß angelegte Studie zu generativer KI im Kundenservice fand im Durchschnitt Produktivitätsgewinne, mit den größten Effekten bei weniger erfahrenen Beschäftigten.

3) Was KI nicht ersetzen wird (und warum agile Teamarbeit weiterhin zählt)

Lieferung im Unternehmen ist einsozio-technisches Problem: unklare Ziele, konkurrierende Randbedingungen, verborgene Annahmen und sich verändernde Umfelder. Das erfordert mehr, als Text oder Code zu erzeugen.

• Liefergeschwindigkeit ist überwiegend ein Governance- und Risikoproblem, kein Tippgeschwindigkeitsproblem. Die „Lead Time for Changes" in DORA wird vom Commit bis in die Produktion gemessen – dort dominieren Freigaben, Release-Mechanik, Bereitschaft der Umgebungen und Risikoentscheidungen. Governance existiert oft aus guten Gründen (Incidents, regulatorische Feststellungen), kann aber abdriften inProzesstheater, das Last erzeugt, ohne Risiko zu senken. KI kann helfen, Bürokratie zu reduzieren, aber sie kann unklare Risikoverantwortung oder zersplitterte Entscheidungsrechte nicht allein beheben.

• Entwicklerinnen und Entwickler bleiben verantwortlich – und müssen KI-Ergebnisse validieren können. KI überträgt keine Verantwortung. Engineering-Teams verantworten weiterhin Korrektheit, Wartbarkeit, Sicherheitsniveau und Betreibbarkeit. Im Unternehmenskontext heißt das auch: KI-erzeugte Änderungen wie jeden anderen Beitrag prüfen und hinterfragen zu können, mit denselben Qualitätsmaßstäben.

• KI ist am besten bei Fleißarbeit und Mustererkennung – nicht bei verantworteter Erfindung. Sie kann Ergebnisse produzieren, die kreativaussehen, aber die Forschung legt nahe, dass Kreativität mit hoher Neuheit schwieriger ist und häufig auf die Rekombination bekannter Muster hinausläuft. Das ist wertvoll – nur eben nicht dasselbe wie eine belastbare, verantwortete Entscheidung unter realen Randbedingungen.

• KI ist oft darauf optimiert, hilfreich und zustimmend zu sein – genau das, was Teams manchmalnicht sein sollten. Viele Assistenten sind darauf abgestimmt, Nutzerinnen und Nutzer zufriedenzustellen, was zu „Sycophancy" führen kann: der Zustimmung zu einer fehlerhaften Rahmung, statt sie infrage zu stellen. Das ist ein reales Risiko in Discovery- und Architekturdiskussionen, in denen konstruktiver Konflikt wesentlich ist.

4) Lokale Beschleunigung garantiert keine Ergebnisse im Unternehmen

Selbst wenn KI Teile der Entwicklung beschleunigt, kann sie auch Instabilität erhöhen, wenn sie mehr Veränderung durch ein System drückt, das dafür nicht bereit ist.

DORAs Untersuchung von 2024 berichtete, dass höhere KI-Adoption mitgeringerer Lieferstabilität korrelierte, und der Effekt auf den Durchsatz klein und sogar negativ sein konnte – trotz einiger Verbesserungen bei Review-Geschwindigkeit und Codequalitätsmaßen.

Das ist kein Argument gegen KI; es ist ein Argument dafür, KI in ein gesundes Engineering-System zu integrieren (Plattform, Teststrategie, Review-Standards, Observability und klare Qualitätsmaßstäbe).

5) Randbedingungen im Unternehmen, die sich nicht „wegprompten" lassen

• Security: LLM-basierte Anwendungsfälle bringen spezifische Risiken mit sich (Prompt Injection, Offenlegung sensibler Daten, unsicherer Umgang mit Ausgaben). OWASP pflegt dafür eine eigene „Top 10"-Liste für LLM-Anwendungsrisiken.

• Regulierung und Governance: In der EU tritt der AI Act schrittweise mit durchsetzbaren Anforderungen in Kraft. Unternehmensweite Rollouts brauchen Governance, weil aus einem „internen Produktivitätswerkzeug" schnell ein „kundenwirksames System" werden kann.

6) Die Parallele zu agilen Transformationen

Vor einem Jahrzehnt versuchten viele Organisationen, „Agilität zu installieren", indem sie Rollen und Meetings umbenannten. Es funktionierte nicht, weil die Randbedingungen strukturell waren: Finanzierungsmodelle, Governance, Architektur, Anreize und Führungsverhalten.

KI steht an einem ähnlichen Punkt. Es wird nicht genügen, „ein KI-Werkzeug hinzuzufügen" und sprunghafte Ergebnisse zu erwarten. Organisationen bekommen Ergebnisse, wenn sie:

• die richtigen Anwendungsfälle wählen (Reibungspunkte mit hohem Volumen),

• in Qualitäts- und Liefergrundlagen investieren,

• Leitplanken setzen (Security, Daten, Compliance),

• und Teams befähigen, KI bewusst einzusetzen (besonders für Validierung und Entscheidungsqualität).

7) Fazit – und das Gute daran

KI wird agile Entwicklungsteams absolut verändern – aber vor allem, indem sie dieeinfachen Teile einfacher und dieschwierigen Teile sichtbarer macht.

• Sie wird Entwürfe beschleunigen, einen Teil der Bürokratie automatisieren und die Kosten des Wissenszugangs senken.

• Sie wird zugleich den Einsatz bei den Engineering-Grundlagen erhöhen: kleine Batches, Testautomatisierung, Sicherheit und disziplinierte Reviews.

• Teams werden nicht verschwinden. Aber der Schwerpunkt verschiebt sich: weg vom Erzeugen von Text und Boilerplate, hin zum Entscheiden, zum Umgang mit Risiko und zur sicheren Integration von Veränderung in einer unaufgeräumten Anwendungslandschaft.

Und für die Lieferung im Unternehmen ist das eine gute Sache.