Warum AI Coding große Systeme bauen kann — aber Production Engineering nicht ersetzt

Warum ist „Code schreiben“ nicht dasselbe wie „ein System bauen“?

Weil ein produktives Softwaresystem aus mehr besteht als aus Quelltext. Produktionsreife ist die Summe aus Code, Spezifikation, Tests, Architektur, Security, Observability, Deployment-Kontrollen, Betriebsprozessen und Ownership — AI Coding beschleunigt vor allem den ersten dieser Bestandteile.

Diese Unterscheidung ist der Kern der gesamten Diskussion. Ein Coding Agent optimiert die Geschwindigkeit, mit der Code erzeugt, verändert und analysiert wird. Das ist wirtschaftlich enorm wertvoll — und es ist genau ein Bestandteil von neun.

Production Readiness = Code + Spezifikation + Tests + Architektur + Security + Observability + Deployment-Kontrollen + Betriebsprozesse + Ownership

Woraus Produktionsreife tatsächlich besteht

• Spezifikation

  Eine von der Implementierung unabhängige Aussage darüber, was das System tun soll — und was es niemals tun darf.

• Architektur

  Entscheidungen über Zuschnitt, Zustände, Konsistenz und Fehlermodelle, die sich später nicht mehr billig ändern lassen.

• Tests

  Nicht nur Testfälle, sondern eine unabhängige Definition dessen, was als korrektes Ergebnis gilt.

• Security

  Die Frage, wie sich das System zu etwas bewegen lässt, das es nicht tun sollte — eine andere Fragestellung als Funktionalität.

• Observability

  Die Fähigkeit, im laufenden Betrieb zu erklären, was gerade passiert und warum.

• Deployment-Kontrollen

  Freigaben, Staging, Rollback-Kriterien und die Möglichkeit, eine Änderung zuverlässig zurückzunehmen.

• Betriebsprozesse

  Incident Response, Bereitschaft, Wiederanlauf, Wartungsfenster — alles, was nach dem Deployment beginnt.

• Ownership

  Eine benannte Stelle, die Architektur und Betrieb verantwortet, über Jahre und über einzelne Änderungen hinaus.

AI kann fast jeden dieser Schritte unterstützen — Tests erzeugen, Dokumentation schreiben, Migrationen vorbereiten, Reviews vorstrukturieren, Incidents analysieren. Sie ersetzt aber nicht die Notwendigkeit dieser Schritte. Wer den Prozess weglässt, weil der Code schneller entsteht, hat nicht Aufwand gespart, sondern Prüfung.

Was bedeutet ein probabilistischer Entwicklungsprozess?

Dass derselbe Auftrag zu unterschiedlichen Lösungswegen und technischen Entscheidungen führen kann. Nicht der ausgelieferte Code ist zufällig — nach dem Commit ist AI-generierter Code ein ganz normales Softwareartefakt. Probabilistisch ist der Weg dorthin.

Diese Unterscheidung entscheidet darüber, ob die Argumentation technisch trägt. Die Aussage „AI-Code ist nicht deterministisch“ ist unsauber und lädt zu Widerspruch ein. Richtig ist: Der Generierungsprozess ist probabilistisch, das Ergebnis danach ein Artefakt wie jedes andere.

Warum das bei kleinen Aufgaben selten stört

Bei einer einzelnen Funktion — etwa der Validierung einer E-Mail-Adresse — ist der Lösungsraum überschaubar. Entstehen drei verschiedene Implementierungen, lassen sie sich mit überschaubarem Aufwand gegeneinander prüfen. Der Nicht-Determinismus ist vorhanden und praktisch folgenlos.

Warum der Effekt mit der Systemgröße relevant wird

In einem großen System besteht eine Aufgabe nicht aus einer Entscheidung, sondern aus tausenden voneinander abhängigen. Ein probabilistischer Agent muss über lange Aufgabenketten hinweg sehr viele Annahmen treffen:

• Welche Architektur wird verwendet, und wo liegt welche Business-Logik?
• Welche Daten werden synchron, welche asynchron verarbeitet?
• Welche Fehler werden abgefangen, welche Zustände sind erlaubt?
• Wie wird ein Retry umgesetzt, welche Transaktion umfasst welchen Vorgang?
• Wie werden Race Conditions verhindert, was passiert bei partiellen Ausfällen?
• Welche Daten dürfen gecacht werden, welche Berechtigungen gelten?

Das Risiko entsteht nicht dadurch, dass mehr Zufall im Spiel wäre. Es entsteht dadurch, dass Entscheidungen voneinander abhängen: Je länger die Kette, desto größer die Wahrscheinlichkeit, dass eine frühe falsche Annahme an einer viel späteren Stelle Wirkung zeigt — dort, wo niemand nach ihr sucht.

Nicht-Determinismus ist kein Grund, AI Coding abzulehnen. Er ist ein Grund, die Verifikation zu industrialisieren: Ein probabilistischer Entwickler braucht besonders starke deterministische Kontrollsysteme.

Warum liefern grüne Tests keine Garantie?

Weil Implementierung und Tests dieselbe falsche Annahme teilen können, wenn beide aus derselben Quelle stammen. Ein Test braucht nicht nur Testdaten, sondern eine unabhängige Aussage darüber, was das korrekte Ergebnis wäre — genau die fehlt, wenn dasselbe System Anforderung, Code und Testerwartung erzeugt.

Vorweg, weil die pauschale Variante dieser Kritik falsch ist: AI kann Tests sehr gut erzeugen — Unit Tests, Integrationstests, ganze Suites. Das ist ein echter Vorteil, und die Behauptung, AI-generierte Systeme hätten keine Tests, geht an der Praxis vorbei.

Das Problem entsteht an einer anderen Stelle. Kritisch wird es, wenn ein und dasselbe System die Anforderung interpretiert, den Code schreibt, definiert was korrektes Verhalten ist, die Tests dafür schreibt und anschließend anhand dieser Tests entscheidet, ob die eigene Implementierung korrekt war.

Das Test-Oracle-Problem

Ein Test braucht ein Orakel: eine Aussage darüber, was herauskommen soll, die nicht aus dem geprüften Code abgeleitet ist. Fehlt sie, entsteht ein geschlossener Kreis, in dem falscher Code und falscher Test einander bestätigen. Das Ergebnis ist die unangenehmste Form von Fehler: Alle Tests sind grün, und das System ist trotzdem falsch.

Womit sich eine unabhängige Definition von „korrekt“ herstellen lässt

• Acceptance Criteria aus fachlichen Spezifikationen statt aus dem Code
• Contract Tests zwischen Diensten
• Property-based Testing gegen fachliche Invarianten
• Mutation Testing, um die Aussagekraft der Suite selbst zu prüfen
• unabhängig erstellte Test-Suites und Integrationstests gegen reale Abhängigkeiten
• End-to-End-, Security-, Last- und Chaos-Tests
• manuelle Reviews der kritischen Invarianten

Ein grüner Test beweist nur dann etwas, wenn die Definition von „grün“ unabhängig vom möglichen Fehler entstanden ist.

Warum muss Observability bewusst entworfen werden?

Weil ein Agent nur die Observability bauen kann, die spezifiziert, architektonisch vorgesehen oder aus dem bestehenden System ableitbar ist. Welche Signale für ein Geschäft kritisch sind, steht nicht im Code — das ist eine Produkt- und Architekturentscheidung.

Auch hier ist die pauschale Kritik falsch: Ein Coding Agent kann Logs, Metriken, Distributed Tracing, Dashboards und Alerts implementieren, und er tut es oft sauberer als ein Team unter Zeitdruck. Observability ist trotzdem keine automatische Eigenschaft generierter Software.

Der Unterschied zeigt sich an den Fragen, die ein produktives System beantworten können muss: Wie viele Requests schlagen fehl? Welche Abhängigkeit verursacht die Latenz? Welche Kundengruppe ist betroffen? Welche Version hat den Fehler eingeführt? Ist er lokal oder systemweit? Welche Requests gehören zu derselben Transaktion? Keine dieser Fragen lässt sich aus dem Quelltext ableiten — sie ergeben sich daraus, was das Unternehmen wissen muss.

Dafür braucht es bewusst entworfene Logs, Metriken, Traces, Correlation IDs, Audit Logs, Dashboards, Alerts sowie SLOs und SLIs. Die Implementierung kann ein Agent übernehmen. Die Entscheidung, welches Signal einen Alarm auslöst und welches nicht, bleibt eine fachliche.

AI kann Observability implementieren. Sie kann aber nicht automatisch wissen, welche Signale für Ihr Geschäft kritisch sind.

Warum funktioniert Security anders als Feature-Entwicklung?

Weil Softwarequalität fragt, ob das System funktioniert, und Security fragt, wie jemand es dazu bringen kann, etwas zu tun, das es niemals tun sollte. Das ist keine Gradfrage, sondern eine andere Fragestellung — und sie wird nicht dadurch beantwortet, dass alle Anforderungen erfüllt sind.

Ein System kann jede funktionale Anforderung erfüllen und trotzdem kritische Lücken enthalten: fehlende Autorisierung, SQL Injection, SSRF, unsichere Deserialisierung, falsch konfigurierte Cloud-Rollen, exponierte Secrets, fehlende Rate Limits, Race Conditions bei Berechtigungsprüfungen, unsichere Abhängigkeiten.

Der Grund liegt in der Natur der Aufgabe. Feature-Entwicklung arbeitet gegen eine Spezifikation, Security arbeitet gegen einen Gegner, der die Spezifikation gerade nicht einhält. Ein Agent, der darauf optimiert, dass die gewünschte Funktion entsteht, hat diesen Gegner nicht im Blick, solange ihn niemand explizit einführt.

Daraus folgt nicht, dass AI Coding unsicher sein müsste. Es folgt, dass AI-generierter Code denselben Security-Prozessen unterliegen muss wie menschlich geschriebener — und angesichts der höheren Änderungsgeschwindigkeit eher strengeren: statische Analyse, Dependency-Prüfung, Secret Scanning, Security Reviews der kritischen Pfade, Penetrationstests vor dem Produktivgang.

Warum nimmt die Komplexität mit der Systemgröße zu?

Weil große Systeme nicht an einzelnen Komponenten schwierig werden, sondern an deren Zusammenspiel. Ein Service kann vollständig korrekt sein und trotzdem Teil eines fehlerhaften Gesamtsystems werden.

Die typischen Komplexitätsquellen sind bekannt und lassen sich aufzählen: verteilte Systeme, Eventual Consistency, Message Queues, konkurrierende Schreibzugriffe, Caches, externe APIs, Netzwerkfehler, Timeouts, Retries, asynchrone Jobs, mehrere Datenbanken, Legacy-Systeme, Berechtigungsmodelle.

Der schwierige Teil ist selten die Implementierung einer einzelnen dieser Komponenten. Der schwierige Teil ist das Verhalten des Gesamtsystems bei ungewöhnlichen Kombinationen von Zuständen — und genau dort wird das Beispiel konkret.

Beispiel: ein Zahlungsvorgang

Ein Agent implementiert: Nutzer klickt auf „Bezahlen“, der Payment Provider wird aufgerufen, die Bestellung wird als bezahlt markiert. Der Happy Path funktioniert, der Test ist grün, die Seite lässt sich öffnen. Ein produktionsreifes System muss zusätzlich beantworten:

• Was passiert, wenn der Payment Provider antwortet, aber die Datenbank nicht?
• Was passiert bei einem Timeout?
• Was passiert, wenn ein Webhook zweimal ankommt?
• Was passiert, wenn zwei Prozesse gleichzeitig dieselbe Bestellung bearbeiten?
• Was passiert, wenn eine Rückerstattung während eines Retries ausgelöst wird?
• Wie wird Idempotenz sichergestellt, und wie wird der Zustand später auditiert?

Diese Eigenschaften sind nicht einfach mehr Code. Sie sind Systeminvarianten — Aussagen darüber, was unter allen Umständen gelten muss. Sie entstehen aus einer Entscheidung, nicht aus einer Implementierung.

Warum Agenten hier an Grenzen stoßen

Coding Agents brauchen Feedback, um zu erkennen, ob eine Entscheidung richtig war. In großen Systemen treten die relevanten Fehler aber erst unter Last auf, nach Stunden oder Tagen, bei seltenen Race Conditions, bei partiellen Infrastrukturausfällen, bei ungewöhnlichen Daten, bei bestimmten Deployment-Reihenfolgen oder im Zusammenspiel mehrerer Dienste. Dieses Feedback steht während der Entwicklung schlicht nicht zur Verfügung.

Warum beschleunigt AI gute und schlechte Engineering-Prozesse gleichermaßen?

Weil AI die Änderungsrate erhöht, nicht die Prüfrate. Ein Team mit sauberer Architektur, guten Tests, schneller CI und belastbarer Observability wird dadurch erheblich schneller. Ein Team mit schwachen Tests, unklarer Architektur und manuellen Deployments erzeugt technische Schuld schneller als zuvor.

Höhere Änderungsgeschwindigkeit bedeutet zwangsläufig mehr Deployments, mehr Code, mehr Abhängigkeiten und mehr mögliche Regressionen. Ob daraus Tempo oder Chaos wird, entscheidet nicht das Werkzeug, sondern das System, in dem es eingesetzt wird.

Damit verschiebt sich auch die strategische Frage. Sie lautet nicht, wie viel Code AI schreiben kann — die Antwort darauf wird jedes Quartal größer. Sie lautet: Kann unsere Engineering-Organisation die zusätzliche Änderungsgeschwindigkeit sicher aufnehmen?

AI erhöht die Änderungsrate. Die Organisation muss ihre Prüfrate entsprechend erhöhen — sonst wächst nur der Abstand zwischen dem, was ausgeliefert wird, und dem, was verstanden ist.

Warum braucht kritische IT unabhängige Kontrollmechanismen?

Weil das Risiko nicht darin liegt, dass AI Code schreibt, sondern darin, dass dieselbe probabilistische Instanz gleichzeitig Erzeuger, Tester, Reviewer und Entscheider ist. Das erzeugt einen geschlossenen Validierungskreislauf ohne unabhängige Kontrolle.

Kritische Infrastruktur — FinTech, Gesundheitswesen, Industrie, Energie, öffentliche Verwaltung, Versicherungen, Identitäts- und Zugriffsverwaltung — sollte nicht auf einem Prozess beruhen, in dem ein Agent die Anforderungen selbst interpretiert, die Architektur selbst entscheidet, den Code selbst schreibt, die Tests selbst definiert, die Ergebnisse selbst bewertet und anschließend ohne unabhängige Kontrolle in Produktion deployt.

Das ist ausdrücklich kein Argument gegen den Einsatz. Codevorschläge, Refactorings, Testgenerierung, statische Analyse, Dokumentation, Migrationen, Code Reviews, Incident-Analyse, Debugging und die Suche in großen Repositories sind auch in kritischen Systemen sinnvolle Einsatzfelder. Abgesichert sein muss die Produktionsfreigabe — durch deterministische und organisatorisch verantwortete Kontrollen.

Verantwortung lässt sich nicht delegieren

Produktionssysteme leben über Jahre und brauchen Entscheidungen, die weit über einen einzelnen Prompt hinausreichen: Warum wurde Technologie A statt B gewählt? Welche Zusage wurde vertraglich gegeben? Welche Daten dürfen gespeichert werden? Wer entscheidet beim Abwägen zwischen Performance und Konsistenz? Wer verantwortet einen Incident? Wann wird ein System neu gebaut statt weiter gepatcht?

Für kritische Systeme muss deshalb benannt sein, wer die Architektur besitzt, wer Änderungen genehmigt, wer Security verantwortet, wer in Bereitschaft ist, wer über Rollbacks entscheidet und wer Restrisiken akzeptiert. Ein Agent kann in jedem dieser Schritte mitarbeiten — eine Verantwortungsstruktur ersetzt er nicht.

Warum Benchmarks die Frage nicht beantworten

Coding-Benchmarks messen klar abgegrenzte Aufgaben in vorhandenen Repositories, mit definierten Testumgebungen, begrenzten Zeithorizonten und messbaren Erfolgsbedingungen. Produktionssysteme enthalten zusätzlich widersprüchliche und unbekannte Anforderungen, Stakeholder-Entscheidungen, regulatorische Vorgaben, Legacy-Systeme, organisatorische Abhängigkeiten, Betrieb über Jahre, Incident Response, reale Angreifer und unvorhersehbare Nutzer.

Dazu kommt die Zuverlässigkeitsfrage. Für kritische IT ist ein System, das eine Aufgabe in 70, 80 oder 90 Prozent der Fälle korrekt erledigt, nicht automatisch ausreichend — entscheidend ist nicht, ob eine Aufgabe lösbar ist, sondern mit welcher Wahrscheinlichkeit eine ganze Klasse von Aufgaben zuverlässig gelöst wird, und wie das System sich in den übrigen Fällen verhält.

Die relevante Grenze moderner Coding Agents ist nicht mehr Capability, sondern Reliability. Der Agent darf Teil des Software-Lifecycle sein. Er sollte nicht der Software-Lifecycle sein.

Das Zielbild: probabilistische Generierung, deterministische Verifikation

Die belastbare Antwort ist weder hundert Prozent menschlich noch hundert Prozent autonom. Sie lautet: AI darf schnell und kreativ arbeiten, und das System um sie herum muss streng sein. Qualität entsteht dann nicht daraus, dass dem Modell vertraut wird, sondern daraus, dass Fehler erkannt und begrenzt werden.

Praktisch heißt das, die Verifikation genauso zu automatisieren wie die Generierung. Eine Pipeline, die diesem Modell folgt, sieht etwa so aus:

1. fachliche Anforderung
2. formalisierte Acceptance Criteria
3. AI erzeugt die Implementierung
4. statische Analyse
5. Unit Tests
6. Contract Tests
7. Integrationstests
8. Security Scans
9. Prüfung der Architekturregeln
10. menschliches oder unabhängiges Review
11. Staging
12. Observability-Checks
13. kontrolliertes Deployment
14. automatische Rollback-Kriterien
15. Monitoring in Produktion

Auffällig an dieser Liste ist, wie wenig sie mit AI zu tun hat. Bis auf Schritt drei ist sie das, was gutes Engineering seit Jahren ausmacht. Der Unterschied liegt in der Dringlichkeit: Was bei zehn Deployments im Monat noch manuell tragbar war, muss bei hundert automatisiert und beweisbar sein.

AI Coding löst das Problem der Codeproduktion. Production Engineering löst das Problem des Vertrauens. Die richtige Konsequenz ist deshalb nicht, AI Coding zu verbieten — sondern es zu industrialisieren.