Zum Inhalt springen
Reality Graph

Rechner

Verification-Debt-Rechner

gemergte ÄnderungenReview-KapazitätVerification DebtKI kommt dazudie Lücke ist das, was diese Seite bepreist
Verification Debt ist die Lücke zwischen dem Tempo, in dem KI-Werkzeuge Code erzeugen, und der Zuverlässigkeit, mit der ein Team ihn vor dem Merge prüfen kann. Dieser Rechner bepreist diese Lücke mit euren eigenen Zahlen: wie viele Leute Code mergen, wie viel jede davon mergt, welcher Anteil davon KI-gestützt ist und eure Vollkosten pro Stunde. Jede Annahme steht sichtbar da und lässt sich ersetzen, denn ein Rechner, dessen Rechenweg verborgen bleibt, ist ein Überzeugungswerkzeug und keine Schätzung. Er bepreist ein Problem, kein Produkt.

Zuletzt aktualisiert:

Mit euren eigenen Zahlen rechnen

Vier Eingaben. Die Standardwerte beschreiben ein Team von zehn Personen, bei dem die meisten Merges KI-gestützt sind. Zieht sie auf eure, und die Rechnung läuft an Ort und Stelle neu.
10
20
Anteil der Merges mit KI-Unterstützung
75 €

Geschätzte Kosten eurer Verification Debt

Beispiel – illustrative Rechnung, kein Benchmark

67.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.

Über dem Break-even.Das bernsteinfarbene Band markiert 30 bis 40 KI-gestützte Änderungen im Monat, auf logarithmischer Skala, damit der ganze Bereich hineinpasst. Darunter rutscht das Beispiel ins Grenzland: wenig abzutragen, und die Praxis trägt sich eher, als dass sie etwas zurückgibt.
Was die Rechnung macht, wenn das Volumen wächst

Stunden im Monat

KI-gestützte Änderungen im Monat

  • Review-Rekonstruktion
  • Nacharbeit nach einem Fehler
  • Break-even-Band, 30 bis 40 Änderungen im Monat
  • Eure aktuellen Eingaben

Modellierte monatliche Entwicklungszeit gegen das KI-gestützte Änderungsvolumen, von null bis zum Doppelten des aktuellen Werts. Das untere Band ist die Review-Rekonstruktion, fällig bei jeder KI-gestützten Änderung; das obere Band ist die Nacharbeit, fällig nur bei den fehlerhaften. Illustrative Rechnung mit ersetzbaren Eingaben, kein Benchmark. Mit den Pfeiltasten links und rechts die Kurve entlangfahren.

KostenzeilePro MonatStunden im Monat
Review-Rekonstruktion4.500 €60 h
Nacharbeit an gechurntem Code1.080 €14,4 h
Incident-Pufferkeiner angesetzt0 h
Modellierte Kosten der Verification Debt nach der auf der Kostenmodell-Seite publizierten Beispielrechnung. Illustrative Rechnung mit ersetzbaren Eingaben, kein Benchmark.

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

Euer Zuschnitt

Was Verification Debt kostet, nach Teamzuschnitt

Sechs Zuschnitte, gerechnet mit derselben Arithmetik wie der Rechner darüber. Sucht die Zeile, die eurer Entwicklungsorganisation ähnelt, und zieht die Regler dann auf eure Zahlen. Über die Summe entscheidet das Volumen, nicht die Teamgröße – deshalb trägt eine zehnköpfige Agentur, die fast alles KI-gestützt ausliefert, mehr Schuld als eine 35-köpfige Abteilung, die KI kaum einsetzt.

Modellierte Kosten der Verification Debt für sechs Teamzuschnitte, gerechnet mit dem auf der Kostenseite veröffentlichten Modell bei durchgehend gleichem Stundensatz. Illustrative Rechnung mit ersetzbaren Eingaben, keine Umfragedaten und kein Branchen-Benchmark.
TeamzuschnittKI-gestützte ÄnderungenEntwicklungszeitModellierte KostenLohnt Verifikation?
Solo oder zu zweit2 Personen, die mergen · 60 % KI-gestütztFrühes Produkt, ein Repository24 im Monat14,9 h im Monat13.000im Jahr1.116im MonatUnter dem Band – eher nicht
Seed-Startup, ein Squad6 Personen, die mergen · 60 % KI-gestütztErste Einstellungen, täglich Releases72 im Monat44,6 h im Monat40.000im Jahr3.348im MonatÜber dem Band – ja
Agentur oder Dienstleister10 Personen, die mergen · 80 % KI-gestütztKundenprojekte, hoher KI-Einsatz160 im Monat99,2 h im Monat89.000im Jahr7.440im MonatÜber dem Band – ja
Scale-up, drei Squads18 Personen, die mergen · 60 % KI-gestütztSeries A bis B, mehrere Services216 im Monat133,9 h im Monat121.000im Jahr10.044im MonatÜber dem Band – ja
Mittelstands-IT35 Personen, die mergen · 40 % KI-gestütztInterne Systeme, vorsichtiger Einsatz280 im Monat173,6 h im Monat156.000im Jahr13.020im MonatÜber dem Band – ja
Konzern-Plattformteam80 Personen, die mergen · 40 % KI-gestütztViele Teams auf einer Plattform640 im Monat396,8 h im Monat357.000im Jahr29.760im MonatÜber dem Band – ja
Modellierte Kosten der Verification Debt für sechs Teamzuschnitte, gerechnet mit dem auf der Kostenseite veröffentlichten Modell bei durchgehend gleichem Stundensatz. Illustrative Rechnung mit ersetzbaren Eingaben, keine Umfragedaten und kein Branchen-Benchmark.Jede Zeile nutzt dieselben veröffentlichten Anker, damit die Zeilen vergleichbar bleiben: 20 Merges je Person · 2 % Nacharbeitsrate · 75 Vollkosten je Stunde · Break-even-Band 30 bis 40 Änderungen im Monat

Warum die Rechnung anfällt

Das Teure ist nicht der Code, der kaputtgeht

Die meisten Kostenargumente zum KI-Coding beginnen bei Fehlern. Das ist die kleinere Hälfte, und deshalb sieht die Zahl meistens erträglich aus.

Wer eine KI-gestützte Änderung reviewt, muss eine Frage beantworten, die sich früher von selbst beantwortet hat: Was sollte das eigentlich tun? Schrieb sie ein Mensch aus dem Team, kam die Absicht mit der Änderung mit – in einem Ticket, einem Gespräch oder der Form des Commits. Schrieb sie ein Modell, rekonstruiert wer reviewt die Absicht erst aus dem Diff, bevor er beurteilen kann, ob der Diff stimmt.

Diese Rekonstruktion fällt bei jeder Änderung an, nicht nur bei denen, die sich als falsch herausstellen. Sie erzeugt kein Ticket und keinen Fehlereintrag, landet also in keiner Budgetzeile, und sie ist der Grund, warum ein Team sich langsamer anfühlen kann, während es mehr ausliefert. Bei den Standardwerten oben sind es vier Fünftel der Summe.

Der Rest ist gewöhnliche Nacharbeit, und dort lohnt Genauigkeit darüber, was sich behaupten lässt und was nicht. Branchenweite Churn-Studien messen Codezeilen, die nach dem Merge überarbeitet werden. Das ist ein brauchbares Warnsignal und eine schlechte Fehlerrate. Dieses Modell rechnet das eine nicht in das andere um, sondern fragt euch nach einer Rate, die eure eigenen Tickets hergeben. Das vollständige Kostenmodell legt die Formel offen und auch, was es bewusst nicht tut, und die Anleitung zum Messen zeigt, wie ihr die Eingaben aus dem eigenen Repository holt statt aus einem Durchschnitt.

In Arbeit

Was eine Team-Version verändert

In Arbeit

Noch nicht gebaut. Steht hier, damit ihr die Richtung beurteilen könnt – nicht den Termin.

Reality Graph ist heute ein Werkzeug für eine Person: keine Konten, keine Seats, kein geteilter Zustand. Vier Dinge ändern sich, wenn das aufhört zu gelten. Nichts davon läuft schon, alles davon ist terminiert, und der Preis steht, damit ihr damit planen könnt.

  1. Eine Checkliste, an der jede Änderung gemessen wird, einmal fürs Team gesetzt

    Heute entscheidet jede Person für sich, was eine Änderung belegen muss, bevor sie als fertig gilt. Zwei Leute sagen dann beide „geprüft“ und meinen Verschiedenes. Eine gemeinsame Checkliste macht ihre Antworten vergleichbar, und erst das erlaubt euch, einem Review zu trauen, das ihr nicht selbst gefahren habt.

    Heute: Schreibt die Checkliste auf und einigt euch im Team darauf. Erzwungen wird sie noch nicht, aber der Streit darüber, was zählt, lohnt sich früh.

  2. Eine Review-Historie, die eine zweite Person öffnen kann

    Wer den Run gefahren hat, ist nicht länger die einzige Person, die sagen kann, was passiert ist. Das ist der Unterschied zwischen einem Beleg und einer Erzählung über einen Beleg.

    Heute: Das Protokoll ist eine schlichte Datei auf dem Rechner, der es erzeugt hat. Ihr könnt sie lesen und ihr könnt sie schicken.

  3. Rollen und Freigaben über ein Team hinweg

    Eine Freigabe heißt nicht mehr „ich habe meine eigene Arbeit freigegeben“. Wer was abzeichnen darf, wird eine Eigenschaft der Organisation statt des Terminals, in das es getippt wurde.

    Heute: Freigaben sind an ihren Run gebunden, damit wenigstens keine zur Dauererlaubnis wird.

  4. Zentrale Konfiguration für eine ganze Organisation

    Eine Stelle, an der steht, was jedes Projekt prüfen muss – statt einer Konvention, die genau so lange hält wie die Person bleibt, die sie aufgeschrieben hat.

    Heute: Konfiguriert wird pro Projekt. Bei drei Repositories geht das, bei dreißig schmerzt es.

39 Euro pro Nutzer und Monat

Der beabsichtigte Preis. Reality Graph hat heute weder Konten noch Seats, kaufen lässt sich also noch nichts.

Erwartet

Ende dieses Jahres

nicht gebaut · keine Konten, keine Seats, kein geteilter Zustand

Free deckt die kommerzielle Nutzung ab, es hindert also nichts eine Firma daran, es heute auf jedem Rechner laufen zu lassen – und das ist Absicht: Ein Startup soll sein eigenes Produkt stabilisieren können, ohne jemanden zu fragen. Die vier Änderungen oben sind der einzige Grund, für den sich eine Team-Version zu zahlen lohnen würde, und keine davon existiert bisher. Welche ihr zuerst nutzen würdet, entscheidet über die Reihenfolge, in der sie entstehen.

Fragen, die wirklich gestellt werden

Woher stammen die Zahlen in diesem Rechner?
Aus der Beispielrechnung, die auf der Kostenmodell-Seite veröffentlicht ist, nicht aus einer Studie über eure Branche. Zwei Eingaben liefert ihr selbst, die Nacharbeitsrate und die Rekonstruktionszeit sind illustrative Werte, die das Modell offen ausweist, und gerechnet wird genauso wie im Artikel. Nichts hier ist ein gemessenes Kundenergebnis, und die Seite sagt das neben der Zahl statt in einer Fußnote.
Warum steht der größte Posten in keinem Budget?
Weil die Review-Rekonstruktion bei jeder KI-gestützten Änderung anfällt, nicht nur bei denen, die sich als kaputt herausstellen. Herauszufinden, was eine Änderung tun sollte, bevor man sie beurteilen kann, erzeugt kein Ticket, keinen Fehlereintrag und keine Position, taucht also nirgends auf. Bei den Standardwerten sind es vier Fünftel der Summe, und das ist der Grund, warum die Zahl überrascht.
Rechnet das aus, was Reality Graph uns sparen würde?
Nein, und das bleibt so, bis es eine Vorher-Nachher-Messung gibt, auf die man das stützen kann. Eine solche Messung existiert nicht, jede Prozentzahl hier wäre also erfunden. Stattdessen benennt die Seite, welche Kostenzeile eine Verifikationspraxis adressieren soll, zitiert die eine publizierte Zahl auf dieser Seite und sagt, ab wann sich die Praxis gar nicht mehr rechnet.
Unser Team ist klein. Rechnet sich Verifikation trotzdem?
Unter etwa 30 bis 40 KI-gestützten Änderungen im Monat wahrscheinlich nicht. Das entscheidet das Volumen, nicht die Teamgröße: Zwei Leute, die den ganzen Tag Agenten laufen lassen, sind über der Schwelle, zwanzig mit wenig KI nicht. Der Rechner zeigt das Band und sagt ausdrücklich, wenn eure Eingaben darunter liegen – ein Argument, das nicht verlieren kann, ist keins.
Kann man die Team-Version heute kaufen?
Nein. Reality Graph hat weder Konten noch Seats noch geteilten Zustand, es gibt also nichts zu kaufen. Der Team-Preis steht veröffentlicht da, damit ihr damit planen könnt, und die Warteliste ist ein Gespräch darüber, welchen Teil ihr zuerst nutzen würdet. Genau das entscheidet die Reihenfolge, in der gebaut wird.
Was kostet ungeprüfter KI-Code ein Entwicklungsteam mit 20 Personen im Jahr?
Bei zwanzig Personen, die je rund zwanzig Pull Requests mergen, davon drei Fünftel KI-gestützt, landet das Modell bei etwa 134.000 Euro im Jahr – gerechnet mit 75 Euro Vollkosten je Stunde. Vier Fünftel davon sind Review-Rekonstruktion, nicht das Beheben von Fehlern. Nehmt die Zahl als nachrechenbare Arithmetik, nicht als Messung eures Teams: Die Tabelle der Teamzuschnitte oben zeigt dasselbe Modell in sechs Größen, und die Regler ersetzen jede Eingabe durch eure.
Was passiert mit den Kosten, wenn sich unser KI-gestütztes Änderungsvolumen verdoppelt?
Sie verdoppeln sich. Beide Kostenzeilen dieses Modells sind linear im Volumen, was der Graph als gerade Kanten statt als Kurve zeichnet – und genau das ist der nützliche Teil: Nichts beschleunigt sich an einer Schwelle, die Schuld wächst also mit der Verbreitung, statt euch bei irgendeiner Größe zu überfallen. Umgekehrt gilt dasselbe: Halbiert ihr den Anteil ungeprüft ausgelieferter Merges, halbiert sich die Rechnung.
Wie mache ich aus dieser Schätzung eine Zahl, die unser Finanzbereich akzeptiert?
Ersetzt zuerst die zwei Eingaben, die wirklich eure sind: die Vollkosten je Stunde, mit denen euer Controlling ohnehin rechnet, und eine Nacharbeitsrate aus euren eigenen Tickets statt aus einer Branchenstudie. Nennt dann die Stunden statt der Euro – Stunden sind das, was ihr umverteilt, und sie überstehen eine Diskussion über Stundensätze. Nehmt die Annahmenzeile mit: Eine Zahl, deren Methode sichtbar ist, lässt sich deutlich schwerer wegwischen als eine runde Summe.
Müssen wir etwas an euch senden, um den Rechner zu nutzen?
Nein. Die Rechnung läuft in eurem Browser, und die Zahlen, die ihr eingebt, verlassen ihn nicht. Die Seite hält fest, dass der Rechner benutzt wurde, und eine gerundete Schätzung, beides ohne jede Kennung – nie die Teamgröße und nie den Stundensatz, den ihr eingetragen habt.

Sagt uns, welchen Teil ihr zuerst nutzen würdet

Die Team-Version ist nicht gebaut. Welche der vier Änderungen oben für euer Team am meisten zählt, entscheidet über die Reihenfolge, in der sie entstehen – und das zu sagen dauert eine Minute.