KI-Code-Prüfberichte
Zuletzt aktualisiert: 2026-07-02Lesezeit ca. 3 Min.
Ein KI-Code-Prüfbericht hält pro Run fest: was beabsichtigt war, was sich geändert hat, was mit welchem Ergebnis validiert wurde, was bewusst übersprungen wurde und was offen bleibt. Beim Code gespeichert, lesbar für Reviewer, Team und Zukunft.
Inhalt
Warum „es funktioniert“ nicht mehr reicht
Schreibt ein Mensch eine Änderung, führt man das Review-Gespräch mit jemandem, der sich erinnert, warum. Hat eine KI sie geschrieben, existiert diese Erinnerung nicht - der Prompt ist weg, die Begründung ist weg, und die Zusammenfassung stammt vom selben Modell, dessen Arbeit zur Debatte steht. Bei Sonar haben 53 % der Entwickler KI-Code erlebt, der korrekt aussieht, aber nicht zuverlässig ist - und „sieht korrekt aus“ ist genau das Problem, für das es Belege gibt.
Belege ersetzen Erinnerung durch einen Nachweis. Kein schwergewichtiges Dokument - eine kurze, strukturierte Antwort auf die fünf Fragen, die jeder Reviewer stumm stellt.
Die fünf Fragen, die ein Bericht beantwortet
- Auftrag - was sollte dieser Run tun, schriftlich, von vor dem Start?
- Änderung - was hat sich tatsächlich geändert, und blieb es innerhalb der deklarierten Grenzen?
- Validierung - welche Checks liefen (Tests, Typen, Lint, Build, gezielte Prüfungen), mit welchen Ergebnissen?
- Negativraum - was wurde bewusst nicht validiert, und warum? Der Teil, den keine selbstgeschriebene Zusammenfassung freiwillig nennt.
- Entscheidung - wer hat übernommen, in Kenntnis all dessen?
pruefbericht.mdtext/markdown
Sample - illustrativ, keine echten Run-DatenRun: 2026-07-02 · fix-rate-limit-headers
Auftrag: Korrekten Retry-After-Header bei 429-Antworten liefern
Grenzen: nur api/middleware/* · Rate-Limit-Logik unangetastet
Tool: Claude Code
Änderungen: 2 Dateien, +38 −7 (innerhalb der Grenzen ✓)
Validierung
✓ Unit-Tests (61 grün, 3 neu - vor dem Run geschrieben)
✓ Typprüfung, Lint, Build
✗ Lasttest - ÜBERSPRUNGEN: Staging nicht verfügbar
? Header hinter CDN - OFFEN, braucht manuellen Check
Entscheidung: FREIGEGEBEN von mk · Lasttest folgt vor dem ReleaseDas Format zählt weniger als die Disziplin: verankert in einem vorab aufgeschriebenen Auftrag, ehrlich bei Lücken, gespeichert dort, wo der Code lebt - nicht im Chat-Verlauf.
Von „es funktioniert“ zum Audit Trail: vier Beweisstufen
Dieselbe Änderung kann mit sehr verschiedenen Beweisstufen ankommen. Erst ab dem Prüfbericht abwärts bekommt ein Reviewer etwas, das er prüfen statt glauben kann - und der gewachsene Trail beantwortet die generelle Frage, die eine bloße Behauptung nie berührt.
| „es funktioniert” | Eine PR-Beschreibung | Ein Prüfbericht pro Run | Ein gewachsener Audit Trail | |
|---|---|---|---|---|
| Was er festhältDie Information, die das Artefakt wirklich über den Run trägt | Nichts Dauerhaftes - ein Status im Chatfenster, der wegscrollt.Redaktionelle Einordnung · 2026-07 | Eine nachträgliche Prosa-Zusammenfassung, die sagt, was ihr Autor erzählen wollte.Redaktionelle Einordnung · 2026-07 | Auftrag, Änderung, Validierungsergebnisse, Negativraum und Entscheidung - pro Run.Redaktionelle Einordnung · 2026-07 | Die Berichte pro Run über die Zeit, beim Code gespeichert, den sie beschreiben.Redaktionelle Einordnung · 2026-07 |
| Wer ihn verfasst hatWessen Darstellung der Änderung das ist | Der Agent, über die eigene Arbeit, im selben Atemzug wie die Änderung.Redaktionelle Einordnung · 2026-07 | Meist dasselbe Modell, das die Änderung machte - ungefragt zum Übersprungenen.Redaktionelle Einordnung · 2026-07 | Der Verifikations-Workflow, aus einem vor dem Run geschriebenen Auftrag.Redaktionelle Einordnung · 2026-07 | Das Team, als Nebenprodukt - niemand schreibt den Trail separat.Redaktionelle Einordnung · 2026-07 |
| Was ein Reviewer prüfen kannWas ein Reviewer daraus verifizieren kann, ohne die Arbeit neu herzuleiten | Nichts; der Reviewer liest wieder den nackten Diff.Redaktionelle Einordnung · 2026-07 | Die Erzählung, nicht den Run; der Negativraum ist, was die Zusammenfassung auslässt.Redaktionelle Einordnung · 2026-07 | Welche Checks mit welchem Ergebnis liefen - und, erstklassig, welche nicht.Redaktionelle Einordnung · 2026-07 | Wie das Team KI-gestützte Änderungen generell kontrolliert, nicht nur einen Run.Redaktionelle Einordnung · 2026-07 |
| Wo er zu kurz greiftDer Fehlermodus, der diese Stufe die Vertrauenslücke nicht schließen lässt | „sieht korrekt aus“ ist genau der Zustand, der sich später als nicht zuverlässig erweist.Redaktionelle Einordnung · 2026-07 | Kein Anker an einen vorab geschriebenen Auftrag, keine Validierungsergebnisse - nichts begrenzt sie.Redaktionelle Einordnung · 2026-07 | Nur so ehrlich wie der Workflow dahinter; ein Skip muss wirklich als Skip verzeichnet sein.Redaktionelle Einordnung · 2026-07 | Er beantwortet die generelle Frage, nicht die konkrete; er stützt ein Audit, ist aber keins.Redaktionelle Einordnung · 2026-07 |
Was Belege in der Praxis ändern
- Reviews werden schneller und tiefer zugleich - der Reviewer startet bei Auftrag und Validierungsstatus, statt beides aus dem Diff zu rekonstruieren.
- „Sah richtig aus“-Vorfälle werden nachvollziehbar - wenn etwas bricht, zeigt der Bericht, was geprüft war und was nicht. Aus Schuldfragen wird Prozessverbesserung.
- Ein Audit Trail entsteht nebenbei - Berichte pro Run summieren sich zur belastbaren Antwort auf „wie kontrolliert euer Team KI-gestützte Änderungen?“ - eine Frage, die Engineering Leads immer öfter hören.
- Das Team lernt - übersprungene Validierungen und wiederkehrende Unsicherheiten werden sichtbare Muster statt Anekdoten.
Wo Reality Graph ansetzt
Reality Graph erzeugt Prüfberichte als Nebenprodukt seines Verifikations-Workflows. Auftrag und Validierungsplan stehen vor dem Run, Grenz-Checks und Validierungsergebnisse werden danach gesammelt, und der Bericht setzt sich selbst zusammen - lokal, beim Code gespeichert. Wie daraus ein einzelnes Ergebnis wird, auch in den Fällen, in denen alle Tests grün sind und der Run trotzdem blockiert bleibt, steht unter wie das Prüfergebnis entsteht. Aktuell in privater Beta; Early Access ist für eine kleine Gruppe von Teams offen.
Was es macht
- Erzeugt den Bericht aus dem Verifikations-Workflow - keine manuelle Buchführung
- Hält Auftrag, Grenzen, Validierungsergebnisse und offene Fragen pro Run fest
- Macht den Negativraum sichtbar: Übersprungenes und Offenes sind erstklassige Einträge
- Speichert Berichte lokal, bei eurem Code - auditierbar durch euer Team
Was es nicht macht
- Belege erfinden - was nicht lief, wird nicht als gelaufen berichtet
- Tests oder CI ersetzen - es hält fest, was sie pro Run gesagt haben
- Berichte irgendwohin senden - sie bleiben in eurer Umgebung
- Compliance behaupten - Belege stützen Auditierbarkeit; eine Zertifizierung sind sie nicht
FAQ
- Was ist ein KI-Code-Prüfbericht?
- Ein kurzer, strukturierter Nachweis pro KI-Coding-Run: Was war der Auftrag, was hat sich geändert, welche Validierung lief mit welchem Ergebnis, was wurde bewusst übersprungen, was ist offen. Er macht aus „der Agent sagt, es ist fertig“ etwas, das ein Reviewer tatsächlich prüfen kann.
- Ist das nicht einfach eine Pull-Request-Beschreibung?
- Eine PR-Beschreibung entsteht im Nachhinein, meist vom selben Modell, das die Änderung gemacht hat - und enthält, was ihr Autor erzählen möchte. Ein Prüfbericht ist an einen vor dem Run aufgeschriebenen Auftrag gebunden und hält Validierungsergebnisse fest - inklusive des Negativraums: was nicht getestet wurde.
- Wer liest Prüfberichte?
- Zuerst Reviewer - sie bekommen Auftrag und Validierungsstatus statt eines nackten Diffs. Dann künftige Maintainer bei der Archäologie an einer Änderung, Engineering Leads, die wissen müssen, wie KI-gestützte Arbeit verifiziert wird - und in regulierten Kontexten Auditoren, die fragen, wie Änderungen kontrolliert wurden.
- Bremst das Schreiben von Belegen das Team aus?
- Der Bericht entsteht aus dem, was der Verifikations-Workflow ohnehin weiß - aufgeschriebener Auftrag, Grenz-Checks, Validierungsergebnisse. Der menschliche Aufwand sind die Minuten der Auftragsdefinition vorab, die sich beim Review zurückzahlen. Belege, die manuelle Buchführung verlangen, würden tatsächlich sterben - deshalb müssen sie aus dem Workflow herausfallen.
- Was unterscheidet Belege von einem Audit Trail?
- Belege gelten pro Run und beantworten „wurde diese Änderung verifiziert, und wie?“. Ein Audit Trail ist die Summe über die Zeit und beantwortet „wie kontrolliert dieses Team KI-gestützte Änderungen generell?“. Beim Code gespeicherte Berichte liefern beides - ohne Zusatzprozess.
- Wie lange sollte ein Team Prüfberichte aufbewahren?
- So lange wie den Code, den sie beschreiben - beim Code gespeichert erledigt sich das von selbst, denn die Berichte wandern mit dem Repository durch Branches, Merges und Archivierung. Ein Bericht ist genau dann wertvoll, wenn Monate später jemand fragt, was bei dieser Änderung eigentlich geprüft wurde; getrennt abgelegte Berichte sind zu diesem Zeitpunkt erfahrungsgemäß nicht mehr auffindbar.
Weiterlesen
GuideDer erste PrüfberichtEin Teamleiter bekommt den ersten KI-Code-Prüfbericht an einem Nachmittag hin, ohne Plattform - der tool-agnostische Fahrplan, eine kopierbare Bericht-Vorlage und der Weg von einem Bericht zur Team-Praxis.ComplianceAudit-Trails für KI-generierten CodeGit protokolliert, was sich änderte - nicht den Auftrag, die Validierung, die Freigabe. Die fünf Auditor-Fragen, warum der Druck unter NIS2 und neuer Produkthaftung steigt und wie man den Trail aufbaut.Alle ArtikelDie ganze Sammlung - 58 belegte, datierte Guides zur Prüfung von KI-generiertem Code.