Verification Debt im KI-Coding

2025 war für die meisten Teams das Jahr, in dem KI-gestütztes Coding vom Experiment zum Alltag wurde. Generieren wurde billig — Prüfen nicht. Der Begriff „Verification Debt“ verbreitete sich in der Entwickler-Community und erreichte die Breite, als AWS-CTO Werner Vogels ihn im Dezember 2025 auf der AWS re:Invent verwendete (Bericht: ITPro). Etwa zeitgleich hat Sonars State-of-Code-Umfrage unter mehr als 1.100 Entwicklern die Lücke vermessen:

Dieselbe Sonar-Studie: 38 % der Entwickler empfinden den Review von KI-generiertem Code als aufwendiger als den von Kollegen-Code, und 53 % haben erlebt, dass KI Code produziert, der korrekt aussieht, aber nicht zuverlässig ist. Diese Kombination — fast universelles Misstrauen, halbherzige Prüfung, steigender Review-Aufwand — ist Verification Debt beim Entstehen.

Verification Debt ist ein Mengenproblem: Code fließt schneller in die Codebasis, als das Team ihn prüfen kann. Es ist keine Aussage über die Qualität von KI-Code. Selbst wenn neun von zehn generierten Änderungen richtig wären — ein Team, das nicht sagen kann, welche neun, trägt die Schuld für alle zehn.

Von technischen Schulden unterscheidet sie sich darin, wie sie sich zeigt. Technische Schulden erzeugen spürbare Reibung. Verification Debt erzeugt das Gegenteil: Alles sieht fertig aus. Sie erzeugt falsches Vertrauen statt sichtbarer Reibung — deshalb fällt sie erst auf, wenn sie teuer wird.

Verwandt, aber nicht identisch: Comprehension Debt— der O’Reilly-Begriff für Code, den niemand im Team mehr wirklich versteht. Comprehension Debt fragt „verstehen wir diesen Code?“; Verification Debt fragt „hat irgendjemand diese Änderung gegen das geprüft, was wir bauen wollten?“. Ein Team kann seine Codebasis verstehen und trotzdem täglich ungeprüft mergen.

Fünf Mechanismen richten den größten Schaden an:

• Generierung überholt die Review-Kapazität. Ein Entwickler mit KI-Tool erzeugt mehr geänderte Zeilen pro Tag, als ein Senior kritisch auditieren kann.
• Große Diffs verleiten zum Überfliegen. KI-Pull-Requests sind tendenziell groß und plausibel — genau die Art Änderung, die Menschen überfliegen statt prüfen.
• Der Generator benotet die eigene Arbeit. Wenn dasselbe Modell den Code schreibt, die Tests schreibt und die Änderung zusammenfasst, gibt es im ganzen Kreislauf keine unabhängige Prüfung.
• Der Auftrag fehlt beim Review. Reviewer sehen, was sich geändert hat — aber nicht die Grenzen, die die Änderung einhalten sollte. Die Frage „ist das überhaupt die richtige Änderung?“ wird nie gestellt.
• Prüf-Belege gehören niemandem. Was getestet wurde, was übersprungen wurde, was unsicher blieb — das steht, wenn überhaupt, im Chat-Verlauf. Für den Reviewer unsichtbar, in einer Woche verschwunden.

Eine Standardmetrik gibt es noch nicht — ehrlich messen lässt sich heute nur richtungsweisend, mit Signalen, die jedes Team schon hat:

• Generierungs-zu-Prüfungs-Verhältnis: gemergte geänderte Zeilen pro Woche vs. tatsächlich investierte Review-Zeit. Hat sich die Generierung verdoppelt, die Review-Zeit aber nicht, ist die Differenz Schuld.
• Review-Tiefe im Trend: substanzielle Review-Kommentare pro 100 geänderte Zeilen. Fällt die Kurve, während das KI-Volumen steigt, werden Reviews dünner.
• Quote ungeprüfter Merges: Anteil KI-gestützter Änderungen, die ohne menschlich verifizierte Test-Belege gemergt werden.
• „Sah richtig aus, war es nicht“-Vorfälle: Defekte, die auf Änderungen zurückgehen, die den Review passiert haben. Sonar: 53 % der Entwickler kennen genau diesen Fehlermodus.
• Nacharbeitsquote: wie oft KI-gestützte Änderungen binnen 30 Tagen revertiert, gehotfixt oder neu geschrieben werden.

Nichts davon braucht neues Tooling — eine Tabelle und eine ehrliche Retro pro Monat machen den Trend sichtbar.

Teams, die das gut lösen, ändern nicht die Review-Härte, sondern das, was beim Review ankommt:

• Auftrag vor dem Run definieren — Scope, betroffene Dateien und ein Validierungsplan, festgehalten bevor die KI etwas erzeugt. Dann gibt es etwas Konkretes, wogegen geprüft wird.
• Diffs klein halten — eine prüfbare Änderung schlägt eine beeindruckende.
• Generierung und Prüfung trennen — das Modell, das die Änderung geschrieben hat, darf nicht das Einzige sein, das sie geprüft hat.
• Belege pro Änderung verlangen — was getestet wurde, was nicht, was offen ist: an der Änderung selbst, nicht im Chat-Verlauf.
• Menschliches Freigabe-Gate behalten — kein Auto-Commit; ein Mensch übernimmt die Änderung, mit den Belegen vor Augen.
• Lokal bleiben, wo Code sensibel ist — Prüfung darf nicht voraussetzen, dass Quellcode zu einem weiteren Cloud-Dienst hochgeladen wird.

Reality Graph ist eine lokale Verifikationsschicht, die neben den KI-Coding-Tools arbeitet, die ein Team ohnehin nutzt — Claude Code, Cursor, GitHub Copilot und vergleichbare. Sie setzt die Praktiken oben als Workflow um: Auftragsgrenzen und Kontext vor dem Run, sichtbare Validierung und ein Prüfbericht danach, dazwischen ein menschliches Freigabe-Gate. Aktuell in privater Beta; Early Access ist für eine kleine Gruppe von Teams offen.