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.

Konzept

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.md

Sample – illustrativ, keine echten Run-Daten

Run:        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 Release

Das 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.

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. 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 unterstützen Auditierbarkeit; eine Zertifizierung sind sie nicht

Wenn diese Grenzen zu eurem Team passen:

Early Access sichern So funktioniert es

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

ArchitekturLocal-First-SicherheitSicherheit als prüfbare Architektur-Eigenschaften statt Marketing-Garantien: local-first, advisory by default, kein Auto-Commit, menschliche Freigabe-Gates.GovernanceKI-Coding-GovernanceKontrollen, Workflows, Freigaben und Belege, mit denen ein Team KI-Coding-Tools einführt, ohne Engineering-Verantwortung zu verlieren – samt der Grenzen jedes Bausteins.Alle ArtikelDie ganze Sammlung – 58 belegte, datierte Guides zur Prüfung von KI-generiertem Code.