Verifikation in einer Software Factory

Generierung verschiebt den Engpass

Mit Codegenerierung können mehr und größere Änderungen in ein Delivery-System kommen. Review, Integration und Produktentscheidungen wachsen nicht von selbst im selben Tempo mit.

Es entsteht eine Warteschlange. Pull Requests liegen länger, Checks laufen öfter, und Menschen bekommen mehr plausiblen Output, als sie beurteilen können. Bevor eine Factory ihre Autonomie erhöht, muss sie besser verifizieren.

Deterministische Gates belegen feste Fakten

Builds, Typprüfungen, Linter, Tests, Schemaprüfungen, Sicherheitsscans und Policy-Regeln beantworten jeweils eine eng umrissene Frage. Bei derselben Eingabe sollten sie zum selben Urteil kommen.

Am stärksten sind sie, wenn sie einen Vertrag absichern, den es schon vor der Implementierung gab. Ein Test, der erst nach der Änderung geschrieben wird, kann dasselbe Missverständnis enthalten wie der Code. Wo das Risiko hoch genug ist, sollten die Belege für die Abnahme unabhängig von der Änderung bleiben.

Als unabhängiger Beleg taugt ein bestehender API-Vertrag, ein aufgezeichneter Verhaltensvergleich, ein Golden Output, eine Eigenschaft, die immer gelten muss, oder ein End-to-End-Szenario, das außerhalb der Implementierungsaufgabe gepflegt wird.

Agenten-Reviews haben eine andere Aufgabe

Agenten können Absicht, Architektur, Sicherheit, Wartbarkeit und fehlende Tests in einer Menge prüfen, die eine einzelne Person nicht schafft. Ihr Urteil bleibt trotzdem probabilistisch. Mehrere Reviewer können dieselbe falsche Annahme wiederholen oder die Korrekturschleife mit breiten Vorschlägen zuschütten.

Wer Agenten-Reviews in Produktion einsetzt, braucht eine gemeinsame Sprache für Schweregrade und einen begrenzten Auftrag. Kritische Findings können blockieren, Warnungen können Nacharbeit auslösen. Fragen gehören zu einer Person. Vorschläge sollten nicht aus demselben Budget bezahlt werden wie ein gebrochener Vertrag.

Review-Schleifen brauchen außerdem einen Punkt, an dem sie abbrechen. Konvergiert eine Schleife nach wenigen Versuchen nicht, hat sie Unsicherheit gefunden. Eine Einladung, unbegrenzt Tokens zu verbrennen, ist das nicht.

Grün heißt nicht korrekt

Eine Änderung kann jede automatisierte Prüfung bestehen und trotzdem das falsche Problem lösen. Sie kann Sicherheitseigenschaften wahren und trotzdem am nützlichen Verhalten vorbeigehen. Sie kann Unit- und Integrationstests bestehen und nebenbei eine Produktentscheidung treffen, die niemand beabsichtigt hat.

Die Absicht bleibt Sache der Menschen, ebenso das restliche Urteil, das die Gates nicht abbilden können. Die Factory sollte die Arbeit nach oben holen, die diese Aufmerksamkeit verdient, statt Menschen jede generierte Zeile lesen zu lassen.

Gates nach Umkehrbarkeit und Auswirkung

Nicht jede Änderung verdient denselben Prozess.

Ein lokales Refactoring ohne öffentlichen Vertrag lässt sich billig zurückdrehen. Ein Datenbankschema, eine öffentliche API, eine Berechtigungsgrenze oder eine Migration von Produktionsdaten wird teuer, sobald andere Systeme darauf aufbauen. Menschliche Aufmerksamkeit gehört dorthin, wo eine falsche Entscheidung schwer rückgängig zu machen ist.

Daraus ergeben sich Betriebsmodi für die Praxis. Arbeit mit niedrigem Risiko kann die automatisierten Gates durchlaufen und gemergt werden. Für riskantere Arbeit kann ein genehmigter Plan nötig sein, ein geprüfter Vertrag oder eine Person beim Deployment. Wo diese Grenzen liegen, verantwortet die Organisation.

Die Factory muss lesbar sein

Agenten müssen den Anwendungszustand sehen können, den sie beurteilen sollen. OpenAI beschreibt, wie Benutzeroberflächen, Logs, Metriken und Traces für Codex in isolierten Worktrees lesbar gemacht wurden. Damit konnten Agenten Fehler nachstellen und das Laufzeitverhalten prüfen, statt beim Quellcode aufzuhören.

Jeder Lauf sollte Belege hinterlassen: die ursprüngliche Absicht, den Plan, die Änderungen, die Gate-Ergebnisse, die Review-Findings, den Deployment-Zustand und die Kosten. Wiederholt sich ein Fehler, kann daraus eine dauerhafte Regel oder ein Test werden.

Wie viel eine Factory verifizieren kann, bestimmt, wie schnell sie sicher laufen kann. Mehr Agenten helfen nur, wenn das Evidenzsystem Schritt hält.