KI kann Code schreiben. Die Enterprise Implementierung ist schwieriger.

Produktmanager:innen können eine Benutzeroberfläche beschreiben und erhalten einen Prototyp. Entwickler:innen können ein Feature in Minuten aufsetzen. Gründer:innen können aus einer Idee eine Demo machen, bevor überhaupt ein Team einzustellen. Das ist praktisch.

Aber Enterprise Software wird nicht danach bewertet, wie schnell eine funktionierende Demo steht. Sie wird danach beurteilt, ob sie gewartet, erweitert und sicher als reales System betrieben werden kann.

Sie muss Enterprise-Architektur Standards erfüllen. Sich in bestehende Ökosysteme integrieren. Kundendaten sicher verarbeiten. Anforderungen an Informationssicherheit, Barrierefreiheit, Performance, Analytics, Lokalisierung, Testing, Dokumentation und Release-Readiness erfüllen.

Sie muss für das nächste Team, das daran arbeitet, wartbar sein. Und genau hier stößt reines „Vibe Coding“ an seine Grenzen. Das Problem ist nicht, dass KI schlechten Code schreibt. Oft sieht der Code sogar überraschend gut aus. Das Problem ist, dass „sieht gut aus“ und „produktionsreif“ zwei verschiedene Dinge sind.

Die Frage, ob KI Code schreiben kann, haben wir längst hinter uns. Sie kann es.

Die weitaus wichtigere Frage ist, ob ein Team diese Fähigkeit in ein Delivery-Modell verwandeln kann, das im Enterprise-Umfeld funktioniert und nachhaltigen Mehrwert schafft.

Die Branche hat sich auf einen Begriff geeinigt: Agentic Engineering. Doch dieser Name greift zu kurz. „Engineering“ fokussiert sich auf den Code – aber der Code war nie das Schwierigste. Das Schwierige ist alles drumherum: die Architektur, die Integration, die Sicherheit, der Weg in die Produktion.

Während die Branche es also Agentic Engineering nennt, kommt es eigentlich auf Agentic Software Delivery an. Auf den gesamten Prozess, nicht nur auf die Generierung von Code.

Unsere Definition: Ein steuerbares Delivery-Modell, bei dem spezialisierte KI-Agenten über den gesamten Software-Lebenszyklus hinweg arbeiten, während Ingenieure und Architekten sie anleiten, ihre Ergebnisse prüfen und die wirklich wichtigen Entscheidungen treffen.

Das ist etwas völlig anderes, als einen Coding-Assistenten zu bitten, ein Feature zu bauen. Es geht auch um mehr als nur Geschwindigkeit.

Der wahre Wert zeigt sich, wenn KI nicht nur dabei hilft, schneller zu tippen, sondern das gesamte Team dabei unterstützt, mit mehr Klarheit, mehr Konsistenz und weniger Nacharbeit voranzukommen. Kürzlich haben wir einen A/B-Test durchgeführt, bei dem fünf Tickets für Architekturverbesserungen an derselben Codebasis zugewiesen wurden.

• Der eine Weg wurde manuell von einem Principal Engineer umgesetzt.
• Der andere nutzte einen strukturierten agentenbasierten Workflow mit menschlichen Reviews an definierten Kontrollpunkten.

Der traditionelle Weg wurde auf etwa 18 Arbeitstage geschätzt. Der agentenbasierte Weg erforderte acht Tage für Setup und Verfeinerung und anschließend ein bis zwei Tage für die Ausführung nach der Stabilisierung. Inklusive Setup entsprach das fast einer Verdopplung der Geschwindigkeit.

Rechnet man das wiederverwendbare Setup heraus, war die reine Ausführung mehr als zehnmal so schnell. Noch interessanter war jedoch, womit der Senior Engineer seine Zeit verbrachte: weniger mit repetitiver Implementierung, mehr mit der Gestaltung des Systems um die Arbeit herum. Bessere Planungs-Prompts, sauberere Leitplanken, stärkere Observability, präzisere Pull Requests.

Genau das ist der Wechsel von KI-gestütztem Programmieren hin zu Agentic Engineering Delivery.

In solchen Diskussionen wird oft übersehen, dass Agentic Software Delivery zwei völlig unterschiedliche Arten von Arbeit beinhaltet.

• Die erste ist das Engineering des Delivery-Systems selbst. Das bedeutet das wiederverwendbare Setup: Standards, Prompts, Workflows, Leitplanken, Review-Punkte und die Tools, die das Ganze reproduzierbar machen.
• Die zweite Aufgabe ist die Nutzung dieses Systems, um ein tatsächliches Feature oder eine Änderung auszuliefern.

Die erste Aufgabe ist diejenige, die sich immer wieder auszahlt. Baut man das System einmalig richtig auf, wird jedes nachfolgende Feature schneller und sauberer ausgeliefert.

Vermengt man diese beiden Aspekte, wird die Diskussion schnell unscharf. Trennt man sie jedoch, ergibt das Modell absolut Sinn.

Anstatt nur zu fragen „Wie liefern wir dieses Feature aus?“, fragt man auch: „Wie sieht das System aus, das es uns ermöglicht, solche Features immer wieder in hoher Qualität auszuliefern?“ Genau hier wird die Planung zur zentralen Steuerungsebene.

In einem agentenbasierten Workflow passiert die wichtigste Arbeit, bevor überhaupt eine Zeile Code geschrieben wird.

Der Agent sollte einen Implementierungsplan erstellen, der die zu ändernden Dateien, die hinzuzufügenden Tests, die architektonischen Auswirkungen und den geplanten Lösungsansatz abdeckt.

Dieser Plan wird geprüft und verfeinert, bevor er ausgeführt wird. Ohne Planung kann KI-gestütztes Programmieren schnell zu einer reaktiven Endlosschleife werden: Man fragt etwas an, prüft das Ergebnis, korrigiert das Tool und wiederholt das Ganze, bis es irgendwann funktioniert.

Mit Planung treten Unklarheiten früher zutage, Missverständnisse lassen sich leichter beheben und das Review findet vor der Implementierung statt – nicht erst, wenn der Schaden bereits in der Git-Historie angerichtet ist.

Ist das Ticket vage, wird auch das Ergebnis vage sein. Ist das Designsystem inkonsistent, wird auch die Komponente inkonsistent sein. Deshalb ist die klare Definition von Absichten und Erwartungen für Agentic Software Delivery so entscheidend.

Ein nützlicher agentenbasierter Workflow benötigt klare Spezifikationen, strukturierte Akzeptanzkriterien, plattformspezifische Standards, Disziplin im Designsystem, maschinenlesbare Dokumentation und explizite Quality Gates.

Das Briefing sollte nicht lauten:

Baue die Checkout-Komponente.

Es sollte lauten:

Baue die Checkout-Komponente unter Verwendung freigegebener Designsystem-Komponenten. Ziehe die Texte aus dem CMS. Behalte bestehende Analytics-Events bei. Befolge die Barrierefreiheits-Richtlinien für Tastaturnavigation und Fehlerstatus. Bleibe innerhalb des Performance-Budgets. Führe ohne Genehmigung keine neuen Abhängigkeiten ein. Generiere Tests für den Happy Path, Validierungsfehler und fehlgeschlagene Zahlungen. Markiere alles, was ein menschliches Review erfordert.

Mit diesem Detailgrad an Anweisungen verwandeln Teams KI von einem schnellen Code-Generator in ein zuverlässiges Delivery-System.

Geschwindigkeit ohne Qualität führt zu Nacharbeit. Qualität ohne Geschwindigkeit ist das alte Delivery-Modell (zu langsam für das Veränderungstempo, das die meisten Unternehmen heute erwarten).

Agentic Engineering funktioniert nur, wenn Qualitätskontrollen fest im Workflow verankert sind.

Das Ziel ist nicht, der theoretischen Höchstgeschwindigkeit von KI nachzujagen. Eine rücksichtslose 25-fache Leistungssteigerung bringt nichts, wenn sie Instabilität erzeugt. Eine steuerbare 10-fache Steigerung ist weitaus wertvoller, wenn sie Qualität, Wartbarkeit und Vertrauen bewahrt.

Agenten können Kontext sammeln, Code generieren, Tests schreiben, Integrationen validieren, Dokumentationen aktualisieren und Fehlerbehebungen vorschlagen.

Aber Entwickler:innen und Solution Architects treffen weiterhin die Entscheidungen, die sich auf Architektur, Sicherheit, Release-Readiness und Produktionsergebnisse auswirken.

• Ein Agent kann ein Migrationsskript erstellen. Er sollte den Migrationsplan nicht genehmigen.
• Ein Agent kann ein Performance-Problem aufzeigen. Er sollte keine Caching-Strategie ohne Review ändern.
• Ein Agent kann eine A/B-Testvariante erstellen. Er sollte nicht über den Gewinner entscheiden.

KI hat die Ausgangslage verändert. Es ist heute viel einfacher, Software zu entwickeln.

Aber Enterprise Technologie braucht mehr als nur Geschwindigkeit.

Sie erfordert Kontext, Rahmenbedingungen, Verifizierung, Observability, Governance und klare Verantwortlichkeiten. Bei Agentic Engineering geht es nicht darum, Entwickler zu ersetzen oder einfach nur mehr Code um des Codes willen zu produzieren.

Es geht darum, ein Delivery-System aufzubauen, das mehr Veränderungen bewältigen kann, ohne an Qualität oder Kontrolle einzubüßen. Unternehmen brauchen keinen schnelleren Code. Sie brauchen eine besser gesteuerte Delivery – von der Idee bis in die Produktion.