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 2026 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. Den breiteren Datensatz - Adoption, Vertrauen und Review-Zahlen nebeneinander - sammelt die Verification-Gap-Statistik.

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.

Verification Debt landet schnell in einer Schublade, für die es schon Werkzeuge gibt. Es lohnt sich, genau zu sein: Jede benachbarte Prüfung fängt etwas anderes - und genau in der Lücke dazwischen sitzt Verification Debt.

Der Punkt ist nicht, dass ein Tool gewinnt. Statische Analyse, Tests und Review beantworten je eine reale Frage, und der SonarQube-Vergleich vertieft, wo Code Quality Assurance endet und Verifikation beginnt. Verification Debt ist das, was übrig bleibt, wenn der Code jede dieser Prüfungen besteht und trotzdem niemand sagen kann, dass die Änderung die richtige war, aus dem genannten Grund erfolgte und Belege trägt - die Idee hinter Proof-Carrying Coding.

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 - der Kern des Code-Review-Engpasses.
• 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:

Nichts davon braucht neues Tooling - eine Tabelle und eine kurze Retro pro Monat machen den Trend sichtbar. Formale Metriken mit Formeln und Startschwellen beschreibt Verification Debt messen.

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.