Episode #351 des französischsprachigen Podcasts **If This Then Dev** (Bruno) mit **Julien Lépine**, Chief Technology Officer von **AWS France** (13 Jahre bei Amazon), aufgezeichnet am Rande des **AWS Summit Paris** (1. April 2026, ca. 10.000 Teilnehmer). Kernthese: Im agentischen Zeitalter wird das Schreiben von Code zweitrangig, und der Wert verlagert sich auf **das Verständnis von Kontext, architektonischen Kompromissen und menschlicher Verantwortlichkeit**. Zentraler Beleg: die **Neuentwicklung von Amazon Bedrock** — einer kritischen Plattform, die Tausende Milliarden Anfragen verarbeitet — durch ein Team von **6 Personen in 72 Tagen** (gegenüber geschätzten 30 Personen / 18 Monaten), **Code vollständig von KI generiert**, ohne Vibe Coding. AWS **standardisiert intern auf Kiro** (IDE + CLI, läuft auf Claude Sonnet/Opus) für ca. 30.000 Entwickler (angekündigt von Matt Garman auf der re:Invent). Roter Faden: **die Kontrolle behalten**, ohne alles zu überprüfen — durch **formale Modellierung (TLA+)** und **Raisonnement automatisé**, um Invarianten zu beweisen und Agenten zu begrenzen, **blameless Post-Mortem**, sowie das Prinzip, dass „die Verantwortung für die Handlung eines Agenten bei der Person liegt, die ihn betreibt.“ Aufkommen des **AI DLC** (Sprints → mehrere tägliche **Bolts**) und das Risiko von **kognitiver Überlastung / Burn-out**.
#AWS Summit Paris#Amazon Web Services#Code-Agenten
**Julien Lépine** — Directeur de la technologie (CTO) d'Amazon Web Services France · 13+ ans chez Amazon ; ses équipes accompagnent les clients AWS sur le cloud · la data et l'IA. **Hôte** : Bruno (créateur et animateur du podcast *If This Then Dev*).
Keynote von **Gregor Hohpe** (Enterprise Strategist bei AWS, Autor von *The Software Architect Elevator* sowie des demnächst erscheinenden Buchs *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse*) bei **PlatformCon 2022** über **die Magie von Plattformen** — warum Plattformen erfolgreich sind, was sie von reinem *IT Service Management* unterscheidet, und **die nicht-trivialen Architekturentscheidungen**, die beim Aufbau einer solchen zu treffen sind. **Kernthese**: *"Standards schränken Kreativität nicht ein, sie können sie vervielfachen"* — analog zu Baltimore 1904 (Brand, inkompatible Pumpen), der ISO-Metrischschraube, HTTP, DIN-A4-Papier. **Kanonisches Zitat, entlehnt von Peter / Thoughtworks**: ***"Plattformen zentralisieren Expertise, aber nicht Innovation"*** — das Rad wird nicht neu erfunden, aber die Innovation bleibt den Teams überlassen, die dem Kunden am nächsten sind. **Zentrale Analogie**: die Automobilindustrie (der Volkswagen-Konzern baut den Audi A4 und den Bentley Bentayga auf derselben Plattform), *"undifferentiated heavy lifting"* (AWS-Vokabular) unter der Haube, Differenzierung sichtbar auf der Kundenseite. **Drei Eigenschaften einer echten Plattform**: (1) **geringe Reibung** (*low friction*) — Adoption lässt sich nicht erzwingen, Teams umgehen sie sonst; (2) **Transparenz** (keine *Black Box*) — Nutzer müssen diagnostizieren können, ob der Fehler bei ihnen oder bei der Plattform liegt; (3) **geteilte Verantwortung** (direkter Verweis auf das *AWS Shared Responsibility Model*) — die Plattform behebt keine schlecht konzipierte Anwendung. **Explizites Anti-Pattern**: *"eine gemeinsame Schicht kann vieles sein — sie ist nicht zwangsläufig eine Plattform"*; traditionelles IT Service Management zeigt dasselbe Bild (eine gemeinsame Schicht unter allen), aber die **Schnittstelle ist das Gegenteil** (hohe Reibung, Formulare, Flaschenhals). **Zwei Aufbauwege**: (a) jeden Bedarf antizipieren (Hohpe: *"Ich halte mich nicht für schlau genug dafür"*); (b) **Evolution** ausgehend von nützlichen Bausteinen, unter Beobachtung der Nutzung. **Explizit zu treffende Entscheidungen**: Ziele (kognitive Last ↓, sicherer / weniger Fehler, schneller durch Samples/Blueprints/Self-Service, Compliance), Form der Lernkurve (Klippe, Hockeyschläger, Gangwechsel). **Kanonisches Konzept Nr. 1 — Floating Platforms vs. Sinking Platforms**: Wenn die *Basisplattform* (typischerweise die Cloud) neue Fähigkeiten erhält, gibt es **zwei entgegengesetzte Strategien**: **Sinking Platform** (statisch, dupliziert, was die Basis nun bietet, sinkt mit steigendem Wasserspiegel) vs. ***Floating Platform*** (verwirft die redundant gewordenen Teile, **steigt über das neue Niveau**, innoviert weiter oben). Metapher *"U-Boot und Boot"*. Starke vertragliche Implikation: **Stakeholder explizit vorwarnen**, dass Komponenten entfernt werden, sobald die Basis sie absorbiert. **Kanonisches Konzept Nr. 2 — Fruit Salad vs. Fruit Basket**: Eine Plattform ist keine Sammlung nebeneinandergestellter Fähigkeiten (ein Korb), sondern ein **proportioniertes, mundgerechtes** Gefüge, in dem die Teile interagieren — *"der Kilopreis für Obstsalat ist höher als für einen Obstkorb"*. Der Titel leitet sich vom Ausdruck *the magic of platforms* ab — der kontraintuitive Effekt, bei dem **Standardisierung Innovation freisetzt, statt sie zu ersticken**, sofern Schnittstelle, Weiterentwicklung und Integration der Komponenten sorgfältig gehandhabt werden. Relevant für: Plattform-Architekten, **Platform-Engineering-/IDP-Teams 2026** (eine grundlegende Referenz, die dem *Internal-Developer-Platforms*-Boom vorausging, aber dessen Vokabular strukturiert), CIOs, die Build-vs-Stagnate gegenüber nativen Cloud-Fähigkeiten bewerten, Produkt-Führungsgremien. Konvergiert mit **AI/works™ Thoughtworks** (2026-05-12), **L'Usine Logicielle Augmentée Wescale** (2026-05-03), **PROJ-AI Habert/WEnvision** (2026-05-05), **DORA AI ROI** (2026-04-21 — Plattform als systemischer Pfeiler).
**Gregor Hohpe** — Enterprise Strategist chez Amazon Web Services · architecte logiciel · auteur prolifique (*Enterprise Integration Patterns* — référence depuis ~2003 — et *The Software Architect Elevator*, O'Reilly 2020). Au moment du talk · écrit *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse* (publié sur Leanpub, accessible via *leanpub.com/platformstrategy*). Profil : architecte *bridging the gap between business and tech* · expérience CTO Allianz · conseil C-suite · conférencier régulier (QCon, GOTO, PlatformCon). Référence majeure dans l'architecture d'entreprise et l'intégration. Talk donné en **keynote PlatformCon 2022** (juin 2022, conférence en ligne organisée par platformengineering.org).