{"id":4450681,"date":"2026-06-09T10:40:12","date_gmt":"2026-06-09T08:40:12","guid":{"rendered":"https:\/\/www.deptagency.com\/insight\/ai-can-write-code-enterprise-delivery-is-harder\/"},"modified":"2026-07-10T17:24:32","modified_gmt":"2026-07-10T15:24:32","slug":"ki-kann-code-schreiben-enterprise-implementierung-ist-schwieriger","status":"publish","type":"article","link":"https:\/\/www.deptagency.com\/de-dach\/insight\/ki-kann-code-schreiben-enterprise-implementierung-ist-schwieriger\/","title":{"rendered":"KI kann Code schreiben. Die Enterprise Implementierung ist schwieriger."},"content":{"rendered":"
\n\t\n\t\t\n\t\t\t<\/mask><\/g><\/svg>\t\t\t\n\t\t\t\tArtikel\t\t\t<\/span>\n\t\t<\/div>\n\t<\/div>\n\tKI kann Code schreiben. Die Enterprise Implementierung ist schwieriger.<\/h1>
\n\t\t\t\n\t\n\t
\n\t\tJonathan Whiteside\t\t
\n\t\tGlobal EVP Technology\n\t\t\t<\/div>\n<\/div>\n\t
\n\t\t\t\t\t
\n\t\t\t\t\n\t\t\t\t\tDatum\t\t\t\t<\/span>\n\t\t\t\t\n\t\t\t\t\tJune 9, 2026\t\t\t\t<\/span>\n\t\t\t<\/div>\n\t\t\t<\/div>\n\n\t\n<\/div>\n\n\n\tKI hat die Softwareentwicklung deutlich vereinfacht.<\/h2>\n\tProduktmanager:innen k\u00f6nnen eine Benutzeroberfl\u00e4che beschreiben und erhalten einen Prototyp. Entwickler:innen k\u00f6nnen ein Feature in Minuten aufsetzen. Gr\u00fcnder:innen k\u00f6nnen aus einer Idee eine Demo machen, bevor \u00fcberhaupt 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\u00fcllen. Sich in bestehende \u00d6kosysteme integrieren. Kundendaten sicher verarbeiten. Anforderungen an Informationssicherheit, Barrierefreiheit, Performance, Analytics, Lokalisierung, Testing, Dokumentation und Release-Readiness erf\u00fcllen.

Sie muss f\u00fcr das n\u00e4chste Team, das daran arbeitet, wartbar sein. Und genau hier st\u00f6\u00dft reines \u201eVibe Coding\u201c an seine Grenzen. Das Problem ist nicht, dass KI schlechten Code schreibt. Oft sieht der Code sogar \u00fcberraschend gut aus. Das Problem ist, dass \u201esieht gut aus\u201c und \u201eproduktionsreif\u201c zwei verschiedene Dinge sind.

Die Frage, ob KI Code schreiben kann, haben wir l\u00e4ngst hinter uns. Sie kann es.<\/strong>

Die weitaus wichtigere Frage ist, ob ein Team diese F\u00e4higkeit in ein Delivery-Modell verwandeln kann, das im Enterprise-Umfeld funktioniert und nachhaltigen Mehrwert schafft.<\/p><\/div>\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t<\/div>\n\n\t\t\t\n\t<\/div>\n\n\n\tEs geht nicht wirklich um Agentic Engineering. Es geht um Agentic Software Delivery.<\/h2>\n\tDie Branche hat sich auf einen Begriff geeinigt: Agentic Engineering. Doch dieser Name greift zu kurz. \u201eEngineering\u201c fokussiert sich auf den Code \u2013 aber der Code war nie das Schwierigste. Das Schwierige ist alles drumherum: die Architektur, die Integration, die Sicherheit, der Weg in die Produktion.

W\u00e4hrend 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 \u00fcber den gesamten Software-Lebenszyklus hinweg arbeiten, w\u00e4hrend Ingenieure und Architekten sie anleiten, ihre Ergebnisse pr\u00fcfen und die wirklich wichtigen Entscheidungen treffen.

Das ist etwas v\u00f6llig 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\u00fctzt, mit mehr Klarheit, mehr Konsistenz und weniger Nacharbeit voranzukommen. K\u00fcrzlich haben wir einen A\/B-Test durchgef\u00fchrt, bei dem f\u00fcnf Tickets f\u00fcr Architekturverbesserungen an derselben Codebasis zugewiesen wurden.<\/p>\n\n\t
  • Der eine Weg wurde manuell von einem Principal Engineer umgesetzt.<\/li>
  • Der andere nutzte einen strukturierten agentenbasierten Workflow mit menschlichen Reviews an definierten Kontrollpunkten.<\/li><\/ul>\n\nDer traditionelle Weg wurde auf etwa 18 Arbeitstage gesch\u00e4tzt. Der agentenbasierte Weg erforderte acht Tage f\u00fcr Setup und Verfeinerung und anschlie\u00dfend ein bis zwei Tage f\u00fcr die Ausf\u00fchrung nach der Stabilisierung. Inklusive Setup entsprach das fast einer Verdopplung der Geschwindigkeit.

    Rechnet man das wiederverwendbare Setup heraus, war die reine Ausf\u00fchrung 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\u00e4rkere Observability, pr\u00e4zisere Pull Requests.

    Genau das ist der Wechsel von KI-gest\u00fctztem Programmieren hin zu Agentic Engineering Delivery.<\/p>\n<\/div>\n\t\n\t<\/div>\n\n\n\tEs gibt hier zwei Aufgaben<\/h2>\n\tIn solchen Diskussionen wird oft \u00fcbersehen, dass Agentic Software Delivery zwei v\u00f6llig unterschiedliche Arten von Arbeit beinhaltet.<\/p>\n\n\t
  • 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.<\/li>
  • Die zweite Aufgabe ist die Nutzung dieses Systems, um ein tats\u00e4chliches Feature oder eine \u00c4nderung auszuliefern.<\/li><\/ul>\n\nDie 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 \u201eWie liefern wir dieses Feature aus?\u201c, fragt man auch: \u201eWie sieht das System aus, das es uns erm\u00f6glicht, solche Features immer wieder in hoher Qualit\u00e4t auszuliefern?\u201c Genau hier wird die Planung zur zentralen Steuerungsebene.<\/p>\n<\/div>\n\t\n\t<\/div>\n\n\n\tPlanung ist die zentrale Steuerungsebene<\/h2>\n\tIn einem agentenbasierten Workflow passiert die wichtigste Arbeit, bevor \u00fcberhaupt eine Zeile Code geschrieben wird.

    Der Agent sollte einen Implementierungsplan erstellen, der die zu \u00e4ndernden Dateien, die hinzuzuf\u00fcgenden Tests, die architektonischen Auswirkungen und den geplanten L\u00f6sungsansatz abdeckt.

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

    Mit Planung treten Unklarheiten fr\u00fcher zutage, Missverst\u00e4ndnisse lassen sich leichter beheben und das Review findet vor der Implementierung statt \u2013 nicht erst, wenn der Schaden bereits in der Git-Historie angerichtet ist.<\/p><\/div>\n\t\n\t<\/div>\n\n\n\tBessere Inputs liefern bessere Outputs<\/h2>\n\tIst 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\u00fcr Agentic Software Delivery so entscheidend.

    Ein n\u00fctzlicher agentenbasierter Workflow ben\u00f6tigt klare Spezifikationen, strukturierte Akzeptanzkriterien, plattformspezifische Standards, Disziplin im Designsystem, maschinenlesbare Dokumentation und explizite Quality Gates.

    Das Briefing sollte nicht lauten:<\/strong>

    Baue die Checkout-Komponente.<\/em>

    <\/em>Es sollte lauten:<\/strong>

    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\u00fcr Tastaturnavigation und Fehlerstatus. Bleibe innerhalb des Performance-Budgets. F\u00fchre ohne Genehmigung keine neuen Abh\u00e4ngigkeiten ein. Generiere Tests f\u00fcr den Happy Path, Validierungsfehler und fehlgeschlagene Zahlungen. Markiere alles, was ein menschliches Review erfordert.
    <\/em>
    Mit diesem Detailgrad an Anweisungen verwandeln Teams KI von einem schnellen Code-Generator in ein zuverl\u00e4ssiges Delivery-System.
    <\/p><\/div>\n\t\n\t<\/div>\n\n\n\tQualit\u00e4t muss Teil des Workflows sein<\/h2>\n\tGeschwindigkeit ohne Qualit\u00e4t f\u00fchrt zu Nacharbeit. Qualit\u00e4t ohne Geschwindigkeit ist das alte Delivery-Modell (zu langsam f\u00fcr das Ver\u00e4nderungstempo, das die meisten Unternehmen heute erwarten).

    Agentic Engineering funktioniert nur, wenn Qualit\u00e4tskontrollen fest im Workflow verankert sind.

    Das Ziel ist nicht, der theoretischen H\u00f6chstgeschwindigkeit von KI nachzujagen. Eine r\u00fccksichtslose 25-fache Leistungssteigerung bringt nichts, wenn sie Instabilit\u00e4t erzeugt. Eine steuerbare 10-fache Steigerung ist weitaus wertvoller, wenn sie Qualit\u00e4t, Wartbarkeit und Vertrauen bewahrt.<\/p><\/div>\n\t\n\t<\/div>\n\n\n\tMenschen behalten die Verantwortung<\/h2>\n\tAgenten k\u00f6nnen 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.<\/p>\n\n\t
  • Ein Agent kann ein Migrationsskript erstellen. Er sollte den Migrationsplan nicht genehmigen.<\/li>
  • Ein Agent kann ein Performance-Problem aufzeigen. Er sollte keine Caching-Strategie ohne Review \u00e4ndern.<\/li>
  • Ein Agent kann eine A\/B-Testvariante erstellen. Er sollte nicht \u00fcber den Gewinner entscheiden.<\/li><\/ul>\n<\/div>\n\t\n\t<\/div>\n\n\n\tVom schnelleren Programmieren zur gesteuerten Delivery<\/h2>\n\tKI hat die Ausgangslage ver\u00e4ndert. Es ist heute viel einfacher, Software zu entwickeln.

    Aber Enterprise Technologie<\/a> 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\u00e4nderungen bew\u00e4ltigen kann, ohne an Qualit\u00e4t oder Kontrolle einzub\u00fc\u00dfen. Unternehmen brauchen keinen schnelleren Code. Sie brauchen eine besser gesteuerte Delivery \u2013 von der Idee bis in die Produktion.<\/p><\/div>\n\t\n\t<\/div>\n\n
    \n\tON OUR MIND<\/span><\/h2>\n\tALLE INSIGHTS ANSEHEN<\/a>\n\t\n\t\t\n\t\t\t
    \n\t\t\t\n\t\t\t\t\t\t\t\t\"\"\n\t\t\t<\/picture>\n\t\t\t\t\t<\/div>\n\t\n\t
    \n\t\t
    \n\t\t\t
    \n\t\t\t\t<\/svg>\t\t\t<\/div>\n\n\t\t\t\n\t\t\t\tInsight\t\t\t<\/span>\n\t\t<\/div>\n\n\t\t\t\t\t
      \n\t\t\t\t\n\t