Production Readiness in der AI Factory: Was man prüft, wenn Agenten den Code schreiben

Nehmen wir an, die Umgebung ist bereits so, wie viele sie gerade bauen. Die Requirements sind nicht mehr als Fließtext im Ticket abgelegt, sondern so strukturiert, dass ein Agent damit arbeiten kann: Akzeptanzkriterien, Domänenbegriffe, Beispiele. Es gibt ein gepflegtes arc42, ein Domänenmodell, ein Protokoll der Architekturentscheidungen. Agenten implementieren, schlagen vor, refaktorieren, entscheiden im Kleinen. Die Pipeline ist grün, bevor jemand hinschaut.

In dieser Welt ist die klassische Frage vor dem Deployment — läuft es, sind die Tests grün, gibt es ein Rollback — weitgehend trivial geworden. Sie wird automatisch beantwortet, oft besser als vorher. Was nicht trivial geworden ist: Woran erkennen wir, dass eine Änderung stimmt, wenn niemand mehr jede Zeile gelesen hat?

Das ist keine Frage an die Technik. Es ist die Frage, die ein Auditor, ein Großkunde oder ein Gericht später stellen wird — und die man nicht rückwirkend beantworten kann.

Fünf Bereiche, die dann zählen. Jeweils die Frage und das, was Sie danach vorlegen können.

1. Herkunft: Woher kommt diese Änderung?

Ein Commit-Hash mit einem Namen daneben war die Antwort, solange ein Mensch den Code geschrieben hat. Jetzt steht dort ein Agent, und der Name daneben ist der der Person, die den Merge-Button gedrückt hat.

Die relevanten Fragen: Welcher Kontext lag vor — welche Version des Requirements, welcher Ausschnitt des Domänenmodells? Welches Modell in welcher Version? Welche Vorgabe hat den Lauf ausgelöst? Und: Ist das in sechs Monaten noch rekonstruierbar, wenn das Modell längst ersetzt wurde?

Was Sie vorlegen können: eine unveränderliche Spur je Änderung — Auslöser, Kontextstand, Modellversion, Ergebnis, Freigabe. Wer den Ereignisstrom als Fundament schon für fachliche Vorgänge nutzt, kennt das Muster; hier gilt es für den Entwicklungsprozess selbst. Mehr dazu unter Event Sourcing.

2. Der Kontext ist jetzt ein Produktionsartefakt

Solange arc42, Glossar und Entscheidungsprotokoll Dokumentation waren, war ihr Veralten ärgerlich. Jetzt sind sie Input. Ein veraltetes Domänenmodell erzeugt kein Missverständnis mehr, sondern Code — konsistent, schnell und falsch.

Fragen: Wer pflegt diese Artefakte, und ist das eine benannte Zuständigkeit oder ein guter Vorsatz? Wie merken Sie, dass die Erzeugung von der fachlichen Realität wegdriftet? Gibt es einen Moment, in dem die Fachseite bestätigt, dass das Modell noch stimmt?

Was Sie vorlegen können: ein versioniertes Kontextpaket mit Änderungshistorie und einem Namen dahinter. Genau dafür ist Event Modeling nützlich: Es erzeugt ein Bild, auf das sich Fachbereich und Team gemeinsam einigen — und das ein Agent lesen kann.

3. Wo der Mensch entscheidet

Nicht jede Änderung braucht ein Review. Einige schon. Die entscheidende Arbeit besteht darin, diese Klassen zu benennen, bevor der erste Zwischenfall sie benennt.

Typische Kandidaten: alles, was Geld bewegt. Alles, was über Zugriff entscheidet. Alles, was personenbezogene Daten berührt. Alles, was unter eine Nachweispflicht fällt. Alles, was eine externe Zusage verändert.

Die eigentliche Frage ist nicht, ob es diese Grenze gibt, sondern wo sie verankert ist. Eine Absprache im Team hält, bis es eilig wird. Eine Grenze, die in der Pipeline erzwungen wird, hält auch dann.

Was Sie vorlegen können: eine Liste der eingriffspflichtigen Änderungsklassen, technisch durchgesetzt, mit protokollierten Freigaben.

4. Verhalten prüfen, nicht Implementierung

Wenn Code billig wird, verschiebt sich der Wert in die Testsuite. Und dort entsteht das subtilste Problem dieser Umgebung: Wenn derselbe Agent Implementierung und Test erzeugt, prüft der Test unter Umständen nur, dass die Implementierung tut, was sie tut.

Fragen: Beschreiben Ihre Tests das fachlich erwartete Verhalten in der Sprache der Domäne — oder spiegeln sie die Struktur des Codes? Kommen die Beispiele aus dem Fachbereich oder aus dem Modell? Gibt es Tests, die niemand ändern darf, ohne dass die Fachseite zustimmt?

Was Sie vorlegen können: eine Menge fachlich formulierter Akzeptanzszenarien, die aus dem Requirement stammen und nicht aus dem Code — der einzige Teil der Suite, dem man nach einer Generierung noch trauen kann.

5. Umkehrbarkeit und Tempo

Mehr Änderungen pro Woche heißt mehr Gelegenheiten, etwas Falsches auszuliefern. Das ist kein Argument gegen Tempo, aber eines für Umkehrbarkeit.

Fragen: Ist Zurücknehmen so billig wie Ausliefern? Merken Sie einen Fehler, bevor der Kunde ihn merkt — oder erst im Ticket? Wie klein ist die kleinste Änderung, die Sie einzeln zurückrollen können?

Was Sie vorlegen können: eine gemessene Zeit von der Auslieferung bis zur erkannten Abweichung, und eine getestete Rücknahme je Änderungseinheit. Das ist dieselbe Frage wie in der klassischen Production-Readiness-Betrachtung — nur zählt sie jetzt öfter am Tag.

Was dadurch nicht wegfällt

Der Betrieb. Die Bereitschaft. Die Frage, wer nachts angerufen wird. Und vor allem: die Verantwortung. Ein Agent kann eine Änderung erzeugen, aber nicht dafür geradestehen. Wer nach dem Go-live wirklich zuständig ist, entscheidet sich weiterhin an Personen, nicht an Werkzeugen — nachzulesen in Ownership statt Rollen.

Auch die Nachweispflicht verschwindet nicht. Sie wird strenger, weil die Menge der Änderungen steigt und der einzelne Mensch dahinter unschärfer wird.

Wann Sie das noch nicht brauchen

Wenn Agenten bei Ihnen heute Vorschläge machen, die ein Mensch vollständig liest, bevor sie mergen — dann ist Ihr bestehender Review der Kontrollpunkt und dieser Beitrag beschreibt eine Zukunft, nicht Ihre Gegenwart. Auch bei internen Werkzeugen ohne Geschäftsauswirkung ist der Aufwand nicht gerechtfertigt.

Der Punkt, an dem es kippt, ist gut erkennbar: Es ist der Tag, an dem der erste Merge stattfindet, dessen Diff niemand vollständig gelesen hat. Ab da braucht es die fünf Fragen oben.

Kurzfassung

In einer AI-getriebenen Entwicklungsumgebung verlagert sich Production Readiness von „läuft es?" zu „können wir belegen, wie es dazu kam?". Herkunft der Änderung, gepflegter Kontext, verankerte Entscheidungsgrenzen, fachlich formulierte Tests und billige Umkehrbarkeit sind die fünf Stellen, an denen sich das entscheidet. Alles davon ist eine Architekturfrage — und keine, die man zwei Wochen vor dem Deployment noch klären kann.