Thoughtworks AIFSD: 26% des IT‑Spends für agentische KI bis 2029

Thoughtworks-Architekt Wes Reisz setzt AI-First Software Delivery nicht als selige Lösung, sondern als kontrolliertes Werkzeug ein: Wähle den Agententyp nach Code-Lebensdauer und automatisierbarer Verifikation; begleite jede Interaktion mit einem klaren Prozess. Zwei harte Zahlen aus seinem Vortrag fassen das Risiko und die Chance zusammen: Laut IDC entfallen bis 2029 rund 26% des weltweiten IT-Budgets auf agentische KI – das entspricht einem Volumen von 1,3 Billionen US-Dollar. Gleichzeitig verweisen Quellen auf eine MIT-Analyse, wonach 95% der KI-Projekte keinen ROI liefern. Reisz’ Antwort darauf ist pragmatisch: kein Multi-Agent-Eifer um jeden Preis, sondern ein 2×2-Entscheidungsmodell plus RIPER-5 (Research, Innovate, Plan, Execute, Review) und spec-driven Development als Vertrag zwischen Mensch und Modell. Für dich heißt das: Agenten bringen Skalierung, aber nur, wenn du Spezifikationen, Pairing und Verifikation zur Pflicht machst und nicht zum Nice-to-have.

Einleitung

Deep Dive: Das 2×2-Modell und RIPER-5 in der Praxis

Reisz strukturiert die Auswahl von Agententypen entlang zweier Achsen: Code-Lebensdauer (kurz vs. lang) und Grad der automatisierten Verifikation. In Quadranten mit kurzer Lebensdauer und geringer Verifizierbarkeit bleiben experimentelle, von Entwicklern geführte Sessions sinnvoll; in Bereichen mit hoher Verifizierbarkeit und klarer Domain-Sicht verschieben sich die Workflows in Richtung unsupervised Background Agents. Entscheidend ist, dass du nicht mit der komplexesten Architektur startest, sondern mit dem Modus, den dein Team und die Domäne vertragen.

RIPER-5 ist das Prozess-Gerüst, mit dem Reisz diese Wahl operationalisiert. Jede Phase hat klare Verbote: Research darf nicht kodieren, Innovate darf nicht planen, Plan darf nicht implementieren; Execute ist die erste Phase, in der Code entsteht; Review darf keinen Prüfschritt überspringen. Das verhindert Drift und frühe Übersprünge von Kontrollen. Reisz betont, dass diese Struktur keine neue Managementdoktrin ist, sondern eine Kodifikation üblicher Ingenieursarbeit, damit LLMs reproduzierbar und nachvollziehbar in den SDLC passen. In der Praxis lässt sich RIPER-5 als Set von Regeln in einem Repo ablegen (Rules/AGENTS.md), versioniert und für Auditierung nutzbar.

Praktisch bedeutet das für dein Team konkrete Artefakte in Git: eine SPEC.md pro Feature, eine AGENTS.md mit erlaubten Modellen und Tokenlimits, sowie ein Review-Checklist-Template, das proof-carrying outputs verlangt. Reisz nennt im Talk konkrete Tools und Integrationen: die Cursor-IDE als Agenten-Host und Claude Sonnet 4.6 als aktuelles Standardmodell für paired Coding. Die im Vortrag genannte "5x throughput increase" bezieht sich auf gemessene Produktivitätsgewinne in paired Human-AI-Workflows; solche Kennzahlen solltest du als relative Benchmarks betrachten und lokal verifizieren. Mehrere Praxisberichte, etwa von Beratungen, berichten von ähnlich hohen Effizienzgewinnen (bei Nortal werden über 50% Effizienzsteigerung in einem Time-Series-Projekt genannt), zeigen aber auch, dass diese Gewinne stark von der Engineering-Basis abhängen. Weitere Details zum Talk findest du bei InfoQ und im Vortragsvideo auf YouTube.

Deep Dive: Spec-Driven Development und sensible Defaults

Spec-Driven Development ist bei Thoughtworks kein Buzzword, sondern Vertrag: Spezifikationen fungieren als präzise Erwartungsdefinition zwischen Entwickler und Modell. Reisz differenziert drei Varianten — spec-first, spec-anchored und spec-as-a-source — und empfiehlt für den Einstieg spec-first. Praktisch heißt das: erst Spec, dann Code; als Verifizierungsmechanismen nutzt er proof-carrying output (z. B. End-to-End-Tests), BDD-artige Akzeptanzkriterien sowie Pre-/Post-Conditions. Das reduziert die typische Schwäche von LLM-gestütztem Code-Generieren: Tests, die nachträglich an Code angepasst sind und dadurch brittle werden.

Wichtig ist das Verhältnis von Planung zu Code: Reisz benennt in seinem Beispiel ein Verhältnis von etwa 10:1 — also zehn Teile Spezifikation und Planung auf eine Code-Einheit. Diese Schieflage ist Absicht: Software ist weniger das Tippen von For-Loops, mehr das Denken in Architektur und Akzeptanzkriterien. Als operative Basis nutzt sein Team „sensible defaults“ – CI/CD, Pair Programming, Trunk-Based Development, Security-Left und automatisierte Builds. Diese Praktiken bleiben die Hebel, die Agenten sicher und reproduzierbar in Produktion bringen.

Ein praktisches Artefakt ist das MCP-Server-Beispiel aus dem Talk: README + spezifizierte Tasks, automatisierte Transkription und Indexierung als einfache RAG-Aufgabe, später erweitert zu Multi-Turn-Interaktion durch ein registriertes Tool. Das zeigt, wie du Kontext, Memory und Tools in eine Agenten-Architektur einbindest, ohne Governance zu opfern. Ergänzend dazu empfiehlt Reisz, einen kleinen Satz automatischer Spec-Checker einzuführen, die Specs gegen existierende Tests und Architektur-ADRs abgleichen. In Proof-of-Concepts haben Teams so früh Fehler in der Domänenmodellierung entdeckt, noch bevor Agenten mit Code begannen. Auch Beratungsreports aus der Praxis zeigen, dass ein Spec-first-Ansatz die Zahl der Review-Kommentare und Regressionen signifikant senkt; ein Nortal-Beispiel beschreibt in einem Projekt über 50% Effizienzgewinne durch klarere Spezifikationsarbeit (Nortal).

Deep Dive: Supervised vs. Unsupervised—Risiken und Migrationspfade

Reisz begründet die Wahl eines supervised Ansatzes auf neuen Teams: drei Monate Teamlaufzeit, begrenztes Domainwissen, viele Unbekannte. In solchen Settings sind developer-paired Coding Agents die sicherste Option; sie erlauben Fallbacks, menschliche Entscheidungen und inkrementelle Verifikation. Erst mit wachsendem Domain-Know-how und stabilen Verifikationsketten empfiehlt er eine graduelle Bewegung Richtung unsupervised Agents und Background Sensing.

Der Haken ist klar: Agenten amplifizieren bestehende Praktiken. Eine schwache Engineering-Basis skaliert schlechte Entscheidungen linear oder exponentiell. Reisz warnt vor schneller Code-Erzeugung ohne entsprechende Review-Kapazität: erhöhte Defektraten, undichte Architekturgrenzen sowie fehlende Traceability in regulierten Umgebungen. Deshalb sind Metriken notwendig; Reisz nennt DORA-Artefakte als Zielweg, betont aber, dass im vorgestellten Projekt noch keine vollständige DORA-Metrik-Erhebung vorlag.

Konkrete Migrationsschritte, die Reisz vorschlägt, sind pragmatisch: 1) Starte mit Spec + supervised Agents + Pairing; 2) Führe automatische Spec-Checker und einfache Monitoring-Agenten ein (z. B. Linting-Bots, Testreport-Collector); 3) Miss Lead Time, Change Failure Rate und MTTR nach DORA-Logik; 4) Wenn Tests bei einer definierten Zuverlässigkeitsschwelle stabil sind, teste unsupervised Background Agents in isolierten Domänen. Reisz empfiehlt außerdem, Memory- und Index-Architekturen schrittweise aufzubauen: beginne mit einem Vektorstore, der PR- und ADR-Artefakte indexiert, und stelle sicher, dass der Store versioniert und gelöscht werden kann, um Datenschutz- und Compliance-Anforderungen zu erfüllen. Diese technischen Details sind wichtig, weil sie die Grenze zwischen kontrollierter Automation und unkontrollierter Drift markieren.

Deep Dive: Technischer Stack und Agenten-Orchestrierung

Die technische Umsetzung von AIFSD erfordert mehr als nur einen API-Key. Wes Reisz betont die Notwendigkeit einer robusten Tool-Registry. Agenten müssen in der Lage sein, auf definierte Werkzeuge zuzugreifen – von Lintern über Test-Runner bis hin zu Deployment-Skripten. In seinem Setup dient das Model Context Protocol (MCP) als Brücke, um Kontext und Werkzeuge standardisiert bereitzustellen. Dies verhindert den "Black Box"-Effekt, bei dem Agenten ohne Wissen über die Umgebung agieren.

Ein oft unterschätzter Faktor ist die Memory-Architektur. Damit Agenten über mehrere Sprints hinweg konsistent bleiben, müssen Architektur-Entscheidungen (ADRs) und Review-Feedback in einem Vektorstore (wie Milvus oder Pinecone) indiziert werden. Dieser "Long-term Memory" erlaubt es dem Agenten, bei neuen Aufgaben auf vergangene Entscheidungen Bezug zu nehmen. Für dich bedeutet das: Die Qualität deines Agenten-Outputs steigt linear mit der Qualität deiner indizierten Dokumentation. Ohne diesen Kontext bleibt der Agent ein Kurzzeit-Praktikant, der bei jedem Task bei Null anfängt.

So promptest du es richtig

Prompting ist hier kein kreatives Attaché, sondern Steuerungslogik: Mode, Verbote, Pre-/Post-Conditions und gewünschte Prüfartefakte gehören in jeden Prompt oder in die rules-Datei. Zwei anschlussfähige Prompt-Beispiele, die du in Cursor/Agent-Rules oder in deinem AGENTS.md ablegen kannst:

# Prompt 1: Research Mode (Deutsch, Cursor rules file)
Ziel: Sammle Kontext zum Modul "UserPolicy". Akzeptiere keine Code-Outputs. Frage gezielt nach fehlenden Vorbedingungen. Gib drei Unklarheiten in maximal 5 Bulletpoints zurück. Erzeuge keine Implementierung.

Erwarteter Output-Mock: 3 Bulletpoints mit fehlenden Voraussetzungen, Liste relevanter Dateien, Hinweis auf notwendige Tests.

# Prompt 2: Execute Mode (Spec-first, paired coding)
Ziel: Implementiere die in SPEC.md beschriebene API-Funktion "validatePolicy". Nutze vorgegebene Unit-Tests als proof-carrying output. Erzeuge nur Dateien, die zu Tests passen, und liefere Pre-/Post-Conditions als Kommentare.

Erwarteter Output-Mock: 1 x neue Datei mit maximal 80 LOC, dazu passende Unit-Testdatei, Kommentarblock mit Pre/Post-Conditions.

Wie gut ist der Output?

• Realismus: 4/5 — Agenten erzeugen plausiblen, ausführbaren Code, bleiben aber non-deterministisch.
• Konsistenz: 3/5 — Style/Architektur driftet ohne strikte Specs.
• Steuerbarkeit: 4/5 — RIPER-5 erhöht Vorhersehbarkeit deutlich.
• Speed: 5/5 — Generierung ist schnell, Review bleibt Bottleneck.
• Cost-per-Output: 3/5 — hohe Specs-Kosten, aber potenziell günstiger bei Skalierung.

Zusätzlich solltest du die Typen von Fehlern messen: funktionale Fehler, Architektur-Drift und Compliance-Lücken. In Projekten mit paired Agents trat die größte Reduktion bei trivialen Implementierungsfehlern auf, während architekturbezogene Probleme weiter manuelle Reviews erforderten. Reisz verweist darauf, dass Proof-Carrying Tests helfen, deterministische Proofs für kleine Units zu liefern, die sich automatisiert prüfen lassen — genau dort zeigen Agenten ihre größte Stärke.

Was du rechtlich beachten musst

• Modell-Lizenz & kommerzielle Nutzung: Prüfe, ob der genutzte Model-Provider kommerzielle Nutzung erlaubt und ob Attribution verlangt wird; halte Regelungen in der rules-Datei fest.
• Trainingsdaten-Risiko: Dokumentiere Herkunft der Trainingsdaten, besonders bei legacy-Code und personenbezogenen Daten; vermeide ungefiltertes Ingest in öffentliche Modelle.
• Wasserzeichen & Provenance: Implementiere Traceability (proof-carrying outputs) und speichere Prompts/Responses zur Auditierbarkeit; in Zukunft kann C2PA-konforme Provenance relevant werden.

Ergänzend musst du das regulatorische Umfeld beachten: Der EU-AI-Act differenziert Pflichten nach Risiko-Klassen und verlangt für Hochrisiko-Systeme umfangreiche Dokumentation, Testberichte und Governance-Mechanismen. Bußgelder können hoch sein, und nationale Datenschutzbehörden fordern bei DSGVO-relevanten Systemen nachvollziehbare Datenflows und Löschkonzepte. Praktisch heißt das: versioniere Prompts, speichere alle proof-carrying outputs im Audit-Repo und begrenze Ingests von personenbezogenen Daten in Drittmodelle. Wenn du öffentliche Modelle verwendest, dokumentiere unbedingt Provider, Modellversion und Eingabe-/Ausgabe-Samples als Teil des Compliance-Artefakts.

Workflow-Integration

Technisch lässt sich ein RIPER-5-basiertes Setup an bestehende Pipelines koppeln: speichere rules und SPEC.md in ein Git-Submodule, binde Cursor/Agent-Connectors als Tool-Registry in dein CI, und verwalte Memory/Index-Daten in einem Vektorstore, der PRs, ADRs und Tests indiziert. So wird der Agent zum toolfähigen Teammitglied, das auf denselben Artefakten arbeitet wie Entwickler.

Konkrete Komponenten, die sich bewährt haben: ein Vektorstore wie Milvus oder Pinecone für kontextuelle Suche, ein Indexer-Service, der PR-Diffs und Test-Reports in Vektoren übersetzt, und eine Regeln-Engine, die Agenten-Prompts vor der Ausführung validiert. In der Praxis ist es wichtig, diese Infrastruktur versionierbar und sicher zu betreiben: Secrets-Management für API-Keys, Quotalimits für Token-Ausgaben und automatisierte Löschjobs für sensitive Memory-Einträge sind keine Nice-to-haves, sondern Betriebspflicht.

Konkrete Schritte für die Umsetzung

Wenn du in einem DACH-Unternehmen starten willst, folge diesem pragmatischen Fahrplan, der Reisz’ Empfehlungen mit praktischen Metriken verbindet:

• Monat 0–1: Inventar & Governance — Karte der Domäne, Datenschutzklassifizierung, Auswahl erlaubter Modelle, Anlegen eines Rules-Repos.
• Monat 1–3: PoC mit supervised Agents — 2–3 paired-Sessions pro Woche, SPEC-First für 2–3 kritische Features, Messung: Baseline Lead Time und Change Failure Rate.
• Monat 3–6: Tooling & Metriken — Einführung eines Vektorstores, Automatisierung von Spec-Checkern, Dashboards für DORA-Metriken; Ziel: 30–50% Reduktion der Reviewzeit für Routinetasks.
• Monat 6–12: Graduelle Automatisierung — Pilot unsupervised Agents in nicht-sensiblen Modulen, definierte Rollback-Szenarien, Compliance-Audits vor breiter Freigabe.
• Kontinuierlich: Audit & Learn — versioniere Prompts, sammle proof-carrying outputs, führe Quarterly-Reviews zur ROI-Messung (z. B. Vergleich Lead Time und Change Failure Rate gegenüber Baseline).

Stakeholder, die du früh einbinden solltest: Datenschutzbeauftragter, Security-Team, Architekturbüro, Team Leads und ein Compliance-Owner. In vielen DACH-Projekten zahlt sich eine kleine Governance-Arbeitsgruppe aus, die initial Regeln verfasst und später als Audit-Schnittstelle fungiert.

So What? Praktische Implikationen für DACH-Unternehmen

Für deutsche Mittelständler und Konzerne gilt: Agentic Workflows bringen Potenzial, treffen aber in DACH auf strikte regulatorische Erwartungen und oft lückenhafte Engineering-Basen. Nutze das 2×2-Modell, um klein zu starten: Beginne mit supervised Agents in PoC-Scope, setze spec-first für alle produktionsnahen Features und instrumentiere früh DORA-ähnliche Metriken. Die EU-Rechtslage fordert zudem Vorsicht: absehbare AI-Act-Pflichten und hohe Bußgeldrahmen für Hochrisiko-KIs verlangen dokumentierte Verifikationspfade; halte deshalb Proof-Carrying-Outputs und Audit-Logs bereit.

Ein kurzer, konkreter Fahrplan: 1) Inventar der Domäne und Datensensibilität erstellen; 2) Minimal-Spec + Rules-Repo anlegen; 3) Pairing-Sessions starten; 4) Automatisierte Spec-Checker als erste Agenten einführen; 5) Schrittweise Automatisierung bis zur akzeptablen Verifikationstiefe. Das reduziert Risiko, schafft Nachvollziehbarkeit für Auditoren und macht Investitionen messbar.

Fazit: Handlungsempfehlung und Prognose

Agentische KI wird kommen — die IDC-Zahlen von 1,3 Billionen USD signalisieren eine massive Kapitalverschiebung bis 2029. Deine Entscheidung ist nicht ob, sondern wie: Beginne mit kontrollierten, spec-getriebenen, überwachten Agenten; mache Pairing, Tests und CI/CD zur Pflicht und messe Erfolge über DORA-ähnliche Metriken. Wer heute die Engineering-Basis für Agenten legt, wird 2026 nicht zu den 95% gehören, die laut MIT keinen ROI sehen, sondern die Skalierungsvorteile der automatisierten Software-Auslieferung voll ausschöpfen.