Thoughtworks Radar: Warum KI-Engineering klassische Disziplin braucht

Die meisten KI-Projekte scheitern nicht an der Technologie, sondern an der fehlenden Ingenieurdisziplin dahinter. Das ist die These, die Nimisha Asthagiri, Data and AI Advisor bei Thoughtworks, in einer aktuellen Episode des New Stack Makers Podcasts vertritt — und sie trifft einen wunden Punkt, den viele Entscheider lieber ignorieren. Der Thoughtworks Technology Radar Vol. 34, eines der meistbeachteten Orientierungswerke der Softwarebranche, gibt ihr Recht: Agentic AI ist in der Breite angekommen, aber der Sprung vom Proof of Concept in die Produktion gelingt nur einem Bruchteil der Teams. Woran liegt das? Nicht an fehlender Rechenleistung oder unausgereiften Modellen — sondern daran, dass Organisationen versuchen, KI in bestehende Workflows einzufügen, statt grundlegend zu überdenken, was sie überhaupt bauen. Diese strukturelle Lücke zwischen Experiment und echtem Produktionsbetrieb ist das zentrale Problem des Jahres 2026 — und es erfordert ausgerechnet Werkzeuge, die viele Teams längst für überholt hielten.

Der PoC-to-Production-Gap: Ein Strukturproblem, kein Technologieproblem

Wer heute mit KI-Verantwortlichen in mittelständischen und großen Unternehmen spricht, hört eine verblüffend einheitliche Geschichte: Der Prototyp hat beeindruckt, das Management war begeistert — und dann passierte lange Zeit nichts Produktionsreifes. Asthagiri benennt den Kern des Problems direkt: Organisationen fragen sich zu oft "Wie werden wir schneller?" statt "Was können wir mit dieser Technologie bauen, das vorher schlicht nicht möglich war?"

Das ist keine rhetorische Unterscheidung. Der erste Ansatz führt dazu, dass Teams KI als Beschleuniger für bestehende Prozesse einsetzen — und dabei die strukturellen Schwächen dieser Prozesse einfach mitautomatisieren. Der zweite Ansatz erfordert Systems Thinking: eine vollständige Neubewertung dessen, welche Use Cases tatsächlich strategischen Mehrwert liefern, bevor auch nur eine Zeile Code entsteht. Erfolgreiche Unternehmen, so Asthagiri, investieren zuerst in Organisationskompetenz und die Ausrichtung ihrer Teams auf sinnvolle Anwendungsfälle — erst dann in die Implementierung.

Im DACH-Kontext ist dieser Befund besonders relevant. Laut aktuellen Marktdaten von Bitkom setzen im April 2026 rund 41 Prozent der deutschen Unternehmen KI aktiv ein — doch der Weg zur Skalierung bleibt steinig. Ein erheblicher Anteil der Projekte bleibt im PoC-Stadium stecken. Der Grund liegt selten am Modell, fast immer am fehlenden Engineering-Rahmen drumherum. Was den EU AI Act betrifft: Wer jetzt in Produktion geht, muss zudem seit August 2025 die GPAI-Regeln und Governance-Anforderungen erfüllen — ein weiterer Grund, warum improvisierte PoC-to-Production-Sprints teuer werden können.

Die Rückkehr der Engineering-Grundlagen: TDD, Mutation Testing, Observability

Einer der provokantesten Punkte aus Asthagiri und dem aktuellen Thoughtworks Radar ist, dass ausgerechnet alte Ingenieurtugenden wieder in den Vordergrund rücken. Test-Driven Development, Mutation Testing, Observability — Praktiken, die in vielen Teams unter dem Druck schneller Delivery-Zyklen vernachlässigt wurden, erfahren eine Renaissance. Der Grund ist logisch: Je mehr Code von KI-Systemen generiert wird, desto kritischer wird die Fähigkeit, diesen Code zu verifizieren und zu verstehen.

Mutation Testing ist dabei besonders interessant, weil es eine Schicht tiefer geht als klassische Unit Tests: Es verändert den Code gezielt, um zu prüfen, ob die Testsuite tatsächlich sensitiv genug auf Fehler reagiert. In einer Welt, in der Coding-Assistenten wie Claude Code oder Cursor 3 ganze Funktionsblöcke auf Knopfdruck generieren, wird diese Fähigkeit zur Pflicht — nicht zur Kür. Wer nicht versteht, was sein KI-System produziert hat, kann es nicht zuverlässig in Produktion betreiben.

Hinzu kommt Zero-Trust Security als explizit genanntes Prinzip, das bei autonomen Agenten in Production-Umgebungen besondere Relevanz gewinnt. Agentic AI, die eigenständig auf externe Systeme zugreift, Entscheidungen trifft und Code ausführt, ist kein theoretisches Zukunftsszenario — es ist der Stand von 2026. Die Sicherheitsarchitektur muss das von Anfang an widerspiegeln, nicht nachträglich draufgepflastert werden.

• Test-Driven Development: Macht KI-generierten Code prüfbar und verständlich, bevor er in Produktion geht.
• Mutation Testing: Prüft die Qualität der Testsuite selbst — entscheidend bei automatisierter Code-Generierung.
• Observability: Gibt Teams die Sichtbarkeit, die sie brauchen, um agentic Systeme im Betrieb zu verstehen.
• Zero-Trust Security: Architekturgrundsatz, der bei autonomen Agenten nicht optional ist.

Dark Code: Das Problem, das niemand benennen will

Asthagiri führt in der Podcast-Episode ein Konzept ein, das in seiner Konsequenz unterschätzt wird: "Dark Code". Gemeint ist KI-generierter Code, der möglicherweise niemals wirklich verwendet wird — analog zum Phänomen der "Dark Data" in Big-Data-Projekten, wo Unmengen an Daten gesammelt, aber nie ausgewertet werden. Der Gedanke klingt zunächst akademisch, hat aber handfeste operative Implikationen.

Jede Zeile Code, die existiert, muss irgendwann gewartet, verstanden oder migriert werden. Wenn Coding-Assistenten Code in einem Tempo generieren, das jedes menschliche Review-Kapazität übersteigt, entsteht ein technischer und kognitiver Schuldenberg. Asthagiri nennt dieses Phänomen "Cognitive Debt" — Teams verlieren das konzeptuelle Verständnis für ihre eigenen Systeme, weil sie schlicht nicht mehr nachkommen, den generierten Output zu durchdringen.

Die Lösung, die sie vorschlägt, ist ein intentionaleres Lifecycle-Management: Auch Code hat einen Lebenszyklus, und der Begriff "ephemeral code" — Code, der von vornherein als temporär und ersetzbar konzipiert wird — könnte ein Weg sein, die Masse zu beherrschen. Das ist keine romantische Rückkehr zu handgefertigter Software, sondern ein pragmatischer Umgang mit der Realität, dass AI-Systeme heute Code produzieren können, ohne dass irgendjemand gefragt hat, ob dieser Code gebraucht wird.

Für Operations Manager in deutschen Unternehmen bedeutet das konkret: Wer KI-Coding-Tools einführt, ohne gleichzeitig Prozesse für Code-Review, Lifecycle-Management und technische Schuldenreduzierung zu definieren, schafft eine neue Klasse von Legacy-Systemen — diesmal mit KI-Unterstützung. Das ist nicht billiger, sondern teurer als das Problem, das man lösen wollte.

Was dagegen spricht: Die Grenzen des "Back to Basics"-Arguments

Die These, dass klassische Ingenieurdisziplin die Antwort auf den KI-Wildwuchs ist, hat eine blinde Stelle. TDD und Mutation Testing setzen voraus, dass Teams ausreichend Kapazität haben, diese Praktiken konsequent anzuwenden. In vielen Organisationen ist genau das nicht der Fall — und das ist kein Management-Versagen, sondern Realität: Der Marktdruck ist hoch, die Verfügbarkeit erfahrener Engineers begrenzt, und die Erwartungen an Liefergeschwindigkeit sind gestiegen, nicht gesunken.

Wer den Thoughtworks Radar als Argument nutzt, um Prozessdisziplin einzufordern, muss gleichzeitig erklären, wie diese Disziplin in einem Umfeld skaliert, in dem GitHub Copilot Ende April 2026 Neuanmeldungen pausieren musste, weil der AI-gestützte Codierungsbedarf die Compute-Kapazität übersteigt. Die Antwort kann nicht einfach "mehr Tests schreiben" sein, wenn das Produktionstempo von KI-Agenten jeden menschlichen Review-Rhythmus sprengt.

Asthagiri adressiert das implizit, indem sie den Fokus von der reinen Codeerzeugung auf Spezifikationen und Kontextmanagement verschiebt. Das ist klug: Wenn die Spezifikation präzise genug ist, wird die Testbarkeit des generierten Codes strukturell besser — ohne dass jeder Entwickler jeden Code-Block manuell durchdenken muss. Dennoch bleibt die Frage offen, wie Organisationen diesen Übergang organisieren, ohne während der Transformation produktive Kapazität zu verlieren.

So What? Strategische Implikationen für DACH-Entscheider

Für Entscheider im DACH-Raum ist der Kern dieser Debatte nicht akademisch, sondern strategisch akut. Wer KI-Engineering als reines Technologieprojekt behandelt, wird am PoC-to-Production-Gap scheitern — das ist mittlerweile empirisch gut belegt. Was fehlt, ist ein Organisations- und Governance-Rahmen, der dem Engineering-Team erlaubt, Qualitätssicherung und Lifecycle-Management als erstklassige Aufgaben zu behandeln.

Im Klartext: Wer heute ein KI-Projekt startet, sollte drei Fragen beantworten, bevor der erste Prompt geschrieben wird. Erstens: Welchen strategischen Wettbewerbsvorteil liefert dieses System, den wir ohne KI nicht hätten? Zweitens: Welche Engineering-Praktiken stellen sicher, dass wir den generierten Code verstehen und warten können? Drittens: Wie sieht das Lifecycle-Management für ephemeral und long-lived Code aus?

Für den EU AI Act gilt: Ab dem 2. August 2026 greifen die Hauptteile des Acts, inklusive der Anforderungen an Hochrisiko-KI-Systeme. Agentic AI, die eigenständig Entscheidungen trifft und in Produktionssysteme eingreift, dürfte in vielen Szenarien als Hochrisiko eingestuft werden. Die Observability- und Dokumentationspflichten, die Asthagiri aus Engineering-Sicht fordert, sind damit nicht nur Best Practice — sie werden regulatorische Mindestanforderung. Wer jetzt die Ingenieurgrundlagen legt, baut gleichzeitig Compliance-Infrastruktur auf.

Praktisch bedeutet das: Priorisiere Use Cases, die klaren strategischen Mehrwert liefern und lehr dein Engineering-Team, diese Use Cases mit Disziplin umzusetzen. Der Weg dahin führt nicht durch mehr Geschwindigkeit, sondern durch bessere Spezifikationen, konsequentes Testen und ein ehrliches Inventory dessen, was wirklich gebraucht wird — und was Dark Code ist, der nur Kosten erzeugt.

Fazit: Disziplin ist kein Rückschritt, sondern Wettbewerbsvorteil

Die Thoughtworks-These ist unbequem, weil sie den Hype-Narrativen widerspricht: KI-Engineering wird nicht einfacher, nur weil Modelle mächtiger werden. Im Gegenteil — mit wachsender Autonomie agentic Systeme steigen die Anforderungen an Governance, Testbarkeit und organisationale Reife. Teams, die jetzt in Engineering-Disziplin investieren, bauen einen strukturellen Vorteil auf, der schwer zu kopieren ist.

Meine Einschätzung: Die Wahrscheinlichkeit, dass der PoC-to-Production-Gap in den nächsten zwölf bis achtzehn Monaten größer wird statt kleiner, liegt hoch. Zu viele Organisationen haben KI-Projekte gestartet, ohne die operative Infrastruktur dafür zu schaffen. Wenn/dann gilt: Wenn ein Unternehmen jetzt nicht in TDD, Observability und Code-Lifecycle-Management investiert, wird es spätestens beim nächsten Regulierungs-Audit oder dem ersten schwerwiegenden Production-Incident nacharbeiten müssen — unter Druck und mit höheren Kosten. Der bessere Zeitpunkt war gestern. Der zweitbeste ist heute.