In den meisten Diskussionen über KI im Engineering geht es um Tools: welchen Coding-Assistenten man einführt, wie man die Testgenerierung automatisiert oder wie Dokumentationsunterstützung in der Praxis aussieht. Produktentscheidungen bekommen dabei die Aufmerksamkeit, strukturelle Entscheidungen nicht.
Das schafft ein geschäftliches Problem. Viele Unternehmen investieren in KI, lassen das Betriebsmodell aber unverändert: Entwickler arbeiten vielleicht individuell schneller, doch das Unternehmen zahlt weiterhin für dieselben Übergaben, dieselben Abstimmungsschleifen, dieselben Freigabeverzögerungen und dieselbe unklare Verantwortung. McKinsey hat festgestellt, dass der regelmässige Einsatz von KI mittlerweile weit verbreitet ist: 88 % der Unternehmen setzen KI in mindestens einer Geschäftsfunktion ein, doch nur 39 % berichten von einer Auswirkung auf das EBIT auf Unternehmensebene. Das zeigt anschaulich die Lücke zwischen Einführung und Wertschöpfung.
Was verursacht diese Kluft? Der eigentliche Wandel betrifft nicht die Tools, sondern die Art, wie Arbeit organisiert ist. Wenn KI von der Unterstützung zur Ausführung übergeht, verändern sich Teamgrösse, Verantwortungsgrenzen, Kostenstrukturen und Liefertakt gemeinsam.
KI zu einer unveränderten Teamstruktur hinzuzufügen, bringt schrittweise Verbesserungen. Die Struktur zu verändern schafft einen anderen Business Case.
Für Engineering-Teams lautet die Frage oft, ob KI die Produktivität von Entwicklern steigern kann. Für Führungskräfte ist die bessere Frage, ob KI die Kosten und die Zeit senken kann, die nötig sind, um Produktentscheidungen in funktionierende Software umzusetzen.
Diese Unterscheidung ist wichtig. Eine 20-prozentige Verbesserung der individuellen Entwicklerproduktivität wird nicht automatisch zu einer 20-prozentigen Verbesserung der Produktbereitstellung. Wenn Arbeit weiterhin auf funktionale Übergaben, Sprint-Abhängigkeiten, Review-Warteschlangen oder unklare Verantwortlichkeiten wartet, wird der Gewinn vom System aufgezehrt.
Die Kosten dieses Systems sind bereits erheblich. Atlassians Untersuchung zur Developer Experience ergab, dass 69 % der Entwickler jede Woche acht Stunden oder mehr durch Ineffizienzen verlieren. Das entspricht etwa einem Arbeitstag, also einem Fünftel ihrer Zeit, die für Reibungsverluste statt für Produktfortschritt aufgewendet wird.
Hier beginnt der Business Case. Der Wert von Agentic Engineering liegt nicht einfach darin, dass Engineers schneller Code schreiben. Er liegt darin, dass der Weg von der Produktidee zur Validierung in Produktion kürzer wird.
Das wirkt sich auf mehrere geschäftliche Kennzahlen aus:
Es geht nicht darum, fachliches Urteilsvermögen von Engineers zu ersetzen. Es geht darum, teure menschliche Kapazität nicht mehr für Arbeit einzusetzen, die eine Agentenebene unter menschlicher Aufsicht ausführen, prüfen und wiederholen kann.
Jeff Bezos führte die Zwei-Pizza-Regel bei Amazon ein, als das Unternehmen herausfinden musste, wie es beim Wachstum Geschwindigkeit und Verantwortlichkeit bewahren konnte. Das Prinzip war einfach: Teams sollten klein genug bleiben, um die Kommunikations- und Entscheidungskosten zu vermeiden, die mit steigender Mitarbeiterzahl zunehmen. In der Praxis bedeutete das meist autonome Gruppen von etwa fünf bis zehn Personen, also so viele, wie sich von zwei Pizzen satt essen können.
Die Teamgrösse war nur ein Teil der Idee. Zwei-Pizza-Teams erhielten die Verantwortung für ein definiertes Produkt oder einen definierten Service, wobei die nötigen Fähigkeiten, um es zu bauen, zu betreiben und zu verbessern, direkt in der Gruppe vorhanden waren. Statt Arbeit zwischen separaten Entwicklungs-, Test- und Betriebsabteilungen weiterzureichen, konnte das Team eine Aufgabe von Anfang bis Ende verantworten. Das passte gut zur allgemeinen Richtung der agilen und DevOps-Transformation: kleinere Teams, kürzere Feedbackschleifen und Verantwortung, die näher am Kunden liegt.
Das war eine deutliche Verbesserung gegenüber traditionellen Projektstrukturen. Frontend- und Backend-Engineering, QA, Betrieb und Produktsteuerung in einem Team zu bündeln, reduzierte die Abhängigkeit von zentralen Funktionen. Entscheidungen konnten näher an der eigentlichen Arbeit getroffen werden, und Teams konnten releasen und lernen, ohne jede Änderung über eine grosse Organisation hinweg abstimmen zu müssen.
Das Modell blieb jedoch davon abhängig, dass mehrere Spezialisten zusammenarbeiteten, um einen Produktbereich voranzubringen. Arbeit wurde weiterhin zwischen Rollen innerhalb des Teams weitergereicht, auch wenn sie nicht mehr zwischen Abteilungen wanderte. Frontend-Entwicklung, Backend-Entwicklung, Testing, Infrastruktur und Produktmanagement blieben getrennte Verantwortungsbereiche.
Diese interne Arbeitsteilung setzte eine Grenze dafür, wie klein und schnell das Team werden konnte. Jede zusätzliche Spezialisierung brachte eine weitere Abhängigkeit mit sich, während die Verantwortung für das Endergebnis über die gesamte Gruppe verteilt blieb. Verlangsamte sich die Lieferung, konnte die Ursache überall in einer Kette aus Entscheidungen, Reviews und Übergaben liegen.
Rund zwei Jahrzehnte lang bot das Zwei-Pizza-Team eine praktische Antwort auf die Koordinationsprobleme grösserer, funktional getrennter Organisationen. Agentic Engineering verändert nun die zugrunde liegende Ökonomie dieser Antwort. Wenn KI einen grösseren Teil der Ausführungsarbeit in Coding, Testing, Dokumentation und Infrastruktur übernehmen kann, braucht ein Produkt nicht mehr dieselbe Anzahl an Spezialisten, um voranzukommen.
Der nächste Schritt ist deshalb nicht einfach ein produktiveres Zwei-Pizza-Team, sondern ein kleineres Team mit breiterer Produktverantwortung.
Das Zwei-Pizza-Modell beruhte auf einer Annahme: Ausführung erforderte mehrere spezialisierte Rollen. Ein einzelner Engineer konnte nicht gleichzeitig den gesamten Stack verantworten, die Tests schreiben, die Infrastruktur betreuen und die Dokumentation aktuell halten. Spezialisierung existierte deshalb, weil Breite teuer war.
KI verändert diese Annahme. Code, Tests, Dokumentation, Refactoring und Workflow-Gerüste lassen sich parallel generieren. Sich wiederholende Engineering-Arbeit, die früher eigene Stellen erforderte, kann automatisiert werden. Die Kosten für den Wechsel zwischen Domänen sinken für Engineers, die eher steuern als jede Zeile manuell zu schreiben.
Das verändert die Beschränkung auf spezifische Weise. Der Engpass ist nicht mehr die Ausführungskapazität, sondern die Qualität der Steuerung: die Fähigkeit, so präzise zu definieren, was gebaut werden soll, dass Agenten es ausführen können, das Ergebnis zu validieren und zu entscheiden, was ausgeliefert wird.
Deshalb hängt der Business Case von einer Veränderung des Betriebsmodells ab. Wird KI nur innerhalb der bestehenden Struktur eingesetzt, erledigt das Unternehmen Aufgaben schneller. Verändert KI Verantwortung und Lieferfluss, bewegt sich das Produkt schneller voran.
Wenn Ausführung nicht mehr die Beschränkung ist, ändert sich die Logik hinter der Teamgrösse. Was entsteht, ist keine kleinere Version des Zwei-Pizza-Teams, sondern ein anderes Modell mit einem anderen Namen: das Ein-Pizza-Team.
Zwei bis drei Produktentwickler ersetzen ein sechs- bis achtköpfiges, funktional aufgebautes Team. Jeder Produktentwickler verantwortet eine vollständige Wertschöpfungskette statt eines funktionalen Ausschnitts, und eine Agentenebene übernimmt die Ausführung: Codegenerierung, Testerstellung, Refactoring, Dokumentation und Workflow-Gerüste.
KI-native Produktentwickler nutzen Agenten nicht nur. Sie orchestrieren sie.
Der strukturelle Unterschied zeigt sich darin, wie Wert geliefert wird. Im Zwei-Pizza-Modell ist die Wertlieferung kollektiv und diffus, wobei die Verantwortung über Funktionen verteilt ist. Im Ein-Pizza-Modell ist die Wertlieferung individuell und nachvollziehbar, wobei jeder Produktentwickler für die Lieferung verantwortlich ist statt für die Erledigung einer Aufgabe innerhalb einer Kette.
Für das Unternehmen entsteht dadurch eine andere Masseinheit. Statt zu fragen, wie viele Entwickler einem Produktbereich zugewiesen sind, können Führungskräfte fragen, wie viel validierte Produktbewegung jeder Produktentwickler mit Unterstützung einer Agentenebene erzeugen kann. Das ist ein nützlicheres Erfolgsmass, weil es Engineering-Kapazität mit geschäftlichem Durchsatz verknüpft.
Der Ertrag von Agentic Engineering entsteht aus mehreren Effekten, die sich verstärken, sobald sich das Betriebsmodell ändert:
Das ist der massgebliche Business Case. Agentic Engineering sollte daran gemessen werden, ob dieselbe Investition mehr validierte Produktbewegung erzeugt, nicht allein an der Tool-Nutzung.
Je mehr Ausführungsarbeit Agenten übernehmen, desto stärker verschiebt sich die Herausforderung von der Codeerstellung hin zur Kontrolle darüber, wie diese Arbeit ausgeführt wird. Unternehmen müssen wissen, was Agenten tun dürfen, auf welche Systeme und Daten sie zugreifen können, wie ihre Ergebnisse überprüft werden und wer für das Resultat verantwortlich bleibt.
Das erfordert ein Governance-Modell, das speziell für Agentic Engineering entwickelt wurde. Unternehmen brauchen mindestens klare Kontrollen für Agentenberechtigungen, Datenzugriff, Modellauswahl, Testing, menschliche Freigaben, Monitoring und Auditierbarkeit. Diese Kontrollen sollten fest in den Lieferprozess eingebettet sein, statt erst nachträglich hinzugefügt zu werden, nachdem Agenten bereits im Einsatz sind.
Ohne diese Grundlage können Agenten Umfang und Geschwindigkeit des Outputs steigern und gleichzeitig Sicherheits-, Qualitäts- und Compliance-Risiken erhöhen. Es kann mehr Code entstehen, aber auch Fehler, uneinheitliche Standards und Fehler in der Geschäftslogik können sich schneller durch das Liefersystem bewegen.
Eine Agentic-Engineering-Plattform hilft dabei, indem sie eine kontrollierte Umgebung bereitstellt, in der Agenten konfiguriert, überwacht und verbessert werden können. Sie gibt Engineering-Verantwortlichen einen einheitlichen Weg, Zugriffe zu verwalten, Sicherheitsrichtlinien anzuwenden, die Output-Qualität zu bewerten und die Übersicht über parallele Agenten-Workflows zu behalten.
Auch die Rolle des Engineers verändert sich dadurch. Engineers erledigen nicht mehr jede Implementierungsaufgabe selbst, sondern definieren den Umfang, beaufsichtigen die Ausführung, überprüfen kritische Ergebnisse und entscheiden, was auslieferungsreif ist. Je stärker die Agentenebene wird, desto wichtiger werden diese Kontrollen und Verantwortlichkeiten.
Das Ziel ist nicht, Agenten einfach mehr tun zu lassen. Es geht darum, ein Liefersystem zu schaffen, in dem sie mit hoher Geschwindigkeit arbeiten können, ohne Sicherheit, Qualität oder Verantwortlichkeit zu schwächen.
Die Anziehungskraft der ersten Phasen ist klar erkennbar. In einer kontrollierten Studie von Microsoft und GitHub erledigten Entwickler, die GitHub Copilot nutzten, eine Programmieraufgabe 55,8 % schneller als jene ohne. Für die Ausführung einzelner Aufgaben kann der Gewinn erheblich sein.
Aber Aufgabengeschwindigkeit ist nicht dasselbe wie Liefergeschwindigkeit. Ein schnellerer Entwickler arbeitet weiterhin im selben Produktsystem. Wartet die Arbeit anschliessend auf Review, QA, Infrastrukturunterstützung, Produktklärung oder Release-Koordination, geht ein Grossteil des individuellen Gewinns verloren, bevor er den Kunden erreicht.
Deshalb sollte man die KI-Einführung als Reifekurve verstehen, nicht als Tool-Rollout. Nicht jedes Unternehmen, das KI einführt, erreicht dieses Modell, und die Ergebnisse hängen davon ab, wie weit die Einführung geht und ob sich das Betriebsmodell mitverändert. Es gibt eine klare Entwicklung, die sich in zwei grundlegend unterschiedliche Kategorien aufteilt.
Der Sprung von chatbasiert zu agentenbasiert ist der Punkt, an dem sich das Modell verändert. Chatbasierte Einführung verbessert die individuelle Produktivität innerhalb der bestehenden Struktur. Agentenbasierte Einführung verändert, was die Struktur ist.
Die meisten Unternehmen stossen an eine Effizienzgrenze, weil sie bei den chatbasierten Phasen stehen bleiben. Die Tools verbessern sich, aber das Betriebsmodell bleibt gleich. Das Unternehmen sieht dann teilweise Gewinne, während der grössere Investment Case unrealisiert bleibt.
Das Muster bei Unternehmen mit begrenzten Gewinnen ist immer gleich: KI wird zu bestehenden Workflows hinzugefügt, während Teamstrukturen, Rollen und funktionale Silos unverändert bleiben.
Einzelne Engineers erledigen Aufgaben vielleicht schneller, und der Gesamtoutput des Teams verbessert sich möglicherweise. Doch derselbe Koordinationsaufwand bleibt bestehen. Arbeit durchläuft weiterhin Übergaben, Review-Warteschlangen und getrennte Verantwortungsbereiche, bevor sie in Produktion geht.
Deshalb tun sich viele KI-Programme schwer, einen klaren geschäftlichen Ertrag nachzuweisen. Unternehmen messen Tool-Einführung oder individuelle Produktivität, verändern aber nicht das Liefermodell, das bestimmt, wie schnell Arbeit von der Idee zur Produktion gelangt.
Um die grösseren Effizienzgewinne von Agentic Engineering zu erschliessen, braucht es mehr, als Engineers bessere Tools zu geben. Es bedeutet, Teams um Produktentwickler mit breiterer Verantwortung herum neu zu gestalten, Agenten in den Lieferprozess einzubetten und die umgebenden Workflows, Kontrollen und Erfolgsmasse anzupassen.
Ohne diese strukturellen Veränderungen kann KI einzelne Aufgaben beschleunigen, ohne die Kosten oder die Geschwindigkeit der Produktlieferung wesentlich zu verändern.
Um diese Grenze zu überwinden, sind bewusste Entscheidungen über die Struktur nötig, nicht zusätzliche Technologieinvestitionen.
Das deckt sich damit, was leistungsstarke KI-Unternehmen anders machen. McKinseys AI-Survey 2025 ergab, dass KI-Spitzenreiter fast dreimal so wahrscheinlich Workflows grundlegend neu gestalten wie andere Unternehmen. Mit anderen Worten: Die Unternehmen, die Wert schaffen, fügen KI nicht nur zu bestehenden Prozessen hinzu. Sie verändern die Prozesse selbst.
Verantwortung muss von rollenbasierten Aufgaben zu Verantwortung für die gesamte Wertschöpfungskette wechseln. Ein Backend-Engineer, der für seine Tickets verantwortlich ist, ist nicht dasselbe wie ein Produktentwickler, der dafür verantwortlich ist, dass ein Feature ausgeliefert wird und korrekt funktioniert. Der Umfang ist anders, die Messung ist anders, und die Anreize sind anders.
Die Teamstruktur muss funktionale Abhängigkeiten reduzieren, nicht nur die Teamgrösse. Ein Team von acht auf fünf Personen zu verkleinern, während dieselben funktionalen Rollen bestehen bleiben, erhält genau den Koordinationsaufwand, der das ursprüngliche Modell eingeschränkt hat. Diese Rollen zu breiterer Verantwortung zusammenzuführen, ist die Veränderung, die wirklich zählt.
Die Agentenebene muss fester Bestandteil der Lieferung sein, kein optionales Werkzeug, das im Ermessen des einzelnen Engineers liegt. Unternehmen, die Orchestrierung als persönliche Vorliebe von Entwicklern statt als Lieferfähigkeit behandeln, werden den strukturellen Vorteil nicht sehen.
Die Messung muss folgen. Liefergeschwindigkeit pro Produktentwickler, Iterationszykluszeit, Kosten pro ausgeliefertem Feature, Nacharbeitsrate, unentdeckte Fehler in Produktion und die Zeit von der Idee bis zur Produktion sind relevantere Signale als Story Points oder Codezeilen. Traditionelle Engineering-Kennzahlen setzen einen linearen Zusammenhang zwischen Mitarbeiterzahl und Output voraus. Agentic Delivery tut das nicht.
Wenn sich das Betriebsmodell zusammen mit der Technologie verändert, sollten die Ergebnisse messbar sein. Die Teamgrösse pro Produktbereich kann sinken. Die Liefergeschwindigkeit pro Produktentwickler kann steigen. Iterationszyklen können sich verkürzen, sobald funktionale Abhängigkeiten wegfallen. Die Verantwortlichkeit wird klarer, weil die Zuständigkeit direkt ist.
Es gibt bereits Belege dafür, dass die grössten Gewinne von Unternehmen kommen, die das Entwicklungsmodell verändern, nicht nur die Tools. McKinseys Analyse von fast 300 börsennotierten Unternehmen ergab, dass Spitzenreiter Verbesserungen von 16 bis 30 % bei Produktivität, Time-to-Market und Kundenerfahrung erzielen, zusammen mit Qualitätsgewinnen von 31 bis 45 % bei der Software. Das gemeinsame Muster ist nicht einfache Tool-Einführung. Es ist eine tiefere KI-Integration über den gesamten Software-Lebenszyklus hinweg, unterstützt durch Veränderungen bei Rollen, Workflows und Messung.
Die stärkste Aussage ist nicht, dass jedes Unternehmen denselben prozentualen Gewinn erzielen wird. Das stärkere geschäftliche Argument ist, dass sich die Ökonomie der Lieferung verändert. Produktivität ist nicht mehr linear zur Teamgrösse. Kapazität ist nicht mehr allein eine Einstellungsfrage. KI-Investitionen rechtfertigen sich nicht mehr durch individuelle Entwickler-Adoption, sondern dadurch, ob das Liefersystem Agenten-Ausführung in schnellere, sicherere Produktbewegung umsetzen kann.
Das ist der praktische Unterschied zwischen KI als Werkzeug und KI als Teil der Lieferstruktur.
Dieser Wandel geschieht nicht durch die Einführung der richtigen Tools. Er erfordert bewusste organisatorische Entscheidungen, die über dem Technologie-Stack liegen.
Führungskräfte müssen neu definieren, was ein Team ist. Das Zwei-Pizza-Modell war zwei Jahrzehnte lang eine nützliche Faustregel der agilen Transformation, als die Softwarelieferung noch von mehreren Spezialisten abhing, die innerhalb eines autonomen Teams zusammenarbeiteten. Agentic Engineering verändert diese Rechnung, indem es Produktentwicklern erlaubt, die Ausführung über Coding, Testing, Dokumentation und Infrastruktur hinweg mit Unterstützung einer Agentenebene zu steuern.
Das Anforderungsprofil eines Produktentwicklers, der Agenten-Workflows orchestriert und eine vollständige Wertschöpfungskette verantwortet, unterscheidet sich deshalb von dem eines Spezialisten, der eine funktionale Domäne verantwortet. Beide bleiben wertvoll, dienen aber unterschiedlichen Liefermodellen und sind nicht austauschbar.
Führungskräfte müssen Orchestrierungsfähigkeit zudem als Infrastruktur behandeln, nicht als persönliche Weiterbildung. Das bedeutet, in eine Agentic-Engineering-Plattform zu investieren, die einen einheitlichen Weg bietet, um den Umfang von Agenten zu definieren, den Zugriff auf Systeme und Daten zu kontrollieren, Sicherheitsrichtlinien durchzusetzen, Aktivitäten zu überwachen und Ergebnisse zu prüfen, bevor sie in Produktion gehen.
Ohne diese gemeinsame Grundlage bleibt Orchestrierung von individuellen Arbeitsweisen abhängig und lässt sich im grossen Massstab nur schwer steuern. Mit ihr können Unternehmen einheitliche Standards für Sicherheit, Qualität und Verantwortlichkeit über Teams hinweg anwenden und Produktentwicklern gleichzeitig die Freiheit geben, Agenten-Workflows wirksam zu steuern.
Das Ziel ist nicht, mehr KI einzusetzen. Es ist, ein Liefersystem aufzubauen, in dem Agenten wirksam arbeiten können und Produktentwickler diese Ausführung präzise steuern können. Unternehmen, die diesen Wandel vollziehen, können Koordinationskosten senken, Produktzyklen verkürzen und knappe Engineering-Kapazität besser nutzen.
Wer Agentic Engineering als reine Tool-Entscheidung behandelt, erhält schnellere Ausführung. Wer das Liefermodell darum herum neu gestaltet, verändert die Ökonomie der Softwareentwicklung.