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

Amazon, die 4,5× und die Teams ohne Gewinn

Ü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 Schichten, die wir immer zusammen ansehen: Organisation, Prozess und IT. 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. Den scheinbaren Widerspruch löst der derzeit beste verfügbare Datenpunkt auf: das, 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.

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.

Warum die drei Schichten zusammengehören

Warum wir Organisation, Prozess und IT zusammen ansehen, hat einen Grund: Der Engpass ist eine Eigenschaft des ganzen Systems. Er zeigt sich in einer Schicht und hat seine Ursache oft in einer anderen. Wer nur eine Schicht verbessert, macht das Ganze oft nicht besser. Agentic AI zeigt das so deutlich wie selten, 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) Das passt zu Amazon, es ist die andere Seite derselben Medaille: In der Studie wurde ein Tool auf einen unveränderten Prozess gesetzt. Genau das ist „Agile Theater" in neuer Verkleidung. Und es ist eine lokale Optimierung: Das Tool beschleunigt einzelne Schritte, und beim Kunden kommt nichts davon an.

Schauen wir uns also an, was „den Prozess umbauen" bei Amazon konkret heißt, entlang der drei Schichten Organisation, Prozess und IT.

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 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 nie aus der Baukapazität. Sie kam 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.

Diese Obergrenze bleibt. KI ändert, 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 das Programm um das Team herum: 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.

Wenn KI das Bauen beschleunigt, wandert der Engpass: weg vom Bauen, hin zur Abstimmung. Ein Apparat aus 40 Personen wird dann selbst zum Engpass. Amazon passt deshalb die Organisation an, statt nur Tools zu verteilen. Conways Gesetz erklärt, warum das auch die Software betrifft: Systeme, die eine Organisation selbst baut, spiegeln ihre Kommunikationsstruktur. (4) Wer nur die Teams umbaut und die Architektur lässt, wie sie ist, bekommt die alten Schnittstellen zurück. 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 wandert vom Bau zur Spezifikation

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 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.

Organisation, zweiter Teil: Rollen und Entscheidungen

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: Zu den Betriebskosten gehören künftig die Köpfe und die Agenten, die neben ihnen arbeiten. (1)

Der Mensch verschwindet also nicht. Er rückt dorthin, wohin der Engpass bei Amazon gewandert ist: zur Spezifikation. Urteil und Verantwortung gehören dazu.

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 drei Schichten zeigen, woran es hängt: Ein Werkzeug beschleunigt einen Schritt. Ob das Ganze schneller wird, entscheidet der Engpass, und der sitzt oft in einer anderen Schicht. Bei Amazon kamen die 4,5× aus dem Umbau der Arbeitsweise. Wer nur das Tool kauft, bekommt die METR-Studie (Stillstand) und 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 es dafür bisher gab. Wo ein Unternehmen schon vorher Organisation, Prozess und IT zusammen gedacht hat, wirkt KI wie ein Verstärker. Wo nicht, legt KI die Schwäche nur schneller offen.

Wo steht Deine Organisation?

Ehrliche Standortbestimmung, diesmal danach, wie weit Organisation, Prozess und IT schon zusammenpassen:

Level 4 kommt nicht über Nacht. Das erste Ziel 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 Organisation, Prozess und IT zusammenpassen, sind 4,5× 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 zeigen eine Richtung und sind kein Versprechen.
• Lokale Optimierung mit Agenten: Ein Tool ohne Umbau beschleunigt Schritte, die nicht der Engpass sind. Das Ergebnis ist 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, und das gehört in jede ehrliche Diskussion.

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

1. Der Drei-Schichten-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, ist die Gefahr groß, dass die Änderung nicht hält. Wo euer Engpass sitzt, zeigt das noch nicht. Dafür braucht ihr Ablauf, Organigramm und Systemlandschaft nebeneinander und eine Messung.
2. An der Spezifikation ansetzen: 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 Genehmigungsschritt (CAB, Sign-off, Ticket-Stau), vor dem die Arbeit am längsten liegt, und prüft, ob die Stationen danach in der Zeit auf Arbeit warten. Wenn ja, ist er ein Kandidat für euren Engpass und ein besseres Ziel als 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 und die Validierung fest in den Prozess einbauen.

Fazit: Erst den Engpass finden, dann das Tool kaufen

Wichtiger als die 4,5× aus Amazon ist, worauf sie zurückgehen. Das passt zu dem, was wir in Projekten sehen: Der Engpass zeigt sich in einer Schicht und hat seine Ursache oft in einer anderen. Wer nur das Werkzeug tauscht, arbeitet an einer einzigen Schicht.

Wer Agentic AI als Abkürzung um die unbequeme Organisationsarbeit herum versteht, wird garantiert enttäuscht. Warum wir Organisation, Prozess und IT zusammen ansehen, bevor wir einen Engpass benennen, steht unter dem Prinzip hinter unserer Arbeit. Wer sie als Anlass nimmt, Organisation, Prozess und IT endlich zusammen anzusehen, 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: Systeme, die eine Organisation baut, spiegeln deren Kommunikationsstruktur. Ein Umbau der Teams hält deshalb nur, wenn die Architektur mitgeht, und umgekehrt. 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)