Was Verification Debt kostet
Zuletzt aktualisiert: 2026-08-15Lesezeit ca. 3 Min.
Verification Debt kann als Rework und Review-Zeit erscheinen, doch ihre Kosten sind eine lokale Schätzung, kein Universalpreis. Nutzt einen definierten Zeitraum und ersetzt jede Beispieleingabe durch beobachtete Teamdaten. Externe Studien zeigen messenswerte Risiken; sie belegen weder eure Fehlerquote noch Incident-Exposition oder ROI.
Kurz: Nutzt echte Daten aus eurem Team. Messt Zeit für Review, Tests und spätere Nacharbeit in einem festen Zeitraum. Eine Studie kann ein Risiko zeigen. Sie setzt aber nicht euren Preis, eure Quote oder euren Nutzen fest.
Legt fest, was als Nacharbeit zählt. Nutzt für Start und Ende stets die gleiche Regel. Trennt Fehler, normale Pflege und neue Wünsche. Verknüpft Zeit nur dann mit dem ersten Diff, wenn ein klarer Beleg da ist. So bleibt die Zahl prüfbar. Sie ist eine Sicht auf euer Team und kein Marktwert.
Inhalt
Mit der Belegklasse beginnen, nicht mit dem Eurozeichen
Vier Klassen müssen getrennt bleiben. Eine Quelle berichtet eine Beobachtung unter ihrer eigenen Methode. Euer Team erfasst eine lokale Beobachtung unter einer schriftlichen Definition. Eine Schätzung kombiniert gewählte Eingaben. Ein Rechenergebnis ist nur die arithmetische Folge dieser Eingaben. Keine Klasse wird zur gemessenen Einsparung, bevor ein vergleichbarer Vorher-nachher-Wert sie stützt.
GitClears Repo-Studie, Faros’ Kunden-Telemetrie und Veracodes Security-Test generierter Code-Samples beschreiben unterschiedliche Stichproben und Outcomes. Sie sind hilfreiche Warnsignale. Sie rechtfertigen nicht, einen Churn-Unterschied als Fehlerquote zu bepreisen, Review-Telemetrie in eine universelle Pro-PR-Abgabe umzudeuten oder aus einer Security-Testquote eine Incident-Rückstellung abzuleiten.
Eine Beispielrechnung mit ersetzbaren Annahmen
Das Beispiel nutzt 120 KI-unterstützte Changes im Monat, eine lokal grundcodierte Rework-Rate von 2 %, sechs Stunden je Rework, eine halbe Stunde zusätzliche Review-Rekonstruktion je Change und 75 € internen Stundensatz. Das sind illustrative Eingaben, keine Quellenbenchmarks. Daraus entstehen 14,4 Rework-Stunden und 60 Review-Stunden, also 74,4 Stunden beziehungsweise 5.580 € in diesem Monat. Jede andere Eingabe verändert das Ergebnis.
Ersetzbare Eingaben statt Benchmark
| Beispiel | Ersetzen durch | Bedeutung | |
|---|---|---|---|
| AI-unterstützte Changes/Monat | 120Ersetzbare Beispielannahme · 2026-07-16Nur zur Demonstration der Formel; nicht aus einer Studie übernommen. | Git-/PR-DatenRedaktionelle Evidenzgrenze · 2026-07-16Erfordert eine lokal definierte Messregel und Zeitraum. | Volumen, kein QualitätsurteilRedaktionelle Evidenzgrenze · 2026-07-16Interpretation gilt nur für die gewählten Eingaben. |
| Innerhalb 14 Tagen wegen Fehlern nachbearbeitet | 2 %Ersetzbare Beispielannahme · 2026-07-16Nur zur Demonstration der Formel; nicht aus einer Studie übernommen. | Eigene, grundcodierte Rework-RateRedaktionelle Evidenzgrenze · 2026-07-16Erfordert eine lokal definierte Messregel und Zeitraum. | 2,4 Changes/Monat im BeispielRedaktionelle Evidenzgrenze · 2026-07-16Interpretation gilt nur für die gewählten Eingaben. |
| Stunden je Rework | 6 hErsetzbare Beispielannahme · 2026-07-16Nur zur Demonstration der Formel; nicht aus einer Studie übernommen. | Ticket-/Zeiterfassung oder StichprobeRedaktionelle Evidenzgrenze · 2026-07-16Erfordert eine lokal definierte Messregel und Zeitraum. | 14,4 h/Monat im BeispielRedaktionelle Evidenzgrenze · 2026-07-16Interpretation gilt nur für die gewählten Eingaben. |
| Zusätzliche Rekonstruktion je Change | 0,5 hErsetzbare Beispielannahme · 2026-07-16Nur zur Demonstration der Formel; nicht aus einer Studie übernommen. | Review-Stichprobe mit/ohne Task- und TestbelegRedaktionelle Evidenzgrenze · 2026-07-16Erfordert eine lokal definierte Messregel und Zeitraum. | 60 h/Monat im BeispielRedaktionelle Evidenzgrenze · 2026-07-16Interpretation gilt nur für die gewählten Eingaben. |
| Interner Vollkostensatz | 75 €Ersetzbare Beispielannahme · 2026-07-16Nur zur Demonstration der Formel; nicht aus einer Studie übernommen. | Finance-Zahl für das konkrete TeamRedaktionelle Evidenzgrenze · 2026-07-16Erfordert eine lokal definierte Messregel und Zeitraum. | Nur monetarisiert, wenn dieser Satz passtRedaktionelle Evidenzgrenze · 2026-07-16Interpretation gilt nur für die gewählten Eingaben. |
Das Beispiel mit euren eigenen Zahlen rechnen
Dasselbe Modell als Instrument
Die Zahlen oben sind das Beispiel eines Teams. Zieht die vier Eingaben auf eure, und die Rechnung läuft an Ort und Stelle neu – mit derselben Nacharbeitsrate, derselben Rekonstruktionszeit und derselben Weigerung, einen Incident-Puffer anzusetzen, den niemand definiert hat. Denselben Rechner gibt es auf einer eigenen Seite, zusammen mit dem, was eine Team-Version ändern würde.
Geschätzte Kosten eurer Verification Debt
Beispiel – illustrative Rechnung, kein Benchmark67.000 €
pro Jahr · 5.580 € pro Monat
Gerechnet mit rund 120 KI-gestützten Merges pro Monat.
Bei diesen Eingaben beziffert das Modell die Verification Debt auf 67.000 € im Jahr oder 5.580 € im Monat: 74,4 Stunden Entwicklungszeit, davon 60 dafür, herauszufinden, was eine Änderung tun sollte, bevor man sie beurteilen kann.
| Kostenzeile | Pro Monat | Stunden im Monat |
|---|---|---|
| Review-Rekonstruktion | 4.500 € | 60 h |
| Nacharbeit an gechurntem Code | 1.080 € | 14,4 h |
| Incident-Puffer | keiner angesetzt | 0 h |
Was das Modell für euch angenommen hat· Annahmen mit Stand 2026-08-15
0,5 Stunden Review-Rekonstruktion je KI-gestützter Änderung · 2 % der KI-gestützten Änderungen binnen 14 Tagen wegen eines Fehlers nachgearbeitet, eine illustrative Rate, die ihr durch eure eigene ersetzt · 6 Stunden, um eine gechurnte Änderung nachzuarbeiten
Die Schätzung entscheidungsfähig machen
- Rework vor dem Zählen definieren. Trennt Fehlerkorrekturen von geplanter Iteration, Formatierung und unabhängigem Follow-up.
- Eine begrenzte Review-Stichprobe nutzen. Vergleicht Changes mit und ohne schriftlichen Auftrag und angehängte Receipts; leitet keine Rekonstruktionszeit aus einem externen Aggregat ab.
- Incidents separat halten. Ergänzt Expected Loss nur mit eigener Taxonomie, Exposition und Historie; sonst bleibt das Risiko unquantifiziert.
- Unsicherheit veröffentlichen. Zeigt eine Spanne oder rechnet alternative Annahmen durch, statt einen Punktwert als Fakt darzustellen.
Der Begleitartikel erklärt, wie ihr die vier lokalen Verification-Debt-Maße erhebt. Für den Vergleich einer Intervention ergänzt die ROI-Methode Interventionskosten und eine vergleichbare Baseline, ohne Annahmen in Versprechen zu verwandeln.
Die Rechnung liefert
- Eine prüfbare Formel
- Ersetzbare Annahmen
- Eine Trennung von Beobachtung, Schätzung und Ergebnis
- Einen Startpunkt für eine lokale Baseline
Sie liefert nicht
- Eine Branchenbenchmark
- Einen kausalen Nachweis über KI
- Eine garantierte Einsparung
- Einen Incident- oder ROI-Forecast
Wo Reality Graph ansetzt
Reality Graph kann Aufgaben, Validierungs-Receipts und Run-Grenzen leichter aufbewahrbar machen. Ob das Rework oder Review-Aufwand verändert, ist eine empirische Frage für euren Workflow. Messt vor und nach einem begrenzten Pilot dieselben Definitionen, bewahrt fehlgeschlagene ebenso wie bestandene Ergebnisse auf und lasst den lokalen Vergleich die Entscheidung stützen.
FAQ
- Was kostet ungeprüfter KI-Code ein Team pro Jahr?
- Es gibt keine belastbare Universalzahl. Schätzt eure Kosten für einen definierten Zeitraum aus Change-Volumen, grundcodierter Rework-Rate, Stunden je Rework, zusätzlicher Review-Rekonstruktion und internem Stundensatz. Die Beispielrechnung zeigt nur die Arithmetik; sie ist weder Benchmark noch Kundenergebnis.
- Welche Eingaben sind gemessen und welche Annahmen?
- Die Beispielwerte sind sichtbar als ersetzbare Annahmen markiert. Für eine reale Schätzung ersetzt ihr sie durch lokales Git-/PR-Volumen, grundcodiertes Rework, eine Review-Stichprobe und einen von Finance bestätigten Kostensatz. Externe Studien liefern Risikokontext, aber keine Kostensätze für euer Team.
- Belegt eine externe Churn-Studie unsere Rework-Kosten?
- Nein. Repo-Studien sind Beobachtungsstudien mit eigenen Definitionen und Stichproben. Sie können eine lokale Messung motivieren. Eine berichtete Prozentzahl als eigene Fehlerquote zu übernehmen, erzeugt Scheingenauigkeit und belegt keine Kausalität.
- Sollten Incidents im Modell stehen?
- Nur wenn ihr Incident-Klasse, Häufigkeit und Expected-Loss-Methode lokal definiert habt. Ein Security-Benchmark mit Schwächen in generierten Samples ist keine Incident-Häufigkeit und rechtfertigt allein keine monetäre Rückstellung.
- Beweist die Rechnung den ROI von Prüfung?
- Nein. Sie schätzt ausgewählten schuldenbezogenen Aufwand unter genannten Annahmen. ROI braucht zusätzlich die gemessenen Interventionskosten, eine vergleichbare Baseline, einen Zeitraum und Unsicherheit. Ein Beispiel garantiert weder Einsparung noch positiven ROI.
- Was sollte ein Team zuerst messen?
- Startet mit einem Workflow und einem festen Zeitraum. Erfasst KI-unterstütztes Change-Volumen, grundcodiertes kurzfristiges Rework und eine kleine Review-Zeit-Stichprobe. Trennt Beobachtungen von Schätzungen und ändert zwischen Vergleichszeiträumen nur eine Definition.