2026-08-04

Braucht es im KI-Zeitalter noch ein MVP? 211 Millionen Codezeilen zeigen: Nacharbeit von 3,3 % auf 7,1 %

Wirft man einer KI eine Idee hin, lautet in acht von zehn Fällen ihr erster Satz: „Lass uns mit einer minimal funktionsfähigen Version anfangen.“

Das klingt nach einem Urteil. Es ist eine Erinnerung. Das Agile Manifesto stammt von 2001, The Lean Startup von 2011, und diese beiden Texte samt der mehreren hunderttausend Blogbeiträge, Kurse und Retrospektiven, die daraus hervorgingen, stecken alle in den Trainingsdaten. Sie empfiehlt Iteration nicht, weil sie ihre eigene Rechnung aufgemacht hätte.

Sie rechnet unsere. Und diese beiden Rechnungen sind gegenläufig aufgebaut.

Vier Prämissen trugen das MVP — drei tragen noch

Iteration ist kein Naturgesetz. Sie ist die optimale Antwort unter einem bestimmten Satz von Randbedingungen, und der sieht so aus:

Code schreiben ist langsam und teuer. Ein Feature braucht von „verstanden“ bis „läuft“ Personentage.
Ändern kostet mehr als Schreiben. Wer ändern will, muss erst lesen, und lesen heißt, wieder in den Kopf eines anderen zu steigen — oder in den eigenen von vor drei Monaten.
Anforderungen werden unterwegs schärfer. Nutzer wissen erst, was sie wollen, wenn sie etwas sehen; früh etwas hinzustellen zahlt sich also aus.
Die entscheidende: Zwischen einer groben und einer vollständigen Umsetzung klafft eine große Kostenlücke.

Diese letzte ist das ökonomische Fundament des MVP. Erst mal in localStorage ablegen, erst mal keine Rechteverwaltung, erst mal ein paar Konfigurationswerte fest verdrahten — die so gesparten Wochen waren echt, und sie stattdessen in die Prüfung einer Annahme zu stecken, war tatsächlich der bessere Handel.

Drei der vier gelten heute noch. Die vierte ist weg.

localStorage und PostgreSQL: in den Händen einer KI liegen Minuten dazwischen

Ein Thread auf V2EX bringt es am saubersten auf den Punkt (t/1216691, Titel: „Hat MVP-Denken im Zeitalter des KI-Codings ausgedient?“). Die Worte des Verfassers: Cursor zu beschreiben „speichere die Daten in localStorage“ und zu beschreiben „nimm PostgreSQL mit Connection Pool“ unterscheidet sich um wenige Minuten Generierungszeit.

Wenn die Kosten gleich sind, warum dann die einfache Variante bauen?

Dieser eine Satz zieht das halbe Fundament weg. Was man spart, sind keine Wochen mehr, sondern Minuten — während alles, was man sich dafür einhandelt, unverändert bleibt: eine Speicherschicht, die ersetzt werden muss, eine Reihe darauf aufbauender Aufrufe, eine Migration, die man neu machen darf.

Grob ist nicht mehr billig. Es ist nur noch unvollständig.

Die Rechnung der KI: Hauptposten ist der Kontext, nicht die Aufgabe

Die andere Hälfte des Fundaments bricht auf der Ebene der Kostenstruktur weg, und diese Schicht ist besser versteckt.

Läuft eine agentische Aufgabe, ist der Großteil der Eingabe-Token nie deine Aufgabenbeschreibung. Es sind der System-Prompt, die Repository-Karte, der Gesprächsverlauf, die gelesenen Dateien. Die Aufgabenbeschreibung ist darin eine Rundungsgröße.

Was daraus folgt, ist durchweg gemessen:

Bei jedem erneuten Versuch wird der gesamte Kontext neu gesendet. Zwei Wiederholungen können die Kosten einer Sitzung verdreifachen.
Rechnet man den Kontext-Overhead mit, liegen die realen Kosten beim 3- bis 5-Fachen der naiven Schätzung — etwa 0,27 bis 3,25 Dollar pro PR, und über 20 Dollar für eine einzelne Aufgabe in einem komplexen Repository ist nichts Ungewöhnliches.
Das arXiv-Papier Cheap Code, Costly Judgment (2607.01087) hat gemessen, dass agentische Aufgaben das 1000-Fache der Token eines gewöhnlichen Code-Chats verbrauchen, bei bis zu 30-facher Varianz über wiederholte Läufe derselben Aufgabe.

Nun beide Iterationen nebeneinander gerechnet.

Ein Mensch, der eine Arbeit in drei Phasen teilt, zahlt pro Phase ungefähr dasselbe, weil er sich an die vorige erinnert. Der Kontext sitzt im Kopf, und ihn abzurufen kostet nichts.

Die KI erinnert sich nicht. Sie kauft den Kontext in jeder Phase neu.

Dieselben drei Phasen	Mensch	KI
Hauptkosten je Phase	die Arbeit selbst	Wiederaufbau des Kontexts
Erinnerung an die Vorphase	im Kopf, Abruf gratis	existiert nicht, muss neu geladen werden
Gesamtkosten über drei Phasen	≈ drei Arbeitseinheiten	≈ drei Arbeitseinheiten + zwei Wiederaufbauten
Grenzkosten eines weiteren Schnitts	ein Gespräch	ein vollständiger Neukauf des Kontexts
Was Iteration einkauft	Gelegenheiten, nicht falsch abzubiegen	dieselben Gelegenheiten, zuzüglich Reibungsgebühr

Iteration ist für Menschen eine Versicherung und für eine KI eine Reibungsgebühr.

GitClear hat die Nacharbeit gemessen: 3,3 % → 7,1 %

Alles bisher war Herleitung. Was folgt, ist Messung.

GitClear hat 211 Millionen Zeilen geänderten Code analysiert und dabei eine Kennzahl namens Churn verfolgt: den Anteil an Code, der binnen Tagen nach dem Merge erheblich umgeschrieben oder gelöscht wird. Sie misst genau eines — dass es beim ersten Mal nicht richtig war.

Jahr	Churn
vor 2023 (Basislinie)	3,3 %
2024	5,7 %
2025	7,1 %

Mehr als eine Verdopplung in zwei Jahren. Weitere Kennzahlen derselben Untersuchung zeigen in dieselbe Richtung:

Copy-Paste innerhalb eines Commits +41 %
Duplizierte Codeblöcke +81 %
Fehler verdeckende Konstrukte +47 %
Dateiübergreifende Funktionsaufrufe, der Indikator für Wiederverwendung: −35 %
Zeilenverschiebungen durch Refactoring: −70 %

GitClear sortiert die von KI verstärkte Nacharbeit in drei Sorten, und jede ist die unmittelbare Folge davon, zuerst etwas Halbfertiges auszuliefern:

Falscher Ort — Logik und Syntax stimmen, sitzen aber an der falschen Stelle der Architektur; jemand verschiebt sie später
Zweimal gebaut — vorhandene Funktionalität neu implementiert, statt sie wiederzuverwenden
Tage später umgeschrieben — gemergt und dann wegen eines Randfalls oder einer verletzten Konvention erheblich geändert

In derselben Untersuchung tragen von KI verfasste PRs im Schnitt 10,83 Probleme, von Menschen verfasste 6,45. Faktor 1,7.

Das Erleben der Entwickler passt zu diesen Zahlen. Aus der Stack Overflow Developer Survey 2026:

84 % setzen KI-Werkzeuge ein
45 % sagen, das Debuggen von KI-generiertem Code dauert länger, als es selbst zu schreiben
66 % nennen als größte Frustration Ergebnisse, die „fast richtig, aber nicht ganz“ sind
Und das Vertrauen in KI-Ausgaben liegt bei 3 %

Eine weitere Erhebung beziffert 43 % der KI-generierten Codeänderungen als solche, die in der Produktion nachgebessert werden müssen.

„Fast richtig“ ist der entscheidende Ausdruck. Es bedeutet, dass das Problem nicht in dem Moment auftaucht, in dem du abnimmst, sondern nach dem Merge — und damit genau auf der nächsten Iteration landet. Die Runde, die du gespart zu haben glaubtest, wird später in Rechnung gestellt.

„Einmal richtig“ ist nicht „alles auf einmal“: Liefergranularität und Ausführungsgranularität

Hier rutscht man am leichtesten in eine Parole: Schluss mit Iteration, alles auf einmal. Das ist falsch, und gefährlich falsch.

Zwei Granularitäten müssen getrennt bleiben:

Ausführungsgranularität: eine Änderung nach der anderen, jede verifiziert. Gilt heute unverändert, sogar stärker — eine KI, die zehn Dateien gleichzeitig anfasst, übersteigt das, was du prüfen kannst.
Liefergranularität: ob das, was du diese Runde übergibst, fertig ist.

„Einmal richtig“ meint das Zweite. Beschränkt wird der Fertigstellungsgrad, nicht die Zahl der Funktionen.

Der Umfang darf schmal sein — so schmal wie eine Seite, ein Endpunkt. Aber der Teil, den du dir für diese Runde vorgenommen hast, muss vollständig sein: echte Datenstrukturen statt Platzhalter; alle vier Zustände vorhanden — Laden, Leer, Fehler, Erfolg —, nicht nur der Idealpfad; etwas, das wirklich läuft und von einem Menschen benutzt werden kann, kein Screenshot.

Das größte Problem am Wort MVP ist, dass es „schmaler Umfang“ und „grob gebaut“ im Paket verkauft hat. Früher hingen die beiden tatsächlich zusammen — sparen hieß, an beidem zu sparen. Jetzt lassen sie sich trennen: Der Umfang soll weiterhin schmal sein, aber grob spart kein Geld mehr.

„MVP heißt Annahmen prüfen und hat mit KI nichts zu tun“ — zwei der vier Einwände halten

Die Antworten unter jenem V2EX-Thread sind wertvoller als der Ausgangsbeitrag. Der Reihe nach:

1. „Der Kern des MVP ist das Prüfen einer Annahme. Das hat nichts mit Code zu tun und nichts damit, ob KI im Spiel ist.“

Hält — und zeigt genau, wo das Problem liegt. Das Wort MVP hat immer zwei Dinge zusammengepackt: eine Annahme prüfen und eine unvollständige Umsetzung ausliefern. Früher waren sie untrennbar, weil der einzige billige Weg, eine Annahme zu prüfen, darin bestand, etwas Grobes zu bauen. Sie haben sich getrennt. Prüfe die Annahme, unbedingt — nur kannst du das inzwischen mit etwas Vollständigem tun.

2. „Du wirst nie alle Bedürfnisse potenzieller Nutzer auf einmal kennen.“

Hält, und steht nicht im Widerspruch zu „einmal richtig“. Niemand verlangt, alle Funktionen in einem Durchgang zu bauen. Verlangt wird, dass der Teil, den du in diesem Durchgang baust, nicht halb liegen bleibt.

3. „Bei logisch komplexen Projekten, besonders Systemen mit verschachtelten Fachabläufen und Zustandsautomaten, wird alles auf einen Schlag zu Matsch.“

Ein echtes Problem, aber eines der Ausführungsgranularität. Ein komplexer Zustandsautomat wird selbstverständlich Schritt für Schritt gebaut und bei jedem Schritt verifiziert. Das ist kein Argument dafür, eine Version auszuliefern, von der man bereits weiß, dass man sie neu schreiben wird.

4. „Mit KI ist Iterieren rasend schnell und kostet fast nichts.“

Dieser hält nicht. Die beiden Abschnitte darüber sind sein Gegenbeispiel: schnell geworden ist die Erzeugung, nicht die Konvergenz. Dass Churn von 3,3 % auf 7,1 % steigt, misst exakt diese Lücke.

Nachdem „keine Entwicklung in Phasen“ in meinen globalen Regeln steht

In meinen eigenen globalen Regeln steht eine Zeile fest verdrahtet: keine phasenweise Entwicklung, Lieferung bedeutet fertiges Produkt, kein MVP und keine Teiletappen.

In konkrete Handlungen übersetzt heißt das:

Schon im ersten Durchgang echte Datenstrukturen und echte Inhalte — kein Lorem ipsum, keine Fake-Daten
Alle vier Zustände zusammen ausliefern: Laden, Leer, Fehler, Erfolg
Vor der Abgabe selbst einmal laufen lassen — im Browser öffnen, auf der Kommandozeile ausführen, den Endpunkt mit curl ansprechen

Der Preis ist real: Die erste Beschreibung wird deutlich länger. Grenzen, Zustände und Datenstrukturen müssen vor dem Anfangen durchdacht sein. Diese Arbeit hat die KI nicht übernommen; sie ist nur von „muss man beim dritten Nacharbeitsdurchgang notgedrungen durchdenken“ nach „denkt man vor dem ersten Durchgang freiwillig durch“ gewandert.

Der Ertrag ist ebenso direkt: Man erklärt dieselbe Sache nicht ein zweites und drittes Mal. Und das Wiedererklären ist genau der teuerste Posten auf der Rechnung oben.

Wie schmal der Umfang zu schneiden ist — dabei hilft die KI nicht

Diese Frage hat weiterhin keine Antwort.

„Einmal richtig“ setzt voraus, dass der Umfang richtig geschnitten wurde. Zu breit geschnitten, wird aus „einmal“ ein „sehr langes einmal“. Zu schmal geschnitten, prüft das Gebaute keine Annahme mehr. Wo dieser Schnitt liegt, hängt am Urteil über Nutzer und Situationen — und der Titel jenes Papiers hat bereits alles gesagt: Code ist billig geworden, Urteilsvermögen nicht.