Welche Eingaben sind gemessen, welche sind Annahmen?

Gemessen, mit Quellen: 14-Tage-Churn Richtung 5,7 % in KI-lastigen Codebasen (GitClear, 211 Mio. Zeilen), Review-Zeit pro PR +91 % in KI-intensiven Teams (Faros-Telemetrie), rund 45 % der KI-Samples fallen durch Security-Tests (Veracode 2025). Annahmen, klar gekennzeichnet: euer Output-Volumen, der Vollkostensatz pro Entwicklerstunde, Stunden pro nachgearbeiteter Änderung und die Incident-Häufigkeit. Die Tabelle im Artikel trennt beide Klassen ausdrücklich.

Ist Churn nicht teilweise normal und sogar gesund?

Ja – ein Teil des Churns ist schnelle Iteration, die ihren Job macht, und ein ehrliches Modell bepreist nicht allen Churn als Verschwendung. Deshalb bepreist die Beispielrechnung nur das Churn-Delta über der Vor-KI-Basis (GitClears ~3,1 %) als debt-getrieben, und deshalb zeigt die Sensitivitäts-Sektion das Ergebnis unter freundlicheren Annahmen. Auch die konservative Variante bleibt teuer – das ist der Befund, der zählt.

Was ist der teuerste einzelne Posten?

In den meisten Parametrisierungen: die Review-Rekonstruktion – die Stunde, die ein Reviewer damit verbringt zurückzuentwickeln, was eine Änderung tun sollte, multipliziert über jeden KI-gestützten PR. Sie übertrifft die Nacharbeit in Teams mit hohem PR-Volumen, weil sie bei jeder Änderung anfällt, nicht nur bei den defekten. Sie ist zugleich der billigste Posten zum Angreifen: Ein schriftlicher Auftrag pro Run entfernt das meiste davon.

Sind Incidents in der Rechnung enthalten?

Als separater, ausdrücklich unsicherer Posten – Incident-Kosten sind klumpig und von seltenen Ereignissen dominiert; sie glatt in einen Jahresschnitt zu falten, würde Präzision vortäuschen. Die Beispielrechnung führt einen bescheidenen Ansatz auf Basis der Security-Durchfallraten und markiert ihn als breitesten Fehlerbalken. Teams in regulierten oder exponierten Domänen sollten diesen Posten mit eigenen Incident-Daten modellieren, nicht mit unseren.

Was würde die Rechnung am stärksten verändern?

Zwei Hebel, beide stromaufwärts: schriftliche Aufträge pro KI-Run (kollabiert den Rekonstruktions-Posten und einen Teil des Churn-Deltas) und unabhängige Validierung vor dem Merge (verschiebt Defekte von Nacharbeit nach dem Merge zu Fixes davor, die einen Bruchteil kosten). Das ist die Brücke zur ROI-Frage – wann die Kosten dieser Praxis unter der entfernten Debt liegen –, die der ROI-Artikel mit derselben Transparenz durchrechnet.

Ökonomie

Was Verification Debt kostet

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

Verification Debt kostet echtes Geld – sie stellt die Rechnung nur spät und unter anderen Namen: Nacharbeit an gechurntem Code, Reviewer-Stunden fürs Rekonstruieren von Absicht, ein Incident-Ansatz. In unserer Beispielrechnung für ein 12-Personen-Team – auf belegten Eingaben gebaut, jede Annahme gekennzeichnet und austauschbar – landet die Jahresrechnung in der Spanne von ein bis zwei Entwicklergehältern. Die Zahl, der ihr trauen solltet, ist die nach dem Einsetzen eurer eigenen Werte – das dauert zehn Minuten.

Inhalt

Die belegten Eingaben, auf denen das Modell steht

Drei gemessene Befunde verankern die Arithmetik. GitClears 211-Millionen-Zeilen-Analyse zeigt 14-Tage-Churn von einer ~3,1-%-Basis Richtung 5,7 % bei wachsender KI-Nutzung – das Delta ist der debt-getriebene Anteil, den wir bepreisen. Faros-Telemetrie zeigt Review-Zeit pro PR +91 % bei fast doppeltem PR-Volumen – die Rekonstruktions-Steuer. Und Veracodes ~45-%-Security-Durchfallrate speist einen bewusst bescheidenen Incident-Ansatz. Alles andere im Modell ist eine Annahme, die ihr ersetzen solltet.

Die Beispielrechnung, Posten für Posten

Posten	Wert im Beispiel	Klasse
Gemergte KI-gestützte Änderungen	~120 PRs/Monat	Annahme – nehmt eure PR-Daten
Als Debt bepreistes Churn-Delta	2,5 Punkte (5,6 % vs. 3,1 % Basis)	Gemessener Trend (GitClear), auf Beispiel-Volumen angewandt
Stunden pro nachgearbeiteter Änderung	6 h im Schnitt	Annahme – zwischen trivialem Revert und tiefem Fix
Review-Rekonstruktion pro KI-PR	0,5 h im Schnitt	Annahme, verankert in +91 % Review-Zeit-Telemetrie
Vollkostensatz pro Entwicklerstunde	75 €	Annahme – nehmt eure Finance-Zahl
Incident-Ansatz	20.000 €/Jahr	Annahme, als breitester Fehlerbalken markiert

Beispielrechnung für ein 12-Personen-Team – die Spalte „Klasse“ ist der Ehrlichkeits-Mechanismus: Messwerte tragen Quellen, Annahmen sind zum Ersetzen da (Beispiel, kein Benchmark; Stand Juli 2026).

Die Arithmetik, transparent: 120 PRs × 2,5 % Churn-Delta ≈ 3 nachgearbeitete Änderungen pro Monat × 6 h × 75 € ≈ 1.350 €/Monat Nacharbeit. Review-Rekonstruktion: 120 PRs × 0,5 h × 75 € ≈ 4.500 €/Monat – dieser Posten überragt die Nacharbeit, weil er bei jeder Änderung anfällt, nicht nur bei den defekten. Mit dem Incident-Ansatz landet das Jahr bei rund 90.000–110.000 € – ein bis zwei Vollkosten-Gehälter, für ein Team, das schnell liefert und wenig liest. Tauscht eine beliebige Annahme, und das Modell rechnet neu; die Struktur ist der Punkt, nicht der Punktwert.

Sensitivität: Was das Ergebnis kippt

Halbiert das Churn-Delta (eure Codebasis verhält sich besser als der GitClear-Trend): Der Nacharbeits-Posten halbiert sich, die Summe sinkt um rund 15 % – der Rekonstruktions-Posten hält die Rechnung hoch.
Nullt den Rekonstruktions-Posten (jeder PR kommt schon mit schriftlichem Auftrag und Belegen an): Die Summe fällt um fast die Hälfte. Das ist der sensibelste Hebel – und der billigste.
Streicht den Incident-Ansatz (Prototyp-Arbeit, keine Produktions-Exposition): Die Rechnung schrumpft, bleibt aber fünfstellig – und das ist zugleich der ehrliche Fall, in dem Prüfaufwand herunterskaliert gehört, wie die Vibe-Coding-Analyse einräumt.

Was die Sensitivität nicht schafft: das Vorzeichen kippen. Unter jeder vertretbaren Parametrisierung kostet ungeprüftes KI-Volumen mehr als die Struktur, die es prüft. Die eigenen Eingaben zu messen ist ein gelöstes Problem – die vier Kennzahlen rechnen sich aus Git- und PR-Daten, die ihr schon habt.

Wohin das Geld geht – und woher es zurückkommt

Die Rechnung oben ist kein Argument gegen KI-Coding – dieselbe Telemetrie, die die Debt zeigt, zeigt echte Durchsatz-Gewinne. Sie ist der Preis der ungeprüften Variante: Der Nacharbeits-Posten ist Churn über der Basis, der Rekonstruktions-Posten sind Reviews ohne Referenz, der Ansatz sind Defekte, die Produktion erreichten. Jeder Posten korrespondiert mit einer Praxis, die ihn entfernt – schriftliche Aufträge, Verifikation vor dem Merge, Belege angehängt –, und die Frage, wann sich diese Praxis bezahlt macht, ist die ROI-Rechnung, mit derselben Transparenz geführt.

Wo Reality Graph ansetzt

Reality Graph greift die zwei größten Posten der Beispielrechnung an: Schriftliche Aufträge mit Verifikation pro Run kollabieren die Rekonstruktions-Steuer, und Pre-Merge-Checks verschieben Defekte von der Nacharbeit nach dem Merge zu Fixes davor. Wir geben keine Einsparungs-Versprechen ab und nennen keine Prozente – der ehrliche Zug ist der dieses Artikels: das Modell mit euren Zahlen rechnen, vor und nach einem Pilot, und die eigenen Daten sprechen lassen. Die Prüfberichte machen dieses Vorher/Nachher messbar.

Diese Rechnung gibt euch

Ein transparentes Modell mit belegten Ankern und markierten Annahmen
Die Posten, unter denen Debt tatsächlich abrechnet
Sensitivitäts-Analyse statt eines rosinengepickten Punktwerts
Einen Zehn-Minuten-Weg zur eigenen Zahl

Sie gibt euch nicht

Eine universelle Kostenzahl – das Beispiel ist ein Beispiel
Ein Argument gegen KI-Coding – die Gewinne sind auch real
Einsparungs-Versprechen für irgendein Tool, auch nicht Reality Graph
Präzision bei Incidents – dieser Fehlerbalken ist ehrlich breit

Wenn diese Grenzen zu eurem Team passen:

Early Access sichern So funktioniert es

FAQ

Was kostet ungeprüfter KI-Code ein Team pro Jahr?: Eine ehrliche Universalzahl gibt es nicht – die Kosten hängen an Volumen, Stundensätzen und Incident-Exposition –, aber es gibt ehrliche Arithmetik. In unserer Beispielrechnung für ein 12-Personen-Team (Annahmen gekennzeichnet und austauschbar) landet die Jahresrechnung in der Spanne von ein bis zwei Entwickler-Vollzeitgehältern, dominiert von Nacharbeit an gechurntem Code und Review-Zeit fürs Rekonstruieren von Absicht. Der Punkt des Modells ist nicht der Punktwert, sondern dass ihr in zehn Minuten eigene Zahlen einsetzen könnt.
Welche Eingaben sind gemessen, welche sind Annahmen?: Gemessen, mit Quellen: 14-Tage-Churn Richtung 5,7 % in KI-lastigen Codebasen (GitClear, 211 Mio. Zeilen), Review-Zeit pro PR +91 % in KI-intensiven Teams (Faros-Telemetrie), rund 45 % der KI-Samples fallen durch Security-Tests (Veracode 2025). Annahmen, klar gekennzeichnet: euer Output-Volumen, der Vollkostensatz pro Entwicklerstunde, Stunden pro nachgearbeiteter Änderung und die Incident-Häufigkeit. Die Tabelle im Artikel trennt beide Klassen ausdrücklich.
Ist Churn nicht teilweise normal und sogar gesund?: Ja – ein Teil des Churns ist schnelle Iteration, die ihren Job macht, und ein ehrliches Modell bepreist nicht allen Churn als Verschwendung. Deshalb bepreist die Beispielrechnung nur das Churn-Delta über der Vor-KI-Basis (GitClears ~3,1 %) als debt-getrieben, und deshalb zeigt die Sensitivitäts-Sektion das Ergebnis unter freundlicheren Annahmen. Auch die konservative Variante bleibt teuer – das ist der Befund, der zählt.
Was ist der teuerste einzelne Posten?: In den meisten Parametrisierungen: die Review-Rekonstruktion – die Stunde, die ein Reviewer damit verbringt zurückzuentwickeln, was eine Änderung tun sollte, multipliziert über jeden KI-gestützten PR. Sie übertrifft die Nacharbeit in Teams mit hohem PR-Volumen, weil sie bei jeder Änderung anfällt, nicht nur bei den defekten. Sie ist zugleich der billigste Posten zum Angreifen: Ein schriftlicher Auftrag pro Run entfernt das meiste davon.
Sind Incidents in der Rechnung enthalten?: Als separater, ausdrücklich unsicherer Posten – Incident-Kosten sind klumpig und von seltenen Ereignissen dominiert; sie glatt in einen Jahresschnitt zu falten, würde Präzision vortäuschen. Die Beispielrechnung führt einen bescheidenen Ansatz auf Basis der Security-Durchfallraten und markiert ihn als breitesten Fehlerbalken. Teams in regulierten oder exponierten Domänen sollten diesen Posten mit eigenen Incident-Daten modellieren, nicht mit unseren.
Was würde die Rechnung am stärksten verändern?: Zwei Hebel, beide stromaufwärts: schriftliche Aufträge pro KI-Run (kollabiert den Rekonstruktions-Posten und einen Teil des Churn-Deltas) und unabhängige Validierung vor dem Merge (verschiebt Defekte von Nacharbeit nach dem Merge zu Fixes davor, die einen Bruchteil kosten). Das ist die Brücke zur ROI-Frage – wann die Kosten dieser Praxis unter der entfernten Debt liegen –, die der ROI-Artikel mit derselben Transparenz durchrechnet.

Weiterlesen

ÖkonomieKI-Token-Kosten senkenTokens sind vor allem Kontext, und Kontext wird jede Runde neu gesendet – die fünf Hebel, die die Rechnung senken, ohne den Output zu verschlechtern, jeder mit benanntem Qualitätsrisiko. Keine Prozente, nur Mechanik, die Preisänderungen überlebt.ÖkonomieDie Verifikations-ROI-RechnungVolumen entscheidet, nicht Kopfzahl: das transparente Break-even-Modell für eine Verifikationspraxis – Kosten pro Run und Fix-Block gegen entfernte Rekonstruktion und Nacharbeit – inklusive der ehrlichen Nein-Fälle.Alle ArtikelDie ganze Sammlung – 58 belegte, datierte Guides zur Prüfung von KI-generiertem Code.