Wie misst man Verification Debt konkret?

Mit vier Kennzahlen aus Daten, die jedes Team schon hat: dem Generierungs-zu-Prüfungs-Verhältnis (gemergte geänderte Zeilen vs. tatsächlich investierte Review-Stunden), der Review-Tiefe (substanzielle Kommentare pro 100 geänderte Zeilen), der Quote ungeprüfter Merges (Anteil KI-gestützter Merges ohne festgehaltenen Validierungsnachweis) und dem 14-Tage-Churn (Anteil neuen Codes, der binnen zwei Wochen wieder angefasst wird). Monatlich erheben – der Trend zählt mehr als jeder Einzelwert.

Mit welcher Kennzahl sollte ein Team anfangen?

Mit der Quote ungeprüfter Merges, denn sie ist der direkteste Ausdruck der Schuld: Jeder Merge ohne festgehaltene Verifikation ist eine ungeprüfte Behauptung in Produktion. Sie braucht nur eine Konvention – dass Prüfergebnisse pro Änderung festgehalten werden – und zeigt sofort, ob Prozessänderungen greifen.

Gibt es Standard-Schwellenwerte?

Nein – dafür ist das Feld zu jung. Die Schwellen in diesem Artikel sind Startpunkte, abgeleitet aus veröffentlichten Baselines wie GitClears gemessenem Anstieg des 14-Tage-Churns von rund 3 % auf fast 6 % über 211 Millionen geänderte Zeilen. Kalibriert gegen eure eigene Drei-Monats-Baseline statt gegen fremde Absolutwerte.

Braucht man dafür spezielles Tooling?

Nein. Git und die PR-Plattform enthalten alles außer den Prüfnachweisen: geänderte Zeilen, Review-Kommentare, Revisions-Zeitstempel. Eine Tabelle und eine monatliche Retro reichen für den Start. Tooling hilft bei der einen Kennzahl, die Git nicht sieht – ob eine Änderung wirklich verifiziert wurde. Genau deshalb zahlen sich Prüfberichte doppelt aus.

Reichen DORA-Metriken nicht?

DORA misst Lieferperformance – und KI hebt genau diese Zahlen, während das Risiko woandershin wandert. Der DORA-Report 2025 hat mit der Rework Rate eine fünfte Metrik genau für diesen blinden Fleck ergänzt, und Branchentelemetrie zeigt eine um 441 % gestiegene mediane PR-Review-Zeit bei wachsendem KI-Volumen. Verification-Debt-Kennzahlen ergänzen DORA; sie ersetzen es nicht.

Kann man damit einzelne Entwickler bewerten?

Man sollte nicht. Verification Debt ist eine Eigenschaft des Systems – Auftragsdefinitionen, Review-Kapazität, Tooling –, nicht einzelner Personen. Werden die Kennzahlen zu persönlichen Scores, lädt das zum Gaming ein und zerstört ihren diagnostischen Wert. Die Pipeline messen, Trends in der Retro besprechen, den Prozess ändern statt das Ranking.

Methode

Verification Debt messen

Zuletzt aktualisiert: 2026-07-02Lesezeit ca. 4 Min.

Verification Debt messen heißt: die Lücke zwischen dem, was ein Team merged, und dem, was davon nachweislich verifiziert ist – erfasst über vier berechenbare Kennzahlen: Generierungs-zu-Prüfungs-Verhältnis, Review-Tiefe, Quote ungeprüfter Merges und 14-Tage-Churn. Alle vier entstehen aus Git- und PR-Daten; der Monatstrend zählt mehr als jeder Einzelwert.

Inhalt

Warum eure Dashboards die Schuld nicht zeigen

Die Liefermetriken werden besser, während die Schuld wächst – genau das macht sie unsichtbar. KI-Einsatz hebt Deployment-Frequenz und Lead Time, und das Risiko wandert in Dimensionen, für die klassische Dashboards nie gebaut wurden: Der DORA-Report 2025 hat die Rework Rate als fünfte Metrik ergänzt – für genau diesen blinden Fleck, begleitet von Telemetrie mit +441 % medianer PR-Review-Zeit und +51 % PR-Größe bei wachsendem KI-Volumen.

Dieser Artikel macht aus den fünf Warnsignalen der Verification-Debt-Übersicht etwas, das diese Woche in eine Tabelle passt: Formeln, Datenquellen und ehrliche Start-Schwellenwerte.

Die vier Kennzahlen, mit Formeln

Kennzahl	Formel	Datenquelle	Warnschwelle (Startpunkt)
Generierungs-zu-Prüfungs-Verhältnis (GPV)	Gemergte geänderte Zeilen pro Woche ÷ tatsächlich investierte Review-Stunden	git log --stat; Kalender oder PR-Zeitstempel	Verhältnis verdoppelt sich, während die Review-Stunden gleich bleiben
Review-Tiefe	Substanzielle Review-Kommentare ÷ (geänderte Zeilen ÷ 100)	PR-Plattform-API (Bot- und Nitpick-Kommentare ausschließen)	Fällt unter ~1 Kommentar je 100 Zeilen bei steigendem KI-Volumen
Quote ungeprüfter Merges (QUM)	KI-gestützte Merges ohne festgehaltenen Validierungsnachweis ÷ alle KI-gestützten Merges	Prüfnachweise / Prüfberichte pro Änderung	Über 30 % – laut Sonar prüft nur die Hälfte überhaupt immer
14-Tage-Churn	Zeilen, die ≤ 14 Tage nach Merge revidiert/revertiert werden ÷ neue Zeilen	git log mit Folge-Commit-Analyse	Über ~6 % – GitClear maß den Branchendrift von 3,1 % auf 5,7 %

Vier Verification-Debt-Kennzahlen, berechenbar aus Git- und PR-Daten. Die Schwellen sind Startpunkte, keine Normen – kalibriert gegen die eigene Drei-Monats-Baseline.

Zwei veröffentlichte Anker helfen bei der Einordnung: GitClears Analyse von 211 Millionen geänderten Zeilen zeigt den 14-Tage-Churn von 3,1 % (2020) Richtung 5,7 % steigen – erstmals überholten kopierte Zeilen die refaktorierten – und Sonars Umfrage beziffert den Anteil der Entwickler, die KI-Code immer prüfen, auf 48 % – was eine naive Team-QUM um die 50 % zum realistischen, ernüchternden Ausgangswert macht.

Ein Rechenbeispiel

Ein fiktives Acht-Personen-Team, ein Monat Daten – als Beispiel gekennzeichnet, aber die Arithmetik bleibt die Arithmetik:

vd-bericht-april.md

Beispiel – illustrative Zahlen

Team:       8 Devs · ~60 % der Merges KI-gestützt
Fenster:    4 Wochen

Eingaben
  gemergte geänderte Zeilen:    41.200   (vor KI: ~19.000/Monat)
  Review-Stunden (Kalender):    64 h     (unverändert zu vor KI)
  substanzielle PR-Kommentare:  212
  KI-gestützte Merges:          97 · davon mit Prüfnachweis: 31
  Zeilen revidiert ≤ 14 Tage:   2.890

Kennzahlen
  GPV:            41.200 / 64  = 644 Zeilen/Review-Stunde
                  (Baseline vor KI: 297)  → 2,2×  ⚠
  Review-Tiefe:   212 / 412    = 0,51 je 100 Zeilen  ⚠
  QUM:            (97−31)/97   = 68 %                ⚠⚠
  14-Tage-Churn:  2.890/41.200 = 7,0 %               ⚠

Lesart: Generierung verdoppelt, Prüfkapazität nicht.
Priorität: Prüfergebnis pro Änderung festhalten (die QUM
bewegt sich als erste, wenn der Prozess sich ändert).

Messfallen

Goodharts Gesetz. Sobald eine Kennzahl zum Ziel wird, misst sie nichts mehr. Diese vier sind Diagnose-Instrumente für die Monats-Retro – keine OKRs und nie persönliche Leistungswerte.
Attributionsrauschen. KI-gestützte und menschliche Änderungen sauber zu trennen ist schwer; ein einfaches PR-Label vom Autor ist unperfekt, schlägt aber Raten. Konsistenz zählt mehr als Präzision.
Kleine Zahlen. Der Monats-Churn eines Drei-Personen-Teams springt. Fenster verbreitern, bevor Schlüsse gezogen werden.
Messen ohne Hebel. Die Kennzahlen zahlen sich nur mit angeschlossenem Hebel aus – schriftlicher Auftrag pro Aufgabe, ein Soll-Ist-Abgleich, festgehaltene Ergebnisse. Sonst ist es ein Dashboard des Niedergangs.

Wo Reality Graph ansetzt

Die eine Kennzahl, die Git nicht berechnen kann, ist: Wurde die Änderung wirklich verifiziert? Reality Graph erzeugt diesen Nachweis als Nebenprodukt – jeder Run endet in einem Prüfbericht, womit die Quote ungeprüfter Merges eine Abfrage wird statt eines Archäologie-Projekts – und die drei anderen Kennzahlen den Nenner bekommen, den sie brauchen.

Das Messen liefert

Eine Trendlinie statt des Gefühls, dass Review ertrinkt
Ein Argument, das Budgetverantwortliche verstehen
Frühwarnung, bevor der Churn die Produktion erreicht
Sichtbarkeit, ob Prozessänderungen wirklich greifen

Es leistet nicht

Branchen-Standardschwellen – lokal kalibrieren
Perfekte Zuordnung von KI- vs. Mensch-Änderungen
Ehrliche Werte, wenn es Personalbewertung wird
Abbau der Schuld von allein – es zeigt auf die Hebel

Wenn diese Grenzen zu eurem Team passen:

Early Access sichern So funktioniert es

FAQ

Wie misst man Verification Debt konkret?: Mit vier Kennzahlen aus Daten, die jedes Team schon hat: dem Generierungs-zu-Prüfungs-Verhältnis (gemergte geänderte Zeilen vs. tatsächlich investierte Review-Stunden), der Review-Tiefe (substanzielle Kommentare pro 100 geänderte Zeilen), der Quote ungeprüfter Merges (Anteil KI-gestützter Merges ohne festgehaltenen Validierungsnachweis) und dem 14-Tage-Churn (Anteil neuen Codes, der binnen zwei Wochen wieder angefasst wird). Monatlich erheben – der Trend zählt mehr als jeder Einzelwert.
Mit welcher Kennzahl sollte ein Team anfangen?: Mit der Quote ungeprüfter Merges, denn sie ist der direkteste Ausdruck der Schuld: Jeder Merge ohne festgehaltene Verifikation ist eine ungeprüfte Behauptung in Produktion. Sie braucht nur eine Konvention – dass Prüfergebnisse pro Änderung festgehalten werden – und zeigt sofort, ob Prozessänderungen greifen.
Gibt es Standard-Schwellenwerte?: Nein – dafür ist das Feld zu jung. Die Schwellen in diesem Artikel sind Startpunkte, abgeleitet aus veröffentlichten Baselines wie GitClears gemessenem Anstieg des 14-Tage-Churns von rund 3 % auf fast 6 % über 211 Millionen geänderte Zeilen. Kalibriert gegen eure eigene Drei-Monats-Baseline statt gegen fremde Absolutwerte.
Braucht man dafür spezielles Tooling?: Nein. Git und die PR-Plattform enthalten alles außer den Prüfnachweisen: geänderte Zeilen, Review-Kommentare, Revisions-Zeitstempel. Eine Tabelle und eine monatliche Retro reichen für den Start. Tooling hilft bei der einen Kennzahl, die Git nicht sieht – ob eine Änderung wirklich verifiziert wurde. Genau deshalb zahlen sich Prüfberichte doppelt aus.
Reichen DORA-Metriken nicht?: DORA misst Lieferperformance – und KI hebt genau diese Zahlen, während das Risiko woandershin wandert. Der DORA-Report 2025 hat mit der Rework Rate eine fünfte Metrik genau für diesen blinden Fleck ergänzt, und Branchentelemetrie zeigt eine um 441 % gestiegene mediane PR-Review-Zeit bei wachsendem KI-Volumen. Verification-Debt-Kennzahlen ergänzen DORA; sie ersetzen es nicht.
Kann man damit einzelne Entwickler bewerten?: Man sollte nicht. Verification Debt ist eine Eigenschaft des Systems – Auftragsdefinitionen, Review-Kapazität, Tooling –, nicht einzelner Personen. Werden die Kennzahlen zu persönlichen Scores, lädt das zum Gaming ein und zerstört ihren diagnostischen Wert. Die Pipeline messen, Trends in der Retro besprechen, den Prozess ändern statt das Ranking.

Weiterlesen

MethodeSpec-Driven DevelopmentErst Soll, dann Code: Wie SDD mit KI-Agenten funktioniert, was Spec Kit und Kiro wirklich leisten und welche ehrlichen Grenzen Praktiker berichten – und warum Specs trotzdem Verifikation brauchen.MethodeZwei-Phasen-ReviewMaschinelle Vorprüfung zuerst, menschliches Architektur-Review danach: Was in welche Phase gehört, wie das Maschinen-Gate präzise bleibt – und warum der Merge immer menschlich entschieden wird.Alle ArtikelDie ganze Sammlung – 30 belegte, datierte Guides zur Prüfung von KI-generiertem Code.