Verifikation in einer Software Factory

Generierung verschiebt den Engpass

Codegenerierung kann Anzahl und Umfang der Änderungen erhöhen, die in ein Delivery-System gelangen. Review, Integration und Produktentscheidungen gewinnen nicht automatisch dieselbe Kapazität.

Das Ergebnis ist eine Warteschlange. Pull Requests warten länger, Checks laufen häufiger und Menschen erhalten mehr plausiblen Output, als sie beurteilen können. Eine Factory muss die Verifikation verbessern, bevor sie die Autonomie erhöht.

Deterministische Gates belegen feste Fakten

Builds, Typprüfungen, Linter, Tests, Schemaprüfungen, Sicherheitsscans und Policy-Regeln beantworten begrenzte Fragen. Dieselbe Eingabe sollte dasselbe Urteil erhalten.

Diese Gates funktionieren am besten, wenn sie einen Vertrag schützen, der vor der Implementierung bestand. Ein Test, der erst nach der Änderung entsteht, kann dasselbe Missverständnis wie der Code enthalten. Wo das Risiko es rechtfertigt, sollte die Akzeptanzevidenz unabhängig bleiben.

Nützliche unabhängige Evidenz kann ein bestehender API-Vertrag, ein aufgezeichneter Verhaltensvergleich, ein Golden Output, eine unveränderliche Eigenschaft oder ein End-to-End-Szenario außerhalb der Implementierungsaufgabe sein.

Agenten-Review hat eine andere Aufgabe

Agenten können Absicht, Architektur, Sicherheit, Wartbarkeit und fehlende Tests in einem Umfang prüfen, den eine einzelne Person nicht bewältigt. Ihr Urteil bleibt probabilistisch. Mehrere Reviewer können dieselbe falsche Annahme wiederholen oder die Korrekturschleife mit breiten Vorschlägen überlasten.

Eine produktive Review-Stufe braucht eine gemeinsame Schweregrad-Sprache 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 dasselbe Budget wie ein gebrochener Vertrag verbrauchen.

Review-Schleifen brauchen außerdem eine Abbruchbedingung. Wenn eine Schleife nach wenigen Versuchen nicht konvergiert, hat sie Unsicherheit gefunden und keine Einladung, unbegrenzt Tokens auszugeben.

Grün bedeutet nicht korrekt

Eine Änderung kann alle automatisierten Prüfungen bestehen und trotzdem das falsche Problem lösen. Sie kann Sicherheitseigenschaften erhalten, aber das nützliche Verhalten verfehlen. Sie kann Unit- und Integrationstests bestehen und dabei eine Produktentscheidung einführen, die niemand beabsichtigt hat.

Menschen bleiben für die Absicht und für das Resturteil verantwortlich, das Gates nicht codieren können. Die Factory sollte die Arbeit sichtbar machen, die diese Aufmerksamkeit verdient, statt Menschen jede generierte Zeile lesen zu lassen.

Gates folgen Reversibilität und Auswirkung

Nicht jede Änderung verdient denselben Prozess.

Ein lokales Refactoring ohne öffentlichen Vertrag lässt sich günstig rückgängig machen. Datenbankschema, öffentliche API, Berechtigungsgrenze oder Produktionsdatenmigration werden teuer, sobald andere Systeme davon abhängen. Menschliche Aufmerksamkeit gehört dorthin, wo eine falsche Entscheidung schwer umkehrbar ist.

Daraus entstehen praktische Betriebsmodi. Arbeit mit niedrigem Risiko kann automatisierte Gates durchlaufen und mergen. Folgenreichere Arbeit kann einen genehmigten Plan, einen geprüften Vertrag oder eine Person beim Deployment verlangen. Die Organisation verantwortet diese Grenzen.

Die Factory muss lesbar sein

Agenten brauchen Zugriff auf den Anwendungszustand, den sie beurteilen sollen. OpenAI beschreibt, wie Benutzeroberflächen, Logs, Metriken und Traces für Codex in isolierten Worktrees lesbar gemacht wurden. So konnten Agenten Fehler reproduzieren und Laufzeitverhalten prüfen, statt beim Quellcode aufzuhören.

Jeder Lauf sollte Evidenz hinterlassen: ursprüngliche Absicht, Plan, Änderungen, Gate-Ergebnisse, Review-Findings, Deployment-Zustand und Kosten. Aus einem wiederkehrenden Fehler kann dann eine dauerhafte Regel oder ein Test werden.

Die Verifikationskapazität bestimmt die sichere Geschwindigkeit der Factory. Mehr Agenten helfen nur, wenn das Evidenzsystem mithält.