Wie Agentic Coding die Softwareentwicklung verändert

Über Jahre hat sich in der Softwareentwicklung etwas verändert, fast unbemerkt. Viele Unternehmen haben noch nicht erfasst, was es mit dieser Veränderung auf sich hat.

Lange Zeit lag der Engpass dort, wo Code geschrieben wurde. Heute gilt das nicht mehr. Leistungsfähige KI-Agenten analysieren bestehenden Code, schlagen Lösungen vor, verändern mehrere Dateien gleichzeitig, führen Tests aus und optimieren Ergebnisse iterativ – häufig schneller, als Entwicklerinnen und Entwickler Anforderungen vollständig durchdringen können. Damit beginnt eine zentrale Grenze zu verschwimmen, auf der Teamstrukturen, Projektgrößen und Lieferzyklen über Jahre hinweg aufgebaut waren.

Der nächste Engpass in der Softwareentwicklung ist deshalb kein Thema der Geschwindigkeit. Kein Tooling-Problem. Nicht einmal eine Frage des Talents. Es ist eine Frage des Vertrauens.

Die zentrale Herausforderung besteht nicht mehr darin, softwareähnliche Ergebnisse zu erzeugen. Entscheidend ist vielmehr, Absichten in korrektes, sicheres und nachvollziehbares Verhalten zu übersetzen und daraus Systeme zu machen, auf die Unternehmen sich wirklich verlassen können.

Warum sich die Vertrauenslücke nicht von allein schließt

Die Signale aus dem Markt sind eindeutig. Das Thema kann nicht länger als Hype abgetan werden.

Die Developer Survey 2025 von Stack Overflow zeigt: 84 Prozent der Befragten nutzen bereits KI-Tools in ihrer Entwicklung oder planen den Einsatz. 51 Prozent professioneller Entwickler*innen arbeiten täglich damit. Gleichzeitig fehlt Vertrauen: Mehr Entwickler*innen misstrauen der Genauigkeit von KI-generiertem Code (46 Prozent), als ihr vertrauen (33 Prozent).

Diese Lücke ist kein vorübergehender Nebeneffekt. Sie ist strukturell.

KI-Systeme erzeugen Code, indem sie statistisch wahrscheinliche Fortsetzungen aus großen Trainingsdaten ableiten. Bekannte Muster reproduzieren sie sehr gut: Standard APIs, gängige Geschäftslogik oder komponentenbasierte Templates. Schwierig wird es, wenn Kontext und Konsequenzen zählen, etwa bei verteilten Systemen mit komplexer Fehlertoleranz, subtilen Business Rules oder Sonderfällen, die erst unter realer Last sichtbar werden.

Ein KI-Agent versteht nicht, was eine Stunde Ausfall tatsächlich bedeutet, wenn es um Umsatz, Reputation oder vertragliche Verpflichtungen geht. Die eigentliche Vertrauenslücke liegt genau dort: zwischen Code, der Tests besteht, und Verhalten, das den Zweck des Systems wirklich erfüllt.

Stell Dir eine Loyalty-Rabattfunktion vor, die ein Agent entwickelt hat. In der Spezifikation steht: „20 % Rabatt für Treuekund*innen“. Der Agent setzt dies korrekt um. In der Spezifikation war allerdings nie festgelegt worden, ob sich der Rabatt mit laufenden Promo-Codes kombinieren lässt. In der Produktion, mitten in einer stark frequentierten Kampagne, war genau das möglich. Die Tests liefen erfolgreich und galten als bestanden. Die Geschäftslogik nicht.

Diesen Unterschied zu verstehen, ist Führungsaufgabe. KI muss nicht perfekt sein, um Mehrwert zu schaffen. Aber sie braucht Leitplanken.

Der größere Wandel: Umsetzung wird Orchestrierung

Das klassische Modell der Softwareentwicklung basierte auf einem einfachen Engpass: Menschliche Umsetzungskapazität ist begrenzt. Anforderungen werden ins Design überführt, vom Design ins Engineering, dann in die Qualitätssicherung und schließlich in den Betrieb.

Jede Übergabe kostet Zeit und begrenzt den Output auf das, was Menschen an Code produzieren und verifizieren können. Mit agentischen Systemen verliert diese Grenze an Bedeutung. Code entsteht schneller, als Vertrauen in ihn wachsen kann.

Es hilft, die Sache in zwei Schleifen zu denken. Die erste beantwortet die eigentliche Frage: Was bauen wir und woran erkennen wir, dass es gut ist? Hier geht es um Ziele, Ergebnisse und die Richtung. Diese Ebene bleibt menschlich.

Die zweite setzt um: Code wird geschrieben, Tests entstehen, Tools werden konfiguriert, Infrastruktur aufgebaut. Genau diese Arbeit übernehmen zunehmend Agenten.

Die meisten Probleme entstehen dazwischen. Menschen formulieren ihre Absichten nicht präzise genug, Agenten setzen sie dafür umso wörtlicher um. Das Ergebnis funktioniert technisch trifft aber oft nicht den eigentlichen Zweck.

Die Rolle von Entwickler*innen verschiebt sich: weg davon, im System zu arbeiten, hin dazu, am System zu arbeiten. Es geht weniger darum, jeden Schritt selbst umzusetzen, sondern die Bedingungen zu gestalten, unter denen Agenten zuverlässig liefern. Die knappe Ressource ist nicht mehr das Schreiben von Code. Vielmehr ist es die Fähigkeit, unscharfe menschliche Absichten in klare Anweisungen zu übersetzen, in präzise Vorgaben, Constraints, Prüfmechanismen und Rollout-Bedingungen. Anders gesagt: Anforderungen dürfen nicht länger ungenau sein.

Das verändert auch den Blick auf Talent und Teamstrukturen. Wenn operative Entwicklungsaufgaben zunehmend automatisiert werden, steigt der Bedarf an Engineers, die generierte Ergebnisse kritisch prüfen und Auswirkungen auf Systemebene verstehen. Aus Ticket Ownership wird System Ownership. Coding Skills entwickeln sich weiter zu Planungs- und Bewertungsfähigkeiten.

Governance wird zum Wettbewerbsfaktor

Viele Unternehmen behandeln KI noch immer als Richtlinienfrage: erlauben oder verbieten.

Das greift zu kurz. Die eigentliche Frage ist ob Organisationen KI in einem kontrollierten Rahmen nutzen oder im Verborgenen. „Shadow AI“ ist längst Realität. Gemeint ist der Einsatz von KI-Tools ohne Freigabe oder Aufsicht durch die IT. Eine WalkMe-Studie aus dem Jahr 2025 unter 1.000 Beschäftigten zeigt: 78 Prozent der Mitarbeitenden nutzen KI-Tools, die ihr Unternehmen nicht offiziell genehmigt hat. Ein Bericht von UpGuard kommt auf ähnliche Werte, selbst Sicherheitsfachkräfte greifen häufig zu nicht autorisierten Lösungen.

Das Verbieten von Tools löst selten das Problem. Meist reduziert es nur Transparenz und Steuerbarkeit von etwas, das die Mitarbeitenden ohnehin nutzen. Der bessere Weg ist kontrollierte Befähigung. Unternehmen sollten einen freigegebenen Tool-Stack definieren, Einsatzgrenzen festlegen und Zugriffe auf sicherheitskritische Code-Repositories oder Datenströme begrenzen. Ebenso wichtig sind klare Review-Prozesse, nachvollziehbare Logs und Trainings zu sicheren Arbeitsweisen.

Wettbewerbsfähigkeit und Compliance laufen zunehmend in dieselbe Richtung: kontrollierte Einführung statt unregulierter Nutzung. Der Business Case liegt also auf der Hand. Ungesteuerter KI-Code in Produktion erhöht Risiken: Ausfälle, Compliance-Verstöße, Vertrauensverlust bei Kund*innen. Gut gesteuerte Nutzung verkürzt dagegen die Time-to-Market, ohne operative Stabilität zu gefährden.

Governance bremst Innovation nicht. Sie sorgt dafür, dass Innovation nicht zum unkalkulierbaren Risiko wird.

Der SDLC wird zum Intent-to-Release-System

Im klassischen Software-Lebenszyklus waren Anforderungen, Umsetzung, Qualitätssicherung und Betrieb sowohl organisatorisch als auch zeitlich voneinander getrennt. Diese Trennung funktionierte, weil die Menschen in der Lage waren, über alle Übergaben hinweg das Gesamtbild im Blick zu behalten. In einem agentischen Entwicklungsmodell wird genau diese Trennung zum Problem.

Der neue Entwicklungszyklus

Vereinfacht gesagt sieht der neue Ablauf so aus: Ziele müssen geschärft werden. Gleichzeitig wird klar definiert, was ausdrücklich nicht gebaut werden soll. Es geht darum, Grenzen zu setzen, Akzeptanzkriterien in überprüfbare Checks zu übersetzen und den Agenten innerhalb dieser Leitplanken arbeiten zu lassen.

Die Ergebnisse werden anschließend konsequent validiert, kontrolliert ausgerollt, im Verhalten beobachtet und die Erkenntnisse fließen direkt zurück in den Prozess. Auf dem Papier wirkt das einfach. In der Praxis verschiebt sich jedoch vieles grundlegend.

Anforderungen werden ausführbar

Im klassischen Modell konnte ein Product Manager schreiben: „Nutzer*innen sollen nach Datumsbereichen filtern können“ und darauf vertrauen, dass ein Engineer die daraus entstehenden Sonderfälle mitdenkt.

Ein Agent setzt hingegen genau das um, was in der Spezifikation steht und nichts darüber hinaus. Wenn dort nicht definiert ist, was passiert, wenn das Startdatum nach dem Enddatum liegt, wird der Agent selbst eine Entscheidung treffen. Und die ist oft nicht die richtige.

Was ein menschlicher Engineer wohlwollend interpretieren würde, wird für den Agenten zur wörtlichen Vertragsgrundlage. Ein PM, der unklare Anforderungen formuliert, bremst damit nicht länger nur einen Engineer aus, sondern konfiguriert ein System falsch.

Qualitätssicherung rückt nach vorn und läuft kontinuierlich mit

Zu warten, bis Code in einer CI-Pipeline landet, um sein Verhalten zu prüfen, ist nicht mehr tragfähig, wenn ein Agent noch vor dem Mittag fünf Pull Requests erstellt.

Testabdeckung, statische Analysen und Verhaltensvalidierung müssen im Entwicklungsprozess selbst stattfinden nicht erst nachgelagert. Die Rolle von QA (Quality Assurance) verschwindet dabei nicht, sie verändert sich: weg von der Ausführung von Testplänen, hin zum Entwurf automatisierter Prüfmechanismen, die dauerhaft im Hintergrund laufen.

Architektur wird zur Dokumentation

Agenten bauen kein implizites Wissen über mehrere Sessions hinweg auf. Jedes Mal, wenn ein Agent eine neue Aufgabe startet, liest er den Code wie eine neue Person am ersten Arbeitstag, allerdings ohne die Möglichkeit, Fragen zu stellen oder Kontext aus Gesprächen mitzunehmen. Wenn Systemgrenzen nur implizit sind, Benennungen inkonsistent oder Datenflüsse nur mit implizitem Wissen nachvollziehbar, wird der Agent Fehler machen. Teams, die in klare Architekturen, saubere Schnittstellen und explizite Konventionen investiert haben, erzielen bessere Ergebnisse. Nicht, weil das Modell intelligenter ist, sondern weil der Agent auf einer belastbareren Grundlage arbeitet.

Am stärksten verändert sich die Rolle des Produkt Managements

Solange Umsetzung langsam und teuer war, konnten Anforderungen schrittweise anhand der Implementierung weiterentwickelt werden. In einem agentischen Setup sind die Kosten für eine fehlerhafte Implementierung zwar nahezu null, die Kosten für deren Review und Korrektur jedoch nicht. Der Engpass verschiebt sich damit von „jemanden zu finden, der es baut“ hin zu „es beim ersten Mal richtig zu spezifizieren“. Das erfordert ein anderes Skillset und viele Organisationen stehen am Anfang dieser Umstellung.

Auch Engineering Leadership verschiebt sich: weg vom Zählen von Output, hin zur Gestaltung eines Systems, das verlässliche Veränderung überhaupt erst ermöglicht.

Was Führungskräfte jetzt messen sollten

Agentisches Coding macht klassische Output-Metriken endgültig unbrauchbar.

Codevolumen lässt sich leicht künstlich steigern. Entwickler berichten bereits heute, dass rund 42 Prozent des von ihnen eingecheckten Codes KI-unterstützt entstehen – ein Anteil, der bis 2027 deutlich weiter wachsen wird. Zu messen, wie viel Code ein Team ausliefert, sagt damit kaum noch etwas darüber aus, ob dieser Code sicher oder korrekt ist.

Aussagekräftiger sind Kennzahlen, die Vertrauen, Flow und Geschäftswirkung abbilden:

• Time-to-Verify: getrennt von Time-to-Generate: Gemessen wird die Zeit vom Öffnen eines Pull Requests bis zum Bestehen aller menschlichen Review-Gates. Sinkt dieser Wert nicht, während die Generierung zunimmt, entsteht ein neuer Engpass. Ohne diese Differenzierung baut sich Verifikationsaufwand schleichend und oft unbemerkt auf.
• Incident-Raten bei KI-unterstütztem Code: Incidents werden in Post-Mortems so markiert, dass sichtbar wird, ob KI-unterstützter Code beteiligt war. Selbst einfache Heuristiken reichen aus, um eine belastbare Feedback-Loop aufzubauen. Ohne diese Transparenz fehlt das Signal, ob der Review-Prozess tatsächlich wirksam ist.
• Rollback-Frequenz: Die meisten Deployment-Tools erfassen diese Kennzahl bereits. KI-unterstützte Releases sollten als eigene Kohorte betrachtet werden, um Unterschiede sichtbar zu machen. Die Folgen oberflächlicher Reviews bleiben sonst lange verborgen bis sie spürbar werden.
• Zeit von Spezifikation bis zum sicheren Release: Gemessen vom Moment, in dem Akzeptanzkriterien definiert und fixiert sind, bis zum Release hinter einem Feature-Flag in Produktion. Diese Kennzahl zeigt, ob agentische Ansätze tatsächlich beschleunigen oder lediglich den Engpass verschieben. Gleichzeitig ist sie eng mit Time-to-Market und Wettbewerbsfähigkeit verknüpft.

Wenn KI die Softwareproduktion vereinfacht, verlagert sich der Wettbewerbsvorteil zu den Organisationen, die mehr Ideen in verlässliche Releases übersetzen können ohne dabei Kontrolle zu verlieren. In diesem Kontext werden Verifikationsfähigkeit, Architekturqualität, Governance-Reife und Sicherheitsdisziplin zu geschäftskritischen Fähigkeiten, nicht nur zu Engineering-Themen.

Die wichtigste Erkenntnis

Die Zukunft der Softwareentwicklung ist nicht: „KI schreibt Code und Menschen schauen zu.“
Sie ist: „Menschen gestalten Systeme, die maschinell erzeugte Veränderung vertrauenswürdig machen.“

Die Organisationen, die am meisten profitieren, sind nicht jene mit dem höchsten Output an generiertem Code. Es sind diejenigen mit der stärksten Übersetzungsschicht zwischen Idee und produktiver Realität.

Code wird günstiger. Urteilskraft nicht. Verifikation nicht. Sichere Releases nicht. Sich frühzeitig auf diese Verschiebung einzustellen, ist keine technische Entscheidung – sondern eine strategische.

Bei IBM iX ist diese Entscheidung bereits getroffen. Wir integrieren agentisches Coding konsequent in unsere Delivery-Modelle und nutzen IBM Bob als Teil unseres Toolings. Eine dedizierte Working Group stellt sicher, dass der Einsatz gesteuert, messbar und über Teams hinweg konsistent bleibt.

Unser Ziel: schneller liefern, ohne Vertrauen und Qualität zu kompromittieren genau das, worauf unsere Kunden bauen.

Teilen