Code-Audit mit Claude Opus 5.5: Jeden Befund vor dem Merge verifizieren

Claude Opus 5.5 prüft Ihr Repository mehrere Stunden lang und liefert Dutzende „kritische“ Befunde, vielleicht sogar einen großen Patch. Die eigentliche Arbeit beginnt danach: Welche Fehler existieren wirklich, welche Änderung passt zur bestehenden Architektur und was kann sicher gemergt werden?

Dieser Ablauf behandelt Modellausgaben als zu prüfende Audit-Hypothesen, nicht als Ergebnisse. Zuerst frieren Sie eine reproduzierbare Baseline ein. Danach muss jeder akzeptierte Befund Reproduktions-, Risiko-, Architektur-, Fix- und Regressions-Gates bestehen.

Opus 5.5 erweitert den Audit-Radius, genehmigt aber keinen Merge

Das Modell ist für breite, lang laufende Audits plausibel, aber kein unabhängiger Reviewer. Anthropic nennt in der Ankündigung vom 22. September 2026 repositoryweite Migrationen und Audits ausdrücklich als Stärke und veröffentlicht Ergebnisse aus internen Tests sowie von frühen Testern. Solche Herstellerangaben garantieren nicht dasselbe Ergebnis in Ihrem Projekt. Anthropics Opus-5.5-Ankündigung.

Kent C. Dodds veröffentlichte zudem einen Audit-Prompt für Sicherheit, Performance, Barrierefreiheit, Wartbarkeit, Skalierbarkeit, Architektur, Dokumentation, Tests und Automatisierung. Er schrieb, Opus 5.5 habe ein erhebliches Sicherheitsproblem gefunden, das andere Modelle übersahen. Der Beitrag nennt jedoch weder den Fehler noch Reproduktionsschritte oder einen kontrollierten Vergleich. Das ist ein Grund, den Ablauf zu testen, aber kein Grund, auf Verifikation zu verzichten. Öffentlicher Beitrag.

Das Ziel lautet daher: möglichst viele reproduzierbare, eingestufte und unabhängig prüfbare Befunde — nicht möglichst viele Warnungen.

Definieren Sie Erfolg vor dem Audit als ausführbare Befehle

Ohne saubere Baseline lässt sich ein späterer Fehler nicht als Altlast oder neue Regression einordnen. Speichern Sie Commit-SHA, Umgebung, wichtige Versionsstände, exakte Befehle und Exit-Codes.

Ersetzen Sie die Platzhalter durch die tatsächlichen Projektbefehle. Ist ein Gate nicht relevant, markieren Sie es als „nicht anwendbar“, statt eine Scheinprüfung zu erfinden.

git status --short
<install-command>
<lint-command>
<type-check-command>
<unit-test-command>
<integration-test-command>
<build-command>

Die Baseline sollte mindestens enthalten:

• Commit-SHA, Runtime, Paketmanager und wesentliche Abhängigkeiten;
• Befehl, Arbeitsverzeichnis, Exit-Code und kurze Fehlerausgabe;
• bekannte Fehlschläge, flakige Tests und befristete Ausnahmen;
• freigegebene Verzeichnisse sowie Dateien, die nicht geändert werden dürfen, etwa generierter Code, historische Migrationen, Lockfiles oder vendorte Quellen;
• kritische Pfade wie Authentifizierung, Autorisierung, Abrechnung, Datenmigration und externe API-Verträge.

Ist die Baseline bereits rot, wird der Fehler zuerst behoben, isoliert oder als bekannt erfasst. Ein alter Fehler darf nicht als neue Entdeckung erscheinen.

Fordern Sie zuerst einen Audit ohne Dateiänderungen an

Untersuchung und Behebung müssen getrennte Phasen sein. Ändert das Modell schon während der Suche Code, kann ein neuer Fehler aus dem Ausgangscode, dem ersten Patch oder dem Zusammenspiel mehrerer Patches stammen.

Ein sinnvoller Start-Prompt lautet:

Führe einen lang laufenden Audit dieses Repositorys durch. In dieser Phase nur untersuchen und berichten; keine Dateien ändern.

Umfang: <Verzeichnisse, Services, Sprachen und kritische Geschäftsabläufe>
Ausschlüsse: <generierte Dateien, Fremdcode, historische Migrationen, nicht erreichbare Systeme>
Baseline: <ausgeführte Befehle, Exit-Codes und bekannte Fehler>

Prüfe:
1. Sicherheit und Autorisierungsgrenzen;
2. Korrektheit, Nebenläufigkeit, Transaktionen und Fehlerbehandlung;
3. Performance und Ressourcenverbrauch;
4. Barrierefreiheit, sofern relevant;
5. Wartbarkeit und Skalierbarkeit;
6. Architektur und Modulgrenzen;
7. Lücken in Dokumentation, Tests und Automatisierung.

Für jeden Befund angeben:
- eindeutige ID und kurzen Titel;
- Schweregrad und Begründung der Auswirkung;
- betroffene Dateien, Symbole und genaue Zeilen;
- Auslöser, erwartetes und tatsächliches Verhalten;
- reproduzierbaren Befehl oder minimalen Test;
- Zusammenfassung der Ausgabe und Exit-Code;
- mögliche False-Positive-Erklärung;
- kleinste Behebungsrichtung;
- erforderliche Prüfungen nach dem Fix;
- Konfidenz: hoch, mittel oder niedrig.

Regeln:
- Nicht ausgeführte Befehle als NICHT AUSGEFÜHRT markieren.
- Nicht reproduzierbare Befunde als NICHT VERIFIZIERT markieren.
- Tests niemals löschen, überspringen oder abschwächen, um Grün zu erhalten.
- Bei fehlenden Zugangsdaten, Diensten oder Abhängigkeiten stoppen und die Lücke nennen.
- Am Ende jeder Phase die Statustabelle aktualisieren und auf Review warten.

Der Prompt garantiert keine Regelbefolgung. Prüfen Sie Terminalprotokolle, Diffs und echte Testausgaben. Er sorgt lediglich dafür, dass ein vages „hier könnte etwas sein“ nicht sofort in die Fix-Warteschlange gelangt.

Teilen Sie die lange Aufgabe in vier kontrollierte Phasen

Eine lange Laufzeit darf nicht unbegrenzten Umfang oder Rechte bedeuten. Halten Sie nach jeder Phase an.

Phase 1: Systemkarte erstellen

Das Modell liest Code, Konfiguration, Tests und Architekturunterlagen und liefert Einstiegspunkte, Vertrauensgrenzen, Datenflüsse, externe Abhängigkeiten und Hochrisikopfade. Es ändert nichts und verfolgt keine Bug-Quote.

Phase 2: Kandidaten sammeln

Jeder Kandidat verweist auf konkreten Code und einen Auslöser. Allgemeine Verbesserungshinweise ohne Ort oder Szenario zählen nicht als Defekt.

Phase 3: Einen Befund nach dem anderen reproduzieren

Beginnen Sie mit hohem potenziellem Schaden und geringer Prüfkosten. Ein Experiment prüft eine Hypothese. Rohdaten und Umgebungsparameter bleiben erhalten.

Phase 4: Behebungsplan erstellen

Nur reproduzierte Defekte gelangen in den Plan. Er nennt Minimaländerung, Kompatibilitätsauswirkung, Migrationsrisiko, Rollback und obligatorische Gates. Architekturkonflikte entscheidet zuerst der Code Owner.

Der Status kann in audit-plan.md stehen:

ID	Status	Risiko	Reproduktionsbeleg	Architekturentscheidung	Branch	Freigabe
AUD-001	Reproduktion ausstehend	Hoch	Noch keiner	Nicht geprüft	—	—

Erlauben Sie nur den klaren Pfad Kandidat → Reproduktion ausstehend → reproduziert → Architektur geprüft → behoben → akzeptiert. Selbstsichere Formulierungen ersetzen keinen Statuswechsel.

Risiko-Gate: Schweregrad und Konfidenz getrennt erfassen

Der Schweregrad beschreibt den möglichen Schaden, die Konfidenz die Belegqualität. Ein möglicher Autorisierungs-Bypass kann hohen Schaden, aber geringe Konfidenz haben. Ein reproduzierbarer Tippfehler im Log kann hohe Konfidenz und geringe Auswirkung haben.

Stufe	Wann passend	Mindestbeleg vor der Behebung
Kritisch	Breite Rechteausweitung, sensible Datenoffenlegung, irreversible Korruption oder Ausfall eines Kerndienstes	Kontrollierte Reproduktion, klarer Wirkungsradius, sofortiger Owner-Review
Hoch	Kritischer Geschäftsablauf betroffen oder realistische Eingabe löst den Fehler stabil aus	Minimalreproduktion, fehlschlagender Test oder Befehlsausgabe, Owner-Bestätigung
Mittel	Begrenzte Auswirkung, Workaround oder seltene Bedingungen	Wiederholbarer Beleg und Priorisierungsentscheidung
Niedrig	Lokale Qualität, Dokumentation, Wartbarkeit oder unkritische Performance	Konkreter Codebeleg und Nutzen über Regressionsrisiko

Das Modell kann Codepfade verfolgen, kennt aber Datensensibilität, Kundenversprechen, tolerierbare Ausfallzeiten und Kompatibilitätsregeln nicht automatisch. Diese Bewertung braucht verantwortliche Menschen.

Reproduktions-Gate: Aus jedem Befund eine fehlschlagende Prüfung machen

Verdächtiger Code genügt nicht. Eine Prüfung muss vor dem Fix fehlschlagen und danach bestehen. Klären Sie für jeden Befund:

1. In welchem Commit und welcher Umgebung tritt er auf?
2. Was ist die kleinste auslösende Eingabe?
3. Woraus folgt das erwartete Verhalten — Test, Spezifikation, Vertrag oder Geschäftsregel?
4. Was geschah tatsächlich, und wo liegt die Roh-Ausgabe?
5. Weshalb fanden vorhandene Tests den Fehler nicht?
6. Könnte eine legitime Designentscheidung oder Umgebungsabweichung das Verhalten erklären?

Der beste Beleg ist ein minimaler Regressionstest. Ist Automatisierung nicht praktikabel, dokumentieren Sie deterministische Schritte, erwartete Beobachtungen und Aufräumen. Sicherheitsbefunde werden nur in eigenen oder ausdrücklich autorisierten, möglichst lokalen oder isolierten Umgebungen reproduziert.

Behauptet das Modell, einen Befehl ausgeführt zu haben, verlangen Sie vollständigen Befehl, Arbeitsverzeichnis, Exit-Code und relevante Ausgabe. Eine Zusammenfassung ist kein Ausführungsbeleg.

Architektur-Gate: Verstehen, weshalb der bestehende Code so gebaut ist

Eine sauberere Lösung kann Kompatibilität, Deployment-Reihenfolge oder eine absichtliche Grenze brechen. Vor breiten Refactorings prüfen Sie ADRs, Designdokumente, API-Verträge, Migrationszwänge und Historie.

Bei nutzbarer Git-Historie helfen:

git log -- <path>
git blame -L <start>,<end> <file>
git show <commit> -- <path>

Das Modell muss beantworten:

• Welche Einschränkung schützt das heutige Design?
• Welche Aufrufer, Datenformate oder Deployment-Schritte hängen davon ab?
• Behebt die Änderung einen Defekt oder ändert sie Produktverhalten?
• Reicht eine kleinere lokale Änderung?
• Müssen beim Rollback Code, Konfiguration oder Daten zurückgesetzt werden?

Historie liefert Hinweise, keine perfekte Absichtserklärung. Fehlt eine Begründung, markieren Sie „Architekturabsicht unbekannt“ und fragen einen Maintainer.

Fix-Gate: Ein reproduzierter Defekt pro kleinem Patch

Akzeptieren Sie keinen Mega-Patch für viele unabhängige Befunde. Fügen Sie zuerst einen Test hinzu, der auf dem alten Stand fehlschlägt, und implementieren Sie danach die kleinste Behebung.

Gate	Anforderung	Bei Fehlschlag
Umfang	Diff betrifft nur den genehmigten Befund	Fremde Änderungen abtrennen
Regression	Vorher rot, nachher grün	Test korrigieren oder Befund neu bewerten
Statisch	Format, Lint und Typprüfung bestehen	Neue Fehler nicht global ausnehmen
Projekt	Relevante Unit-, Integrations- und Build-Prüfungen bestehen	Ersten neuen Fehler klären, bevor weitere Patches folgen
Architektur	Owner bestätigt Grenzen und Kompatibilität	Umfang verkleinern oder Design-Review eröffnen
Human Review	Fehlerpfade, Rechte, Datenänderungen und Löschungen geprüft	Jede auffällige Änderung erklären

Falsche Erfolge sind abzulehnen: Assertions löschen, Tests überspringen, Exceptions verschlucken, Validierung schwächen, Retries zum Verdecken von Race Conditions erhöhen oder den ursprünglichen Defekt durch Großrefactoring unkenntlich machen.

Regressions-Gate: Projektdefinierte Prüfungen statt Modellauswahl

Die finale Freigabe verwendet vorhandene Skripte oder CI. Vergleichen Sie den vollständigen Ausgangslauf mit dem Endstand und bestätigen Sie, dass der neue Regressionstest ohne Patch fehlschlägt.

Prüfen Sie außerdem Lockfiles, Migrationen, öffentliche APIs und Standardkonfigurationen. Performance-Aussagen benötigen dieselbe Umgebung und Eingabe. Einen flakigen Test nicht bis zum ersten Grün wiederholen: Muster erfassen, Ursache isolieren und prüfen, ob der Patch die Instabilität verstärkt.

Verwerfen Sie das Ergebnis bei einem dieser Warnzeichen

• Exakter Ort, Auslöser oder prüfbarer Beleg fehlen.
• Ein nicht ausgeführter Befehl wird als bestanden gemeldet.
• Der Schweregrad hat keinen nachvollziehbaren Wirkungspfad.
• Der Patch verlässt den genehmigten Umfang oder baut Architektur ungefragt um.
• Tests werden gelöscht, übersprungen oder abgeschwächt, Fehler verschluckt.
• Die Änderung widerspricht ADR, Vertrag oder Migration ohne Freigabe.
• Es gibt nur eine Abschlusszusammenfassung, aber keine Befehle und keinen prüfbaren Diff.
• Eine Sicherheitsbehauptung stützt sich nur auf Zustimmung eines zweiten Modells.

Ein weiteres Modell kann Gegenbeispiele suchen, aber Modellkonsens ist kein unabhängiger Beleg. Unabhängige Validierung kommt aus Tests, Laufzeitausgaben, Historie, Spezifikationen und verantwortlicher menschlicher Entscheidung.

Finale Checkliste vor dem Merge

• Umfang, Ausschlüsse und Baseline-Commit sind eingefroren.
• Baseline-Befehle und Exit-Codes sind gespeichert.
• Jeder akzeptierte Befund hat ID und genaue Codeposition.
• Schweregrad und Konfidenz sind getrennt dokumentiert.
• Der Defekt ist per Test oder deterministischem Verfahren reproduziert.
• Architekturabsicht, Kompatibilität und Rollback sind geprüft.
• Jeder Befund entspricht einem kleinen, reviewbaren Patch.
• Der Regressionstest schlägt vorher fehl und besteht nachher.
• Vollständige Projekt-Gates laufen über bestehende Skripte oder CI.
• Ein Code Owner prüft den finalen Diff und stimmt ausdrücklich zu.

Die öffentlichen Berichte machen Opus 5.5 zu einem glaubwürdigen Kandidaten für große, lang laufende Audits und deuten darauf hin, dass das Modell übersehene Probleme finden kann. Sie ersetzen keine Verifikation. Der kleinste sinnvolle nächste Schritt ist eine saubere Baseline und eine erste Runde „nur Audit, keine Änderungen“.