Menschliches Review bleibt bis zu ausreichenden automatischen Prüfungen verpflichtend

Beobachtung des Nutzers

Im beschriebenen Entwicklungsprozess ist menschliches Code-Review am 23. August 2026 verpflichtend. Es soll erst entfallen können, wenn ausreichende automatische Prüfungen etabliert sind. Was als ausreichend gelten würde, ist noch nicht explizit definiert.

Bereits eingesetzt werden:

• Sonar für statische Codeanalyse;
• Unit Tests;
• Integrationstests;
• End-to-End-Tests;
• automatisierte Prüfung auf geleakte Secrets.

Die Beobachtung beschreibt das Vorhandensein dieser Kontrollarten, nicht ihre Abdeckung, Zuverlässigkeit oder tatsächliche Fehlerfindungsrate.

Wahrgenommene Wirksamkeit des menschlichen Reviews

Nach Erfahrung des Nutzers unterscheidet sich die Reviewqualität deutlich zwischen Reviewern und Fehlerklassen:

• Architektur- und Wartbarkeitsprobleme werden häufig angesprochen.
• Probleme bei Datenmigrationen werden oft erkannt, aber ebenfalls häufig übersehen.
• Versteckte Race Conditions, Performanceprobleme und Deadlocks werden eher übersehen.
• Inhaltliche Diskrepanzen werden teilweise erkannt.
• Bei großen Merge Requests und Änderungen, die mehrere Themen vermischen, sinkt die wahrgenommene Erkennungsrate massiv.

Dies ist eine qualitative Erfahrung ohne gemessene Erkennungsraten oder kontrollierten Vergleich. Sie legt nahe, menschliches Review nicht als einheitliches Orakel zu behandeln und die Prüfbarkeit einer Änderung selbst als Assurance-Eigenschaft zu untersuchen. Die externe Analyse gescheiterter agentischer Pull Requests verbindet große Änderungen ebenfalls mit geringerem Integrationserfolg, misst jedoch nicht dieselbe Review-Erkennungsrate und bestätigt die lokale Beobachtung daher nur indirekt.

Große Änderungen entstehen nach Einschätzung des Nutzers sowohl durch Features, die trotz kleiner Außenwirkung mehrere Services betreffen, als auch durch unzureichenden fachlichen oder technischen Zuschnitt. Als Hauptanreiz für Bündelung nennt er die Absicht, die aufwendigen Schritte Review, Test und Deployment nur einmal auszuführen. Daraus entsteht die ungeprüfte These, dass hohe Änderungskosten große Batches fördern.

Vorläufige Einordnung

Die vorhandenen Kontrollen liefern eine wichtige deterministische Basis. Aus ihrer bloßen Existenz folgt jedoch noch keine ausreichende Assurance. Offen sind insbesondere fachliche Korrektheit jenseits vorhandener Tests, Architektur- und Wartbarkeitsfolgen, missbrauchbare Berechtigungs- und Datenflüsse, Abhängigkeiten und Supply Chain sowie Betriebs- und Rolloutrisiken.

Der Praxisbeitrag zum Agentic Engineer argumentiert für Tests, Linter, Architekturregeln und CI als kontinuierlich verbesserten Harness, liefert aber keine allgemeine Suffizienzschwelle. SecRepoBench zeigt in einem begrenzten C/C++-Benchmark, dass funktionale und sichere Korrektheit gemeinsam schwierig bleiben. Diese Quellen begründen die offene Assurance-Frage, beantworten sie aber nicht für das betrachtete System.