Warum KI-Teams schneller liefern und schlechtere Produkte launchen: Das Intent-Debt-Problem

Code schreiben ist durch KI nahezu kostenlos geworden. Entscheiden, was zu schreiben ist, wurde schwieriger. Diese Lücke heißt Intent Debt, und sie wächst schneller als jede Legacy-Codebasis je gewachsen ist.

Garry Tan berichtet von 37.000 Codezeilen täglich über fünf Projekte, während er Y Combinator in Vollzeit leitet. Anthropics eigene Engineers haben 47 Tage stille Regressionen in Claude Code ausgeliefert, bevor sie am 23. April 2026 in einem öffentlichen Postmortem gefunden wurden. Beide Zahlen beschreiben dasselbe Problem, nur von entgegengesetzten Seiten.

Wer mehr Code als je zuvor schreibt und trotzdem schlechtere Ergebnisse als vor einem Jahr liefert, beobachtet Intent Debt in Echtzeit. Technical Debt war die Steuer auf langsames Coden. Intent Debt ist die Steuer auf langsames Entscheiden. Dieser Artikel benennt den Engpass, erklärt, warum Review- und Eval-Schichten ihn nicht erfassen, und zeigt die vier Maßnahmen, die ihn abbauen.

• KI hat Coding-Zeit um das 30- bis 100-fache komprimiert. Entscheidungszeit komprimiert sie um das 3- bis 5-fache. Die Lücke dazwischen ist der neue Engpass.

• Intent Debt liegt stromaufwärts jeder Review-Schicht. KI-Code-Reviewer, Evals und QA-Agents erkennen schlechten Code, aber nicht das, was falsch gebaut wurde, obwohl es funktioniert.

• Anthropics 47-tägige stille Regression in Claude Code ist ein Intent-Debt-Postmortem, verkleidet als Eval-Problem. Der Drift lag nicht im Code, sondern darin, worauf das Team seine Aufmerksamkeit richtete.

• Die Lösung ist strukturell, nicht taktisch. Sich freizuliefern ist nicht möglich. Sich freizuentscheiden schon, und zwar früher.

• webvise behandelt Intent Capture als eigentliches Deliverable, nicht als kostenlose Pre-Sales-Aktivität. Erfahren Sie, wo das für Ihr Team gilt.

Was Intent Debt wirklich ist

Technical Debt ist der Begriff, den Ward Cunningham 1992 geprägt hat, um die künftigen Kosten zu beschreiben, die entstehen, wenn man eine schnelle Lösung einer sauberen vorzieht. Der Trade-off hatte klare Ökonomie: früher liefern, später höhere Wartungskosten als Zinsen zahlen, das Kapital liegt als refaktorierbarer Code in der Codebasis.

Intent Debt folgt derselben Logik. Hier tauscht man schnelleren Code gegen unschärfere Entscheidungen. Früher geliefert wird, weil die KI die Implementierung in 30 Minuten statt in drei Tagen schreibt. Die Zinsen sind alles, was sich stromabwärts anhäuft, wenn das Team nie festgelegt hat, wie das richtige Ergebnis aussehen soll.

Der Begriff fehlt, weil der Trade-off neu ist. Martin Fowlers Schriften über Benennung und Design Intent gehen von einer Welt aus, in der das Schreiben von Code der teure Schritt war, also lohnte sich ein durchdachtes Design durch weniger Nacharbeit.

Diese Annahme kehrte sich 2024 um. Wenn eine Neuentwicklung einen Tag dauert, rechnet sich der Design-Schritt nicht mehr so wie früher. Teams registrieren das und überspringen ihn, genau den Schritt, bei dem Intent so verdichtet wird, dass andere damit arbeiten können.

Zwei Failure Modes aus eigener Erfahrung.

Erstens: Ein Feature, das ohne KI drei Wochen gebraucht hätte, wird in drei Tagen geliefert. Es funktioniert. Es löst aber ein Problem, das Nutzer nicht haben, denn die Spec war eine Slack-Nachricht und die Implementierung übernahm ein Cursor-Agent. Die Baukosten waren so niedrig, dass das Team nie hinterfragt hat, ob es sich überhaupt lohnt.

Zweitens: Ein Senior Engineer beerdigt sechs Produktrichtungen in einem Jahr. Keine stirbt aus technischen Gründen. Jede scheitert im Pre-Sell-Schritt, der immer wieder übersprungen wird, weil Code schreiben produktiver anfühlt. Dieser Engineer bin ich, und die Postmortem-Kosten dieser sechs Richtungen übersteigen jede Technical Debt, die je abgetragen wurde.

Beide Geschichten sind Intent Debt mit Belegen. Die meisten Engineering-Teams versuchen noch immer, sie auf der Build-Ebene zu lösen: ein weiterer Reviewer, ein weiteres Eval, ein weiterer Linter. Der Fix sitzt eine Ebene höher. Wer solche Belege sammelt, findet in webvise einen Partner, der von Anfang an auf diese Inversion ausgerichtet ist.

Die Zahlen hinter der Verschiebung

Die deutlichsten First-Party-Daten zur Asymmetrie stammen aus Garry Tans gstack-ETHOS-Datei, veröffentlicht im April 2026. Tan liefert ein Open-Source-Agent-Toolkit aus Y Combinator und misst seine Agents mit expliziten Human-vs.-KI-Kompressionsraten für jeden Task-Typ.

Die Tabelle spaltenweise lesen: Boilerplate komprimiert 100x, Tests 50x, Feature-Arbeit 30x. Architektur und Research komprimieren 5x beziehungsweise 3x.

Die unteren drei Zeilen sind Intent-Arbeit. Sie komprimieren, aber mit einem Zehntel der Rate der oberen drei. Das ist der strukturelle Ursprung von Intent Debt: Coden ist heute nahezu kostenlos, Entscheiden bleibt teuer.

Konkret: Wenn ein Team früher 80 % eines Engineering-Tages für Code und 20 % für Entscheidungen aufgewendet hat, sehen die Verhältnisse nach einer 30-fachen Code-Kompression ungefähr so aus: 12 % Code, 88 % Entscheidungen. Die meisten Teams haben die gleiche Besetzung, den gleichen Meeting-Rhythmus und dieselbe Review-Struktur behalten und beobachten seither, wie die zweite Spalte überläuft.

Dieser Überlauf ist Intent Debt in der Praxis.

Drei Symptome, die zeigen, dass man es bereits trägt

Intent Debt bleibt unsichtbar, bis man ihn benennt. Drei Symptome zeigen sich quer durch Teams.

Scope-Cutting-Reflex bei bereits abgeschlossenen Kosten

Drei statt zehn Tests zu schreiben, die Dokumentation wegzulassen, 80 % als ausreichend zu bezeichnen: dieser Instinkt ergab Sinn, als menschliche Zeit die bindende Ressource war. Mit KI im Loop kostet die vollständige Version dieselben Minuten wie der Workaround.

Der Reflex ist Legacy-Denken, automatisch angewendet. Die eigentlichen Kosten sind die Entscheidungsgewohnheit, die sagt: früher liefern ist besser als richtig liefern, obwohl früher liefern heute keine Zeit mehr spart.

Mehr Reviewen, weniger Entscheiden

Elie Steinbock hat am 20. April 2026 eine These veröffentlicht, die Review als neuen Engpass benennt. Er listet sieben Verteidigungsschichten auf, von KI-Code-Reviewern wie Cubic und CodeRabbit bis zu dedizierten QA-Agents und fokussierter Observability. Teams übernehmen die Schichten, und die Review-Fläche nimmt mehr vom Tag in Anspruch.

Intent Debt liegt stromaufwärts all dieser Tools. KI-Reviewer erkennen schlechten Code, nicht das falsch gebaute Feature. Ein QA-Agent, der jeden Flow in jedem Release durchläuft, sagt, ob der Flow funktioniert, nicht ob er existieren sollte.

Stiller Drift, der erst in Postmortems sichtbar wird

Anthropic veröffentlichte am 23. April 2026 ein Postmortem über 47 Tage stille Regressionen in Claude Code. Die Headline-These: "Evals erfassen keinen Drift." Die tiefere These ist, dass Drift sich in der Lücke zwischen dem, was das Team beabsichtigte, und dem, was das System tatsächlich tat, akkumuliert.

Jedes Team, das KI-unterstützt entwickelt, hat gerade sein eigenes 47-Tage-Fenster offen. Die meisten werden es erst im Postmortem finden.

Warum Reviews und Evals ihn nicht erfassen

Review-Tools beantworten die Frage: "Hat der Code getan, was die Spec verlangt?" Eval-Suites beantworten: "Hat sich das Modell so verhalten, wie das Eval erwartet hat?" Beides sind korrekte, enge Fragen. Beide behandeln Spec und Eval als Wahrheit.

Intent Debt akkumuliert sich eine Ebene darüber. Die Kosten liegen in der Lücke zwischen dem, was der Kunde brauchte, was das Briefing sagte und was die Spec erfasst hat. Bis der Code vor einem Review-Tool landet, hat die Spec den Intent bereits festgeschrieben. Ein Reviewer kann keinen Spec-Fehler erkennen, sondern nur Implementierungsfehler gegen eine fehlerhafte Spec markieren.

Das ist die gleiche Struktur wie Anthropics Drift. Das Claude-Code-Team hatte Evals. Die Evals haben bestanden.

Der Drift lag darin, was die Evals maßen, versus was Nutzer tatsächlich erlebten. 47 Tage grüne Ampeln, echte Nutzer mit täglich sichtbaren Regressionen. Die Lösung liegt in engerem Feedback zwischen den Personen, die entscheiden, was gemessen wird, und denen, die das Produktionssignal beobachten.

Review-Engpass-Denken behandelt das als Tooling-Problem. Es ist ein Layering-Problem. Als Ergänzung bietet der frühere Artikel darüber, warum KI-generierte Software trotzdem Engineering-Review braucht, die Build-Layer-Perspektive. Intent Debt abzubauen erfordert eine andere Frage, früher gestellt.

Die Entscheidungsebene komprimiert nicht wie Code

Tans Formulierung, warum das strukturell ist: "Man liefert den Geschmack durch das Gespräch mit dem Agent." Der Agent liefert Vollständigkeit. Der Mensch liefert Richtung und Urteil. Geschmack läuft nicht auf derselben Kompressionskurve wie Code.

Drei Bestandteile von Geschmack, die Code-Generierung nicht ersetzen kann.

Das richtige Problem wählen

Alex Vaccas Services-as-Software-These, im April 2026 über Sequoia-Partner Julien Bek veröffentlicht, fasst die größere Version davon. Software-Anbieter, die das Tool verkaufen, laufen dem Modell für immer hinterher. Unternehmen, die die Arbeit besitzen und das Modell zur Lieferung nutzen, verbessern sich jedes Mal, wenn das Modell besser wird.

Dieselbe Logik gilt innerhalb von Teams. Engineers, die das richtige Problem wählen, werden besser, wann immer das Modell besser wird. Engineers, die nur gegen vorgegebene Specs ausführen, werden über Nacht austauschbar.

Wissen, wann man aufhört

KI-Tools sagen nie: Stopp. Ein LLM bearbeitet den siebzehnten Winkel desselben Problems mit derselben Begeisterung wie den ersten, und jede Antwort fühlt sich wie Fortschritt an. Ohne eine externe Abbruchbedingung läuft die Schleife endlos.

Erfahrene Engineers setzten den Abbruch früher durch Langeweile oder Zeitdruck. Beide Budgets sind jetzt unbegrenzt. Die Abbruchbedingung muss explizit vorab festgelegt werden, vor dem ersten Prompt.

Das Widerspruchsrecht erfahrener Engineers

Die wertvollste First-Party-Leistung eines Senior Engineers ist der Widerspruch: die Botschaft "Das ist das Falsche zu bauen", die ein Quartal Execution im Voraus verhindert. KI-Agents widersprechen nicht. Sie bauen, was verlangt wird, vollständig, auf einer 100-fachen Kompressionskurve.

Geliefert wird, was bestellt wurde, und erst danach stellt sich heraus, dass das Falsche bestellt wurde.

Vier Maßnahmen, die Intent Debt abbauen

Diese Maßnahmen sind taktisch. Sie setzen voraus, dass das Team das Problem bereits benannt und aufgehört hat, es auf der Review-Ebene aufzufangen.

Pre-Sell, bevor der Editor geöffnet wird

Das ist die Maßnahme, die auf die harte Tour gelernt wurde. Wer etwas für jemand anderen baut, holt eine mündliche Zusage, eine Anzahlung oder eine Absichtserklärung, bevor ein Agent eine einzige Zeile schreibt.

Verbale Begeisterung, Launch-Upvotes und eine Warteliste ohne echtes Risiko sind schwache Nachfragesignale. Die Baukosten sind so niedrig, dass der einzige verbleibende Filter ist, ob der Kunde zahlen wird.

Die Spec als dauerhaftes Artefakt behandeln

Pre-KI war die Spec ein Arbeitsdokument, der Code das Artefakt. Post-KI ist der Code regenerierbar, die Spec das Dauerhafte.

Specs sollten den Kunden, die Failure Modes und die Erfolgskennzahl explizit nennen. Unter Versionskontrolle neben dem Code ablegen. Wenn die Spec sich ändert, ist die Regenerierung trivial; wenn die Spec falsch ist, hilft keine Regenerierung.

Ein Two-Model Decision Review durchführen

Ein einzelnes LLM rationalisiert jede Richtung; ein zweites Modell, das explizit zum Widerspruch eingeladen wird, erfasst die Hälfte der Fehlentscheidungen. Das Muster funktioniert im Code Review, wo Claude, Codex und Gemini gegenseitig jedes gelieferte Feature gegenchecken.

Der höherwertige Einsatz ist das Decision Review: Zwei Modellen die Spec zeigen, sie um Widerspruch bitten, den Widerspruch abwägen, bevor gebaut wird. Die Kosten sind Rundungsfehler im Vergleich zum Bau des Falschen.

Eine Datei mit gestoppten Richtungen führen

Jedes Produkt, Feature oder jede Kampagne, das vor der Lieferung gestoppt wurde, kommt in ein Dokument, mit dem Grund. Der Grund zählt mehr als die Anzahl. Vor dem Start von etwas Neuem lesen.

Das Muster, warum Richtungen sterben, ist der günstigste verfügbare Intent-Debt-Abbau, und fast jedes Team überspringt ihn. Wer prüfen möchte, wo diese Maßnahmen im eigenen Team greifen, dem hilft webvise weiter.

Einen Web-Partner in der KI-Ära wählen

Der teuerste Fehler, den ein KI-Zeitalter-Team macht, ist die Beauftragung einer Agentur, die nur die Build-Schicht abdeckt. Build ist heute der günstige Teil. Die Entscheidungsebene, was geliefert wird, wann gestoppt wird, wer der Nutzer wirklich ist, trägt den Multiplikator.

Die meisten Agenturen bepreisen noch immer den Build, weil ihr Margenmodell das kennt. webvise wurde um die Inversion herum aufgebaut.

Die Engagements für KI-Automatisierung und Full-Stack-Applikationen starten mit einem Discovery Sprint, der eine schriftliche Spec, eine Liste gestoppter Richtungen und ein Two-Model Decision Review für jeden festgeschriebenen Scope-Punkt liefert. Ein Feature in einem Tag zu liefern ist möglich. Geliefert wird es erst, wenn das Team sich geeinigt hat, wie Erfolg in der Produktion aussieht.

Wer in diesem Quartal mehr Code als je zuvor geliefert hat und sich weiter von einem funktionierenden Produkt entfernt fühlt als vor sechs Monaten, sollte ein Discovery-Gespräch buchen. Der schnellste Weg, Intent Debt abzubauen, ist aufzuhören, neuen anzuhäufen.