Am 5. November 2026 haben Henning Teek und ich bei der AWS User Group Dortmund gezeigt, wie unsere AI Software Factory auf AWS läuft: erst das Modell, dann die Implementierung mit dem AgentHub. Hier die wichtigsten Punkte mit den Folien, die es dafür braucht.

Es waren zwei Talks hintereinander, Level 400 und auf Englisch. Ich habe über den Software Development Lifecycle in Zeiten von Agenten gesprochen, Henning Teek, Principal bei Storm Reply, im Anschluss über den AgentHub. Der AgentHub und unsere AI Software Factory sind die Implementierung von Silicon Shoring1 auf AWS, dem KI-gestützten Software-Delivery-Modell der Reply Group.

Teil 1: Das Modell, der Agentic Engineering Loop

Coding-Agenten haben einen Teil des Weges von der Idee bis zum Release schnell gemacht: das Schreiben von Code. Anforderung, Architekturentscheidung, Review, Deploy und Betrieb laufen weiter im Tempo von Menschen. Wer nur das Coding beschleunigt, stellt schnelleren Code vor denselben Engpass. Deshalb habe ich keinen Agenten gezeigt, sondern ein Betriebsmodell.

Der Agentic Engineering Loop besteht aus Kreisläufen, die sich berühren. Außen liegt der Kundenkreis mit genau zwei geteilten Punkten: oben die Anforderungen, unten die Abnahme. Dazwischen läuft der Engineering-Kreis, gebunden an Feature Sets und Abnahmen statt an Sprints. Darin dreht sich der Agentic Loop, in dem ein Agent ein einzelnes Feature in Minuten bis Stunden baut, deployt und testet. Nach dem Go-Live führt der Learning Loop Störungen und Nutzungsdaten aus dem Betrieb als neue Anforderungen zurück. Dieser Pfeil ist der Unterschied zwischen einem Projekt und einem Produkt.

Abbildung 1: Der Agentic Engineering Loop mit Kundenkreis, Engineering-Kreis, Agentic Loop und Learning Loop
Abbildung 1: Der Agentic Engineering Loop. Der Kunde ist an zwei Stellen beteiligt, der Betrieb liefert neue Anforderungen zurück. Folie aus meinem Talk, Grafik: Storm Reply.

Die wichtigste Gewohnheit steckt im Kasten Agentic Coding: Der Agent schreibt zuerst keinen Code, sondern eine Spezifikation und einen Implementierungsplan. Beides prüfen ein zweites Modell und ein Mensch. Der Mensch liest den Plan, nicht den Diff.

Am Ende bleiben vier Stellen, an denen ein Mensch entscheidet: die Anforderungen, die Entscheidungen zu Architektur, Sicherheit und Performance, der Plan und die Abnahme. Alles dazwischen darf agentisch laufen, innerhalb von Gates, die technisch erzwungen werden. Rechte, die nur in einem Prompt stehen, sind keine Rechte. Was nicht erlaubt ist, muss technisch unmöglich sein.

Abbildung 2: Vier Entscheidungspunkte des Menschen, dazwischen arbeiten Agenten
Abbildung 2: Wo der Mensch die Kontrolle behält: Anforderungen, Architektur, Plan und Abnahme. Folie aus meinem Talk, Grafik: Storm Reply.

Das ganze Modell in vier Zoomstufen steht im Artikel AI Software Factory: Der Software Development Lifecycle in Zeiten von KI.

Teil 2: Der AgentHub, eine Fertigungslinie auf AWS

Henning hat gezeigt, wie dieses Modell gebaut ist. Der AgentHub nimmt Aufträge über eine Web-App, das Terminal, GitHub, Chat-Bots oder einen Zeitplan an. Ein Agent arbeitet in einer isolierten Sandbox und liefert einen Git-Branch oder einen Pull Request zurück. Henning beschreibt das als Fertigungslinie mit vier Stationen: Annahme, Arbeitsplatz, Qualitätstor, Versand. Die Agenten besetzen die Stationen. Die Engineers entwerfen die Linie, setzen die Regeln und geben frei, was ausgeliefert wird.

Dunkel, hell oder gedimmt

Die erste Frage an jede Software Factory lautet: Wie viel Licht braucht sie? In der Dark Factory prüft kein Mensch mehr eine Änderung. Das ist rund um die Uhr günstig, aber nur so gut wie die Tests, und ein schlechtes Muster verbreitet sich über viele Änderungen, bevor jemand hinschaut. In der Lights-on Factory gibt ein Mensch jeden Schritt frei. Das fühlt sich sicher an, läuft aber im Tempo der Reviewer. Und nach dem fünfzigsten Prompt klickt man Ja, ohne zu lesen.

Hennings Antwort ist, das Licht je Spur einzustellen. Abhängigkeits-Updates, Lint-Fixes, Dokumentation und das Reparieren instabiler Tests laufen dunkel und werden gemerged, sobald die CI grün ist. Alltägliche Features und Fixes laufen gedimmt: Der Agent arbeitet allein, ein Mensch reviewt den Pull Request. Authentifizierung, Zahlungen, Datenmigrationen und Infrastruktur bleiben hell, hier gibt ein Mensch den Plan frei, bevor der Agent startet.

Abbildung 3: Die gedimmte Fabrik mit Dark Lane, Dimmed Lane und Lit Lane
Abbildung 3: Die gedimmte Fabrik: Die Autonomie folgt Risiko und Testabdeckung, je Spur. Folie aus Hennings Talk, Grafik: Storm Reply.

Die Spuren sind nicht fest. Eine Spur wird dunkler, wenn ihre Änderungen eine saubere Bilanz haben und die Tests ihre Regressionen fangen. Sie wird wieder heller, sobald etwas in Produktion bricht, Tests fehlen oder der Agent Neuland betritt. Im AgentHub ist der Dimmer der Branch-Schutz in GitHub: Verlangt ein Repository eine menschliche Freigabe, wartet der Merge auf einen Menschen. Das ist dieselbe Regel wie in meinem Teil: Die Autonomie darf nur so weit gehen, wie die Prüfung trägt.

Vertrauen trennen: Laufzeit und Sandbox

Die Orchestrierung teilt das Vertrauen in zwei Teile. Die Amazon Bedrock AgentCore2 Runtime ist der Vorarbeiter. Sie nimmt die Aufträge über das A2A-Protokoll an, sichert die Sitzungen in S3 und hält als einzige Stelle die Schlüssel der GitHub App. Der Agent selbst läuft in einer Lambda MicroVM, eine VM je Gespräch, als unprivilegierter Nutzer. Er bekommt nur eine Rolle, die Bedrock aufrufen darf, und ein GitHub-Token für ein einziges Repository, das nach einer Stunde abläuft. Zwischen zwei Runden schläft die VM und wacht mit der nächsten Nachricht wieder auf. Nach spätestens acht Stunden ist sie weg.

Abbildung 4: AgentCore Runtime als vertrauenswürdiger Container, Lambda MicroVM als Sandbox des Agenten
Abbildung 4: Die Runtime hält die Schlüssel, die Sandbox hält den Agenten. Darunter eine Runde vom Start bis zum Ende. Folie aus Hennings Talk, Grafik: Storm Reply.

Der Grund dafür ist Prompt Injection. Issues, Kommentare, CI-Logs und Code schreiben andere Menschen, und eine präparierte Zeile kann einen Agenten anweisen, ein Token zu verraten oder eine Hintertür einzubauen. Henning geht davon aus, dass ein Agent früher oder später hereingelegt wird, und begrenzt, was das kostet: ein Repository, höchstens eine Stunde, und der Pull Request muss trotzdem alle Prüfungen bestehen.

Agenten arbeiten über Events, nicht im Chat

Statt eines großen Agenten arbeiten mehrere kleine. Ein Issue mit dem Label agenthub startet den Implementer, der Code und Tests schreibt und einen Pull Request öffnet. Der Reviewer prüft jede Änderung, der Implementer arbeitet die Anmerkungen ein. Nach fünf Runden stoppt die Schleife und fragt einen Menschen. Ein CI-Fixer repariert fehlgeschlagene Builds, ein Conflict Resolver löst Merge-Konflikte, und ein Unblocker startet Issues, sobald ihre Blocker erledigt sind. Wenn alle Prüfungen und Freigaben vorliegen, merged GitHub automatisch.

Abbildung 5: Ein Auftrag vom Issue bis zum automatischen Merge in sechs Schritten
Abbildung 5: Ein Auftrag von Anfang bis Ende, vom Issue mit Label bis zum Merge. Folie aus Hennings Talk, Grafik: Storm Reply.

Jeder dieser Agenten ist eine einzige Markdown-Datei. Sie legt fest, wer der Agent ist, mit einer eigenen GitHub App und nur den Rechten, die er braucht, und wann er läuft. Der Text der Datei ist der Prompt. Agenten sind damit Code: Änderungen an ihnen laufen als Pull Request durch ein Review wie alles andere.

Damit niemand den Agenten bei der Arbeit zuschauen muss, meldet sich die Fabrik selbst: wenn ein Agent eine Frage hat, eine Prüfung scheitert oder die Review-Schleife ihr Limit erreicht. Eine Auswertung zeigt die Bedrock-Tokens und die Kosten je Zeitraum und Auftraggeber.

Drei Dinge zum Mitnehmen

  1. Das Licht je Spur dimmen. Die Autonomie folgt Risiko und Testabdeckung. Menschen beaufsichtigen den Loop, statt jeden Schritt freizugeben.
  2. Vertrauen trennen. Die Runtime hält die Schlüssel, die Sandbox hält den Agenten. Ein hereingelegter Agent kann wenig Schaden anrichten.
  3. Agenten über Events koppeln. Kleine, spezialisierte Agenten übergeben sich die Arbeit in GitHub, bis der Auftrag erledigt ist.

Danke an alle, die dabei waren, und an Henning für den zweiten Teil. Eine Fassung ohne technisches Vorwissen und mit offener Diskussion zeigen wir am 19. November 2026 beim Agentic Shift Meetup in Dortmund.

Quellen

  1. Reply: „Reply launches Silicon Shoring: an AI-Powered Software Delivery model to optimise and automate the entire Software Development Life Cycle“, Pressemitteilung, 15. Mai 2025. reply.com
  2. Amazon Web Services: „What is Amazon Bedrock AgentCore?“, Amazon Bedrock AgentCore Developer Guide, abgerufen 31. Oktober 2026. docs.aws.amazon.com