Aufwand-Inversion: Wenn der Code schneller fertig ist als die Schätzung erlaubt

Die Ausgangshypothese

Am 11. Mai 2026, dem Tag Null eines Softwareprojekts, formulierte ich eine Erwartung: Der tatsächliche Aufwand wird den geschätzten systematisch übersteigen. Mindestens 30 Prozent Mehraufwand gegenüber der Vorabschätzung, so die Prognose. Die Begründung war klassisch: erfahrener Entwickler, teilweise ein neuer Tech Stack (Tailwind & Vite), dazu ein noch wenig erprobter Workflow mit KI-Werkzeugen. Wer seit 27 Jahren Software baut, kennt dieses Muster. Neue Technologien kosten immer mehr als gedacht.

Die Hypothese war falsch. Nicht knapp daneben, sondern in der Richtung verkehrt.

Was gemessen wurde

Das Projekt, ein Touch-Typing-Trainer namens Daktylo, diente als Vehikel und Experiment für eine empirische Untersuchung KI-augmentierter Softwareentwicklung. Jeder Coding-Task wurde vorab geschätzt und anschließend gemessen. Die Messung erfasste die reine Coding-Schicht: die Zeitspanne zwischen Prompt-Übergabe an Claude Code und dem fertigen Commit. Der Quotient aus tatsächlicher und geschätzter Zeit ergibt den Aufwand-Faktor. Ein Faktor von 1,0 bedeutet: Schätzung und Realität stimmen überein. Ein Faktor von 0,5 bedeutet: die Aufgabe war in der Hälfte der geschätzten Zeit erledigt.

Die Schätzungen stammten aus der Konzeptphase. Sie wurden in einem Dialog mit Claude.ai erarbeitet, also selbst KI-gestützt, und orientierten sich an der Erfahrung eines erfahrenen Entwicklers mit einem teilweise unbekannten Stack. Nicht an der Erfahrung eines Entwicklers, der mit einem KI-Agenten arbeitet. Diese Unterscheidung erwies sich als entscheidend.

Die Daten

Phase 1: Setup (Tag 2)

Die ersten beiden Tasks bestätigten die Hypothese. Setup-Arbeiten mit einem teilweise unbekannten Stack dauerten tatsächlich länger als geschätzt. TASK-001 enthielt einen schweren Zwischenfall (Claude Code löschte versehentlich Dokumentationsdateien und musste wiederhergestellt werden), der den Faktor in die Höhe trieb.

Phase 2: Infrastruktur steht (Tag 5-9)

Zwischen Tag 2 und Tag 5 lag die vollständige Infrastruktur-Etablierung: CLAUDE.md, Heredoc-Commit-Pattern, Plan-Mode-Konvention, TypeScript strict, Zod-Validierung, Vitest. Ab TASK-003 fiel kein einziger Faktor mehr über 0,5. Die Trendlinie war monoton fallend: 0,50, 0,50, 0,30, 0,40, 0,20, 0,13, 0,10, 0,06.

TASK-010, die visuelle Tastatur-Komponente, wurde auf vier Stunden geschätzt und war in einer Viertelstunde fertig. Faktor 0,06. Sechs Prozent der geplanten Zeit.

Phase 3: Routine (Tag 11-15)

Median dieser acht Tasks: 0,14. Die Aufgaben wurden in einem Siebtel der geschätzten Zeit fertig.

Ausreißer

Zwei Tasks fielen deutlich aus dem Muster:

Beide waren visuelle Layout-Tasks, bei denen die Korrektheit nicht durch automatisierte Tests, sondern nur durch menschlichen Browser-Vergleich verifizierbar war. TASK-027 hatte zusätzlich eine unerkannte Abhängigkeit. Diese Ausreißer bestätigen eher die Regel: Wo der Mensch im Verifikations-Loop bleibt, nähert sich der Faktor dem traditionellen Bereich.

Was Aufwand-Inversion bedeutet

Der Begriff „Aufwand-Inversion” beschreibt nicht bloß, dass Aufgaben schneller erledigt werden als geplant. Das wäre ein Schätzfehler. Die Inversion liegt in der Richtung: Die Ausgangshypothese erwartete Überschreitung (+30%), die Realität zeigte Unterschreitung um 83-94% bei etablierter Infrastruktur. Das Vorzeichen hat gewechselt, und die Abweichung ist eine ganze Größenordnung von der Erwartung entfernt.

Der Median-Faktor über alle Tasks nach der Setup-Phase liegt bei 0,13-0,17. Eine Aufgabe, die ein erfahrener Entwickler auf zwei Stunden schätzt, ist in 15-20 Minuten Coding-Zeit fertig, wenn die folgenden Bedingungen erfüllt sind:

1. Die Infrastruktur steht (TypeScript strict, Linting, Testing, CI-Konventionen).
2. Der Prompt ist vorbereitet (Konzept-Entscheidungen vorab in Claude.ai geklärt).
3. Die Aufgabe hat eine klare Spezifikation mit Akzeptanzkriterien.
4. Die Verifikation ist automatisierbar (Tests, Typprüfung, Lint).

Was die Daten nicht zeigen

Hier liegt die methodisch wichtigste Einschränkung dieses Befunds, und sie wurde nicht von außen herangetragen, sondern im Projektverlauf selbst entdeckt.

Die Aufwand-Faktoren messen ausschließlich die Coding-Schicht. Die Zeitspanne zwischen Prompt und Commit. Sie messen nicht den Gesamtaufwand eines Arbeitstages. Und die Arbeitstage waren regelmäßig länger als geplant:

Tag	Geplantes Ende	Tatsächliches Ende
13	20:10	~23:30
14	~18:00	22:45
20	~16:10	~20:05

Wohin verschwindet die gewonnene Zeit? In Schichten, die in der Coding-Schätzung nicht vorkommen:

Die Konzeptschicht: Jede Coding-Aufgabe beginnt mit einer Klärung in Claude.ai. Welche Architektur? Welche API? Welche Variante? Die niedrigsten Coding-Faktoren (TASK-017: 0,09, TASK-025: 0,11) hatten die gründlichsten Konzept-Vorgespräche. Die Konzeptarbeit ist nicht kostenlos, sie wird nur nicht gemessen.

Die Dokumentationsschicht: Forschungstagebuch, Tagesabschlüsse, Konzept-Notizen, ADR-Pflege, INBOX-Dispatch. In einem Forschungsprojekt ist das erwartbar, aber auch in einem gewöhnlichen Projekt fallen Code-Reviews, Architekturdokumentation und Wissenstransfer an.

Die Prozessschicht: Sync-Workflows, Budget-Tracking, Datei-Management zwischen Claude.ai und Claude Code, Session-Starts, Token-Verbrauchsplanung. Emergente Workflows, die die Wandzeit verlängern, obwohl die eigentlichen Aufgaben schneller werden.

Die ursprüngliche Hypothese H4 („P1 unterschätzt den Aufwand um 30%”) erwies sich damit als methodisch unterspezifiziert. Sie fragte nach dem Aufwand, ohne zu unterscheiden, welche Schicht gemeint war. Bei der Coding-Schicht ist sie klar falsifiziert, in die entgegengesetzte Richtung. Bei der Wandzeit pro Tag ist sie möglicherweise bestätigt.

Diese Erkenntnis führte zur Aufspaltung in drei differenzierte Hypothesen:

H4a (Coding-Schicht): Claude.ai überschätzt den Coding-Aufwand für Claude Code systematisch. Median-Faktor ~0,15. Klar bestätigt.

H4b (Wandzeit/Tag): Wandzeit pro Tag liegt regelmäßig über Plan, wegen der Nicht-Coding-Schichten. Bestätigt durch die Daten von Tag 13, 14, 15 und 20.

H4c (Gesamtaufwand MVP): Offen. Der MVP wurde am 7. Juni 2026 veröffentlicht, einen Tag vor der Vier-Wochen-Deadline. Im Zeitrahmen, aber ohne Puffer.

Was daraus folgt

Für Schätzungen

Klassische Aufwandschätzungen, ob sie von Menschen oder von KI-Systemen stammen, kalibrieren auf den Erfahrungswert manueller Entwicklung. In einem KI-augmentierten Workflow mit etablierter Infrastruktur ist die Coding-Schicht nicht der Engpass. Schätzungen, die nur diese Schicht betrachten, werden systematisch zu hoch ausfallen. Schätzungen, die die Nicht-Coding-Schichten ignorieren, werden systematisch zu niedrig ausfallen. Beides gleichzeitig.

Für den Workflow

Der niedrigste Aufwand-Faktor korreliert nicht mit einem bestimmten Prompt-Modus (Plan vs. Direkt+STOP), sondern mit der Qualität der Vorarbeit. Tasks, bei denen alle Entscheidungen vor dem Prompt geklärt waren, hatten die niedrigsten Faktoren. Die Wertschöpfung verschiebt sich von der Coding-Schicht in die Konzept-Schicht.

Für die Forschung

Das Phänomen ist bisher schwach dokumentiert. Die meisten Berichte über KI-gestützte Entwicklung messen „Produktivitätsgewinne” als Prozentzahl (30% schneller, 50% schneller). Die hier beobachtete Aufwand-Inversion, Faktoren von 0,06-0,21 bei der Coding-Schicht, ist eine andere Größenordnung. Gleichzeitig zeigen die Wandzeit-Daten, dass der Gesamtaufwand nicht im selben Verhältnis sinkt. Die Arbeit verschwindet nicht, sie verschiebt sich.

Methodik und Einschränkungen

Alle Daten stammen aus einem einzelnen Projekt (N=1) mit einem einzelnen Entwickler. Die Übertragbarkeit ist nicht statistisch gesichert, sondern muss über die Kontextbeschreibung eingeschätzt werden: Solo-Entwickler, 27 Jahre Erfahrung, neuer Stack, zwei KI-Werkzeuge (Claude.ai für Konzept, Claude Code für Implementierung), React/TypeScript/Vite, vier Wochen Projektdauer.

Die Aufwand-Faktoren messen nur die Coding-Schicht. Die Schätzungen stammen aus derselben KI-Umgebung, die auch die Umsetzung durchführte. Die Schätzungen wurden zu Projektbeginn erstellt und bewusst nicht angepasst, um historische Vergleichbarkeit zu wahren.

Die Daten sind Bestandteil eines Forschungstagebuchs mit über 5.700 Zeilen, geführt nach dem Schema „Situation, Erwartung vorab, Beobachtung, Überraschung” mit strikter Trennung von Beobachtung und Deutung. Der methodische Rahmen orientiert sich an Design-Based Research (Brown 1992, Collins 1992) und Reflective Practice (Schön 1983).

Dieser Artikel basiert auf Daten aus dem Forschungsprojekt „KI-augmentierte Solo-Entwicklung”, das seit Mai 2026 auf labs.straight8.de dokumentiert wird. Der vollständige Datensatz, einschließlich Forschungstagebuch, Halluzinations-Register und Zyklen-Reviews, wird als Teil des Projekts veröffentlicht.

Erstveröffentlichung: 28. Juni 2026.