Der Lackmustest: Warum Agentic AI nur dort liefert, wo Technologie, Prozess und Organisation zusammenpassen

Amazon, die 4,5× und der verteilte Monolith aus Agenten

Über Agentic AI gibt es derzeit zwei Lager. Das eine sagt: KI-Agenten schreiben den Code, die alten Teamstrukturen lösen sich auf, alles wird schneller. Das andere – traditionell unseres – sagt: Technologie allein hat noch nie etwas gelöst; wer ein neues Werkzeug einführt und Prozesse und Organisation unangetastet lässt, baut bestenfalls teures Theater.

Im ersten Beitrag dieser kleinen Serie – „Post-Agile: Human-AI Teaming" – haben wir die Mensch-Seite beleuchtet: wie sich Teams organisieren, wenn KI zum Teammitglied wird. In drei begleitenden Beiträgen vertiefen wir die übrigen Bausteine unserer Grundhaltung, der Triade aus Technologie, Prozess und Organisation: je einen zur Technologie, zur Organisation und zu den Abläufen. Auf den ersten Blick schien das techno-optimistische Post-Agile-Versprechen unserer eigenen Maxime „Technologie allein löst nichts" leicht zu widersprechen. Dieser Beitrag löst den scheinbaren Widerspruch auf – nicht mit einer Meinung, sondern mit dem derzeit besten verfügbaren Datenpunkt: dem, was Amazon gerade tatsächlich tut.

Den Organisations-Teil haben wir inzwischen ausgearbeitet: „Conway schlägt zurück: Warum KI kleine Teams zurückbringt – und wie Du sie schneidest". Die Beiträge zu Technologie und Abläufen folgen.

Die entscheidende Zahl vorweg. Teams bei Amazon, die ihre Arbeitsweise rund um KI umgebaut haben, sahen im Median eine 4,5-fache Produktivität, einzelne über 10-fach. Teams, die KI nur zu ihrer bestehenden Arbeitsweise dazugelegt haben, sahen diese Gewinne nicht. (1) Genau hier entscheidet sich alles – und genau hier treffen sich unsere beiden Artikel.

Die Triade ist kein Poster, sondern eine Bedingung

„Technologie, Prozess und Organisation müssen harmonieren" klingt nach Beraterfolklore – bis jemand es misst. Agentic AI ist der erste Fall, in dem der Unterschied brutal sichtbar wird, weil dasselbe Werkzeug bei der einen Gruppe explodiert und bei der anderen verpufft.

Amazon ist nicht allein mit diesem Befund. Microsofts Work Trend Index 2026 (20.000 Wissensarbeitende in 10 Märkten) führt rund 67 % der realen KI-Wirkung auf organisatorische Faktoren zurück – Kultur, Führungsunterstützung, Anreize, Performance-Bewertung – und nur etwa 32 % auf individuelle Fähigkeiten. (2) Microsoft nennt das die „Transformation Paradox": Dieselbe Kraft, die KI-Adoption beschleunigt, bremst sie aus, wenn die Organisation drumherum unverändert bleibt.

Das ist auch die Erklärung für ein Ergebnis, das im ersten unserer Artikel für Irritation sorgte: In einer kontrollierten Studie wurden erfahrene Entwickler mit KI-Tools 19 % langsamer – und merkten es nicht einmal. (3) Kein Widerspruch zu Amazon, sondern dieselbe Medaille: Dort wurde ein Tool auf einen unveränderten Prozess gesetzt. Genau das ist „Agile Theater" in neuer Verkleidung – und es ist die KI-Variante des verteilten Monolithen: Man verschiebt die Komplexität, statt sie zu lösen.

Schauen wir uns also an, was „den Prozess umbauen" bei Amazon konkret heißt – entlang der drei Dimensionen der Triade.

Organisation: zurück zum Zwei-Pizza-Team (Conway lässt grüßen)

Amazons Agentic-AI-Sparte unter AWS-VP Swami Sivasubramanian ist in Dutzende winzige Teams organisiert – viele klein genug, um sie mit zwei Pizzen satt zu bekommen. Das ist kein Retro-Gag, sondern eine bewusste Entscheidung: Projekte, die früher 30 bis 40 Leute brauchten, lassen sich laut Sivasubramanian heute von 6 bis 8 erledigen. (1)

Und ja, 6 bis 8 ist verdächtig genau die Größe eines vollwertigen Scrum-Teams. Kein Zufall: Die Obergrenze effektiver Teams kam noch nie aus der Baukapazität, sondern aus dem Koordinationsaufwand. Kommunikationswege wachsen quadratisch – sechs Leute haben 15, zwölf schon 66 (Brooks). (8) Ab rund zehn Personen verwaltet ein Team mehr, als es liefert (Hackman). (9) Genau deshalb gibt es die Zwei-Pizza-Regel.

Was KI ändert, ist nicht diese Obergrenze, sondern wie viel ein Team dieser Größe schafft. Die Zahl der Menschen pro Aufgabe sinkt gegen eins – ein Engineer baute ein Kiro-Feature, das auf vier Wochen geschätzt war, in anderthalb Tagen –, während der Auftrag des Teams (im Amazon-Jargon: der „Charter") wächst. Was dabei wegfällt, ist nicht das Team, sondern das Programm drumherum: die mehreren Teams plus Koordinationsebene, die man früher nur brauchte, um die schiere Arbeitsmenge auf viele Hände zu verteilen. Stemmt ein Zwei-Pizza-Team diese Menge allein, verschwindet der Grund für das ganze Programm-Gerüst.

Hier greift Conways Gesetz: Softwarestrukturen spiegeln die Kommunikationsstrukturen der Organisation. (4) Wenn KI die Bau-Geschwindigkeit verzehnfacht, wird ein 40-Personen-Abstimmungsapparat zum Flaschenhals – also passt Amazon die Organisation an die neue Geschwindigkeit an, statt nur Tools zu verteilen. Zwei Belege, wie sehr das den Output verändert:

• Amazon Quick (ein Workspace-/Such-Tool über E-Mail, Kalender, Slack & Co.): Ein Team von rund sechs Engineers. Nach sechs Wochen nutzten es 200 Leute intern, nach zehn Wochen 10.000; der Launch kam nach drei Monaten. (1)
• Die Inference-Engine für Amazon Bedrock: sechs Engineers in 76 Tagen – ursprünglich auf 30 Entwickler und 12 bis 18 Monate geschätzt. (1)

Selbst Amazons heiligstes Ritual fällt: Statt zuerst das berühmte sechsseitige „Working Backwards"-Dokument (PRFAQ) zu schreiben, baut man bei risikoarmen Wetten erst den funktionierenden Prototyp – das PRFAQ entsteht danach. (1) Der Prozess folgt der neuen Realität, nicht umgekehrt.

Prozess: Der Engpass ist die Spezifikation, nicht der Bau

Das wichtigste Zitat dieser ganzen Entwicklung stammt ebenfalls von Sivasubramanian: „The bottleneck is not about the time it takes to build something. The bottleneck is about crafting the right specification and the tests and the right product and customer experience." (1)

Das ist exakt der Punkt, den wir seit Jahren in Projekten predigen – nur jetzt mit einem KI-Brennglas. Amazons eigenes Werkzeug Kiro ist „spec-driven": Es erzwingt strukturierte Anforderungen, Architektur und Tests vor dem Code und schiebt das Testen an den Moment des Schreibens, damit der Agent seine eigene Arbeit prüfen kann. Erklärtes Ziel: „Vibe Coding" und „AI Slop" eindämmen. (5) Validierung ist hier kein Nachgedanke, sondern in den Prozess eingebaut.

Wie real dieser Engpass ist, zeigt eine Anekdote, die wir jedem Tool-Optimisten vorlesen würden: Sivasubramanian wollte nachts mit Jetlag eine 20 Jahre alte AWS-Infrastruktur per KI nachbauen – an der er einst vier Monate gearbeitet hatte. Vier Nächte lang scheiterte der Agent, er musste jeden Schritt babysitten. In der fünften Nacht verstand er das Problem: Er hatte dem Agenten keine Möglichkeit gegeben, sein eigenes Ergebnis zu testen. Mit der richtigen Spezifikation und einer Testumgebung war die Aufgabe in rund zwei Stunden erledigt. (1)

Technologie ohne Prozess: vier Nächte Frust. Technologie mit Prozess: zwei Stunden. Dieselbe KI, dieselbe Person.

Mensch: Wenn der Product Manager codet und der Engineer entscheidet

Die dritte Dimension verändert sich am unauffälligsten – und am tiefsten. In Sivasubramanians Teams schreiben Produktmanager Code, und Engineers treffen Produktentscheidungen; die erste Version eines Kosten-Dashboards für Kiro baute ein PM selbst, mit Kiro. (1) Die alten Rollengrenzen verschwimmen – aber nur, weil die Menschen die neue Verantwortung auch übernehmen.

Auch Führung muss sich neu kalibrieren. Sivasubramanian achtet selbst im Urlaub darauf, welche Entscheidungen wirklich seine Freigabe brauchen – beim aktuellen Tempo können vier, fünf Tage Verzögerung die Liefertermine eines Teams um bis zu 10 % strecken. (1) Und es entsteht eine neue Kostenstelle: KI-Token werden wie Betriebskosten getrackt. Noch sind die Beträge überschaubar, aber die Logik ist neu – Betriebskosten umfassen künftig nicht nur Köpfe, sondern auch die Agenten, die neben ihnen arbeiten. (1)

Der Mensch verschwindet also nicht. Er rückt an die Stelle, an der jetzt der Engpass sitzt: Spezifikation, Urteil, Verantwortung.

Wo der vermeintliche Widerspruch verschwindet

Jetzt lassen sich unsere beiden früheren Artikel sauber übereinanderlegen:

Das Post-Agile-Modell beschreibt das Ziel – Teams, die rund um KI neu arbeiten. Die Triade beschreibt die Bedingung – dass dieses Ziel nur erreicht, wer Technologie, Prozess und Organisation gemeinsam bewegt. Amazon ist der Beweis, dass beides dasselbe ist: Die 4,5× kamen nicht aus dem Tool, sondern aus dem Umbau. Wer nur das Tool kauft, bekommt die METR-Studie (Stillstand), nicht Amazon (4,5×).

Damit ist „KI ersetzt die Methode" genauso falsch wie „KI ist nur ein weiteres Tool". Richtig ist: Agentic AI ist der schärfste Lackmustest, den die Triade je hatte. Wo eine Organisation schon vorher gut darin war, Technologie, Prozess und Mensch zusammenzudenken, wirkt KI wie ein Verstärker. Wo sie es nicht war, legt KI die Schwäche nur schneller offen.

Wo steht Deine Organisation?

Ehrliche Standortbestimmung – diesmal nicht nach Tool-Reife, sondern nach Triaden-Reife:

Das Ziel ist nicht Level 4 über Nacht. Es ist, Level 1 zu verlassen – denn Level 1 ist der einzige, der garantiert kein Geld zurückbringt.

Chancen und Risiken – eine ehrliche Abwägung

Chancen

• Echter, messbarer Hebel: Dort, wo die Triade stimmt, sind 4,5× kein Marketing, sondern gemessen. (1) Das verändert, was ein kleines Team überhaupt anpacken kann.
• Rückkehr zu kleinen, verantwortlichen Teams: Das Zwei-Pizza-Prinzip wird wieder praktikabel – mit kürzeren Wegen und mehr Ownership.
• Differenzierung statt Commodity: Wer den Engpass „Spezifikation und Urteil" beherrscht, baut genau dort Vorsprung auf, wo Standardsoftware nie differenziert.

Risiken (ehrlich)

• Survivorship Bias: Amazon ist KI-nativ, hat Spitzenleute und baut die Tools selbst. Ein gewachsener Mittelständler ist nicht AWS – die Zahlen sind eine Richtung, kein Versprechen.
• Der verteilte Monolith aus Agenten: Tool ohne Umbau verschiebt Komplexität nur. Das Ergebnis ist nicht Tempo, sondern Stillstand mit höherer Cloud-Rechnung – belegt durch die Tool-only-Teams ohne Gewinn. (1)
• Zuverlässigkeit & „AI Slop": Nicht zufällig hat AWS einen eigenen Reliability-Push für Agenten gestartet und Spec-Checks in Kiro nachgerüstet. (5) Wer Validierung nicht einbaut, skaliert Fehler.
• Der menschliche Preis: Amazon hat seit Ende 2025 rund 30.000 Corporate-Stellen gestrichen; CEO Andy Jassy erwartet, dass KI die Belegschaft weiter schrumpft. (6) „Effizienz" hat hier ein Gesicht – das gehört in jede ehrliche Diskussion.

Monday Morning Actions: 3 Schritte für morgen früh

1. Der „Triaden-Test" für ein laufendes KI-Vorhaben (20 Min.): Nimm euer aktuelles KI-Projekt und frag drei Dinge: Haben wir nur das Tool geändert – oder auch Prozess (Freigaben, Reviews) und Organisation (Teamzuschnitt, Rollen)? Wo nur eine Dimension angefasst wurde, liegt euer Engpass.
2. Den Engpass verschieben: Wähle eine Aufgabe und schreibe – wie Amazon – zuerst die Spezifikation und die Tests, dann erst den (KI-)Bau. Miss, wie sich Ergebnisqualität und Nacharbeit verändern.
3. Eine Freigabe entschlacken: Finde den langsamsten Genehmigungsschritt (CAB, Sign-off, Ticket-Stau) und frag: Würde er ein Sechs-Personen-Team, das in Tagen liefert, ausbremsen? Wenn ja, ist er euer nächstes Transformationsobjekt – nicht die nächste Lizenz.

Offene Fragen und nächste Schritte

1. Wie überträgt sich „AI-nativ" auf gewachsene Organisationen? Amazons Zahlen stammen aus einer Sonderwelt. Nächster Schritt: In einem Bereich einen ehrlichen Vorher-Nachher-Vergleich aufsetzen – mit und ohne Prozessumbau.
2. Wie steuert man Agenten-Betriebskosten? Token als Opex ist neu. Nächster Schritt: Tracking etablieren, bevor die Rechnung es für dich tut.
3. Wie viel Autonomie bekommt ein Agent? Nächster Schritt: „Human-in-the-Loop" vs. „Human-on-the-Loop" je nach Kritikalität festlegen – Validierung in den Prozess gießen, nicht in den guten Willen.

Fazit: Kauf kein Tool, bau die Triade

Die gute Nachricht aus Amazon ist nicht die 4,5× – es ist, worauf sie zurückgeht. Nicht auf ein besseres Modell, sondern auf den Mut, Prozess und Organisation gemeinsam mit der Technologie umzubauen. Das ist exakt die Pragtics-These, nur dass sie diesmal jemand gemessen hat.

Wer Agentic AI als Abkürzung um die unbequeme Organisationsarbeit herum versteht, wird enttäuscht – garantiert. Warum Technologie, Prozess und Organisation zusammen bewegt werden müssen, haben wir unter dem Prinzip hinter unserer Arbeit ausbuchstabiert. Wer sie als Anlass nimmt, die Triade endlich ernst zu nehmen, bekommt einen Hebel, den es so noch nicht gab. Die Wahl ist keine technische. Sie war es noch nie.

Bilder und sonstige Dankeschöns!

• Titelbild: Foto von Leo Wieling auf Unsplash

Quellen

• 1 – Sivasubramanian, S. / Amazon Web Services (2026), berichtet von GeekWire Quelle: Todd Bishop: „Two pizzas and a prototype: How agentic AI is rewiring Amazon’s teams and upending its traditions", GeekWire, 16.06.2026 – auf Basis eines Interviews mit AWS-VP Swami Sivasubramanian und seines AWS-Blogposts „How frontier teams are reinventing AI-native development". Aussage im Text: Median 4,5× (einzelne >10×) nur bei Teams, die den Workflow umgebaut haben, vs. keine Gewinne bei „Tool nur dazugelegt"; Zwei-Pizza-Teams (6–8 statt 30–40); Amazon Quick (~6 Engineers, 3 Monate); Bedrock-Engine (6 Engineers/76 Tage statt 30/12–18 Monate); Prototype-vor-PRFAQ; „bottleneck is the specification"; Jetlag-Anekdote; PMs coden/Engineers entscheiden; Token als Opex; Entscheidungs-Latenz ~10 %. Fundort: Abschnitte „Back to two pizzas", „Coding and testing", „Bigger goals, same team". Link: geekwire.com · AWS-Blog
• 2 – Microsoft (2026) Quelle: 2026 Work Trend Index: Agents, human agency, and the opportunity for every organization (Befragung: Edelman Data x Intelligence, 20.000 Wissensarbeitende, 10 Märkte, Feb.–Apr. 2026). Aussage im Text: Rund 67 % der realen KI-Wirkung gehen auf organisatorische Faktoren zurück, ca. 32 % auf individuelle Fähigkeiten; „Transformation Paradox". Fundort: Hauptbefund des Reports / Abschnitt zum Operating-Model-Umbau. Link: microsoft.com/worklab
• 3 – METR (2025) Quelle: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089. RCT, 16 erfahrene Entwickler, 246 Tasks auf eigenen Repos. Aussage im Text: KI-Tools auf unverändertem Prozess machten erfahrene Devs 19 % langsamer – bei gefühlter Beschleunigung. Beleg für „Tool ohne Umbau". Fundort: Abstract sowie „Results"/„Forecasts vs. realized". Link: arxiv.org/abs/2507.09089
• 4 – Conway, M. E. (1968) Quelle: How Do Committees Invent?, Datamation. Aussage im Text: Conways Gesetz – Softwarestrukturen spiegeln die Kommunikationsstrukturen der Organisation; daher muss die Organisation der neuen Bau-Geschwindigkeit folgen. Fundort: Kernthese des Aufsatzes. Link: melconway.com
• 5 – Amazon Web Services / Kiro (2025–2026) Quelle: Kiro – spec-driven, agentic IDE; GeekWire: „AWS targets AI slop with new spec check in Kiro" (2026). Aussage im Text: Kiro erzwingt Spezifikation und Tests vor dem Code und schiebt Validierung an den Moment des Schreibens; explizit gegen „Vibe Coding"/„AI Slop"; AWS-Reliability-Push für Agenten. Fundort: Produktbeschreibung kiro.dev; GeekWire-Bericht zum Spec-Check. Link: kiro.dev · geekwire.com – Spec-Check
• 6 – Jassy, A. / Amazon (2025) Quelle: Update from Amazon CEO Andy Jassy on Generative AI (aboutamazon.com) sowie Folgeberichterstattung zu Stellenabbau. Aussage im Text: Amazon hat seit Ende 2025 rund 30.000 Corporate-Stellen gestrichen; Jassy erwartet, dass generative KI und Agenten die Corporate-Belegschaft über die Zeit verkleinern. Fundort: Memo „Generative AI"; Berichterstattung zum Stellenabbau. Link: aboutamazon.com
• 7 – Brooks, F. P. (1986) Quelle: No Silver Bullet – Essence and Accidents of Software Engineering. Aussage im Text: Grundhaltung – es gibt keine magische technologische Lösung für inhärente Komplexität; Technologie allein ist nie die Antwort. Fundort: Kernargument des Aufsatzes. Link: cs.unc.edu (PDF)
• 8 – Brooks, F. P. (1975) Quelle: The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. Aussage im Text: Kommunikationswege wachsen quadratisch (n·(n−1)/2: 6 Personen = 15, 12 Personen = 66); daher deckelt der Koordinationsaufwand – nicht die Baukapazität – die effektive Teamgröße („Brooks’s Law"). Fundort: Kapitel zum Aufwand der Intercommunication / „Brooks’s Law". Link: Wikipedia-Übersicht
• 9 – Hackman, J. R. (2002 / 2009) Quelle: Leading Teams: Setting the Stage for Great Performances (Harvard Business School Press); pointiert in „Why Teams Don’t Work", Harvard Business Review (2009). Aussage im Text: Die zu managenden Verbindungen wachsen fast exponentiell mit der Teamgröße; ab rund zehn Personen überwiegt der Koordinationsaufwand – Empfehlung: Teams klein halten. Fundort: Argument zur Teamgröße; HBR-Interview „Why Teams Don’t Work". Link: hbr.org (2009)