Wie wir in Zukunft Software entwickeln

Am AWS AI Summit in Zürich ging es im Kern um eine einzige Frage: Wie entwickeln wir in Zukunft Software? Zwei Dinge sind hängen geblieben — ein Framework, das die Antwort sortiert (der AI-Driven Development Lifecycle), und ein Kundenshowcase, der zeigt, dass es in einer regulierten Grossbank tatsächlich funktioniert (Raiffeisen Bank International).

Hier die Erkenntnisse, die ich mitgenommen habe — und am Schluss der ehrliche Teil: die Lücke, die auch das beste Engineering-Framework offen lässt. Genau dort setzen wir mit Bionic-OS an.

Von Projektphasen zu «Bolts»

Der AI-DLC ersetzt die starre Projektlogik durch kurze, wiederholte Zyklen. Ein Bolt läuft durch drei Schritte — Inception → Construction → Operation — und dauert Stunden oder Tage, nicht Quartale. Danach der nächste. Und der nächste.

Das klingt nach Agile mit neuem Namen, ist es aber nicht: Der Unterschied liegt darin, dass Elaboration und Construction gemeinsam mit Agenten im Mob passieren. Das Team formuliert die Absicht, die Agenten produzieren, das Team reviewt — in einer Schlaufe, die nicht an Sprintgrenzen wartet.

AI Fluency ist eine Rolle, kein Tool-Rollout

Der für mich wichtigste Punkt des Vortrags: KI-Reife entsteht nicht durch Lizenzen, sondern über Menschen mit Auftrag. Shepherds rekrutieren und rüsten Champions aus, Champions führen Workshops und Mob Programming, und die Teams bauen Fluency an echter Arbeit auf — nicht in Schulungen.

Für den Einstieg nannte AWS vier Prinzipien, die sich lohnen aufzuschreiben:

• Invest in Agent Context — persistenten Kontext schaffen: Steering Files, Agent-Dateien, Coding-Standards, ein paar Skills. Bewusst nicht übertreiben.
• Make Intent Explicit — strukturierte Specs und eine klare Definition of Done, bevor Code generiert wird. Lieber kleine Aufgaben, die immer gelingen.
• Feed Agents, Don’t Babysit — gut geschnittene Backlogs pflegen, mehrere Agenten parallel laufen lassen, Output asynchron reviewen.
• Slow Down to Speed Up — Fluency braucht Zeit für Review, Feintuning und Kontextaufbau. Der Zinseszins kommt danach.

Autonomie wird nach Risiko gestaffelt

Die zweite Reifestufe geht von Fluency zu Autonomie — und dort wurde es angenehm unromantisch:

• Continuous Delivery ist die Baseline. Ohne volle Pipeline bleibt der Mensch der Flaschenhals. Die Zahl dazu: Top-Teams deployen 13,4 Mal pro Tag, der Median liegt bei 1,7.
• Autonomie nach Risiko-Tiers. Tier 1: Agenten laufen frei. Tier 2: KI entwirft, der Mensch gated. Tier 3: menschliche Autorenschaft, gestaffelter Rollout. Nicht alles oder nichts.
• FinOps für KI. Cost-to-Serve statt Cost-per-Token — ohne Messung lässt sich der Nutzen schlicht nicht beurteilen.
• Compound across the Org. Was ein Team lernt, wird als geteilter Skill in einer Agent-Registry verfügbar. Dort entsteht der grösste ROI — nicht im einzelnen Pilot.

Governance ist die Voraussetzung, nicht der Nachgedanke

Der AI-DLC-Stack hat vier Schichten: die Platform (Cloud, Git, Container, Observability), das Agent Harness (wo Entwickelnde mit Agenten arbeiten), Context & Capabilities (Specs, Steering Files, MCP-Tools, Skills, Unternehmenswissen) — und obendrauf Guardrails & Governance: Agent-Registries, geteilte Skills, Security, Kostenkontrollen, Quality Gates, Compliance.

Diese oberste Schicht ist der Unterschied zwischen einem beeindruckenden Pilot und einer Organisation, die skaliert.

Der Beweis: Raiffeisen Bank International

Genau diese Reihenfolge hat RBI im Showcase vorgeführt. Die Zahlen, die im Raum hängen blieben:

• 20’000 Mitarbeitende nutzen den bankeigenen, konformen KI-Chatbot konzernweit.
• 4’000+ Engineers arbeiten mit Claude und weiteren freigegebenen Coding-Agents.
• Kontrolliert wird das über ein LLM Gateway (ein freigegebener Zugang zu Modellen, einfacher Wechsel) und ein MCP Gateway (governierter Zugriff auf die Banksysteme).

Darauf hat RBI zwischen Mai und August 2026 ein eigenes AI-native PDLC Framework gebaut — Skills, Hooks und Agenten über sieben Phasen von Discovery bis Operate, inklusive Feedback-Loop zurück in Plan und Specs.

Am überzeugendsten war aber das kleine Fallbeispiel. Ein Cloud-Enablement-Team, 643 Tickets pro Quartal, zwei konkurrierende Flows (Service Requests und Sprint-Backlog) auf derselben Kapazität, und bis zu drei Tage für einen einzigen eskalierten Fall. Die Lösung waren keine grossen Modelle, sondern verpackte Workflows: Commands, Skills, Spezial-Agenten, MCP-Server und Hooks als wiederverwendbares Plugin. Ergebnis: 90 % der Fälle werden durch die agentische Erstantwort gelöst, die Triage dauert unter einer Stunde.

Die drei Lektionen daraus, in dieser Reihenfolge: Workflow optimieren (Kontext-Sammeln, Übergaben, langsame Feedback-Loops), Foundation verankern (Identity, Access, Policy, Observability, Kosten — aus der Plattform heraus), dann Scale (bewährte Workflows mit Berechtigungen, erwarteten Outputs und menschlichen Entscheidungspunkten verpacken).

Start here: ein einziger, abgegrenzter Workflow. Ergebnis, Kontrollen, menschliche Verantwortung und Messgrösse definieren. Dann standardisieren, was funktioniert.

---

Und jetzt der ehrliche Teil

All das ist hervorragend — und es beschreibt eine Phase. Ein Produkt entsteht in fünf: Discover, Specify, Build, Run, Support. In genau einer davon ist der Aufwand auf einen Bruchteil gefallen. In den anderen vier ist er exakt gleich geblieben.

Rechnen wir es an einem Projekt durch, wie es offeriert wird: 120 Tage, CHF 120’000. Davon 40 Tage Planung, 20 Tage Coding, 30 Tage Komponententests, 30 Tage Systemtest. Der Kunde schaut auf den Coding-Block und sagt — völlig zu Recht — das seien heute zwei Tage und ein Pro-Abo. Er hat recht. Aus 120 Tagen werden 102, aus CHF 120’000 werden CHF 102’000. Und das Projekt bleibt ein Projekt.

Vor allem aber: Diese 120 Tage sind nur der mittlere Block. Davor liegt herausfinden, was überhaupt gebaut werden soll. Danach UX, Go-to-Market, Support, Betrieb, das nächste Release. Für beide äusseren Blöcke existiert keine Zahl. Sie sind nicht geschätzt, nicht budgetiert, nicht optimiert. Sie passieren einfach. Und was nicht gemessen wird, wird auch nicht besser.

Am deutlichsten wird es bei den 40 Tagen «Planung». Das eigentliche Denken — ein paar Leute, die das Problem kennen, streiten sich, hören einander zu und entscheiden — dauert einen Nachmittag. Die 40 Tage danach sind jemand, der dieses Gespräch abtippt: in Requirements, Epics, Tickets, Tabellen. Das ist keine Arbeit am Produkt. Das ist Buchhaltung über das Produkt.

Welches Problem wir mit Bionic-OS lösen

Das Geniale liegt im Austausch. Alles danach ist Beinarbeit. Den ersten Teil fassen wir nicht an. Den zweiten nehmen wir ganz.

Wir haben das Bauen von Software automatiert. Bionic-OS automatisiert den Rest — die vier Phasen, die niemand als Effizienzthema betrachtet, weil sie nie eine Zahl hatten.

Konkret heisst das: eine durchgehende Kette statt fünf getrennter Werkzeugwelten — vom Kundengespräch in Discover über die Spezifikation, den Build mit dem Coding-Agenten deiner Wahl, den Betrieb bis zum Support-Ticket, das als Input in die nächste Runde zurückfliesst. Ein Kontext, der zwischen den Phasen nicht verloren geht, und Agenten, die jede Rolle unterstützen — während die Entscheidungen bei den Menschen bleiben.

Was ich vom AI Summit mitgenommen habe, passt exakt dazu: Governance zuerst, ein abgegrenzter Workflow als Start, Standardisieren statt Einzelfälle, und der Zinseszins entsteht dort, wo das Gelernte geteilt wird. Der einzige Unterschied — wir wenden dieselbe Logik nicht auf das Engineering an, sondern auf die vier Phasen drumherum.

Damit man aufhört, Buchhaltung über das Produkt zu führen. Und sich stattdessen um den Kunden kümmert.

---

Quellen: Vortrag zum AI-Driven Development Lifecycle und Kundenshowcase der Raiffeisen Bank International, AWS AI Summit Zürich, September 2026. Die Einordnung im zweiten Teil ist meine eigene.