Wie viel Zeit spart KI in der Software-Entwicklung?

09.01.2026 Bjarne Jansen

Als Entwickler kennen wir das Problem: Wir schätzen Aufgaben, planen Sprints, setzen Deadlines – und am Ende dauert doch alles länger als gedacht. Aber was passiert, wenn wir einen KI-Assistenten wie Claude Code ins Team holen?

Wir haben einen Prototypen für ein medizinisches Web-Projekt entwickelt und vor jeder Aufgabe detaillierte Zeitschätzungen gemacht. Dann wurden die Aufgaben mit der Unterstützung von Claude Code gelöst und die Zeiten verglichen. Das Ergebnis: 44% Zeitersparnis – mit einer höchst unterschiedlichen Verteilung je nach Aufgabentyp.

Die Fakten: Mock-Daten, die wir auf 4 Stunden geschätzt hatten, waren in 30 Minuten fertig. Ein komplexes Dental Chart? Statt 16 Stunden nur 4. Tests und Architektur-Entscheidungen dauerten allerdings exakt so lange wie gedacht. Claude ist kein Allheilmittel – aber in bestimmten Bereichen revolutioniert er die Entwicklung grundlegend.

In diesem Artikel zeigen wir die Zahlen aus diesem Projekt: 17 Aufgaben, von Setup bis Deployment, mit Best-Case-, Normal- und Worst-Case-Schätzungen – und dann die Realität mit Claude.

Das Projekt: 17 Aufgaben, 3 Szenarien

Bei der Entwicklung des Prototypen haben wir vor jeder Aufgabe eine strukturierte Zeitschätzung gemacht. Zum Zeitpunkt der Schätzung hatten wir bereits ein klares Bild von der Aufgabe und den technischen Anforderungen – die Schätzungen basierten also auf solidem Projektwissen, nicht auf anfänglicher Unsicherheit.

Wir haben dabei immer geschätzt, wie lange wir OHNE den Einsatz von KI für diese Aufgabe wahrscheinlich benötigen werden.

Für jede Aufgabe haben wir drei Szenarien geschätzt:

Best Case: Wenn alles glatt läuft
Normal: Unser realistisches Bauchgefühl
Worst Case: Wenn Murphy's Law zuschlägt

Der Durchschnitt wurde als 3-Punkt-Schätzung berechnet: (Best + Normal + Worst) / 3. Das entspricht der Annahme einer Gleichverteilung – jedes der drei Szenarien ist gleich wahrscheinlich.

Das Projekt umfasste typische Web-Entwicklungs-Tasks: Frontend- und Backend-Setup, UI-Komponenten, Datenbank, Deployment, Tests – ein realistischer Mix aus dem Entwickler-Alltag.

Obwohl es sich um einen Prototypen handelte, waren die Qualitätsrichtlinien genauso hoch, wie bei einem regulären Web-Projekt - insbesondere im Hinblick auf Code Qualität.

Die ursprünglichen Schätzungen sah folgendermaßen aus:

Kategorie	Geschätzte Stunden (Normal)
Setup & Infrastruktur	44h
UI & Frontend	68h
Backend & Daten	48h
Tests & Qualität	44h
Integration & Services	20h
Gesamt	248h

Der Gesamtaufwand von 248 Stunden entspricht etwas mehr als 6 Arbeitswochen bei einer 40-Stunden-Woche.

Unsicherheit in Zahlen: Wo wir schwanken

Bevor wir zu den Ergebnissen mit Claude kommen, ist es aufschlussreich zu sehen, wo die größten Unsicherheiten in unseren Schätzungen lagen. Die Spanne zwischen Best-Case und Worst-Case zeigt, wie gut wir eine Aufgabe im Vorfeld einschätzen konnten:

Aufgabe	Best	Normal	Worst	Unsicherheit
Mock Data	4h	4h	4h	0h
Database Setup	3h	4h	5h	2h
Backoffice Setup	2h	4h	8h	6h
Token Management	8h	12h	20h	12h
Schnelleingabe & Parsing	40h	60h	80h	40h

Die Spalte "Unsicherheit" (Worst minus Best) zeigt die Bandbreite unserer Einschätzung. Bei Mock Data waren wir uns absolut sicher: 4 Stunden, fertig. Beim Backoffice Setup? Das konnte 2 Stunden dauern – oder auch 8, je nachdem welche unerwarteten Konfigurationsprobleme auftauchen.

Die drei größten Unsicherheiten:

Aufgabe	Unsicherheit (W-B)	Anteil an Gesamt-Unsicherheit
Schnelleingabe & Parsing	40h	28%
Token Management	12h	8%
Backoffice Setup	6h	4%
Summe Top 3	58h	40%

Drei Aufgaben machten 40% unserer gesamten Unsicherheit aus (58 von 143 Stunden). Bei komplexen oder weniger vertrauten Aufgaben ist die Streuung naturgemäß größer – ein bekanntes Phänomen in der Softwareentwicklung.

Setup-Tasks: Der Klassiker der Pufferung

Interessant war unser "Optimismus-Faktor" – das Verhältnis zwischen Best-Case und Normal-Case:

Aufgabe	Best	Normal	Optimismus-Faktor
Mock Data	4h	4h	1,0 (kein Puffer)
AI-Service Anbindung	8h	8h	1,0 (kein Puffer)
Alle Setup-Tasks	—	—	2,0 (100% Puffer)

Bei Setup-Aufgaben (Frontend, Backend, Tabs, Backoffice) haben wir systematisch das Doppelte der Best-Case-Zeit eingeplant. Warum? Aus Erfahrung. Setup läuft nie komplett glatt. Es gibt immer diese eine Dependency, die nicht installiert werden will, oder diese eine Config, die nicht auf Anhieb passt.

Bei Mock Data und der AI-Service-Anbindung dagegen: Null Puffer. Best-Case = Normal-Case. Eine durchaus optimistische Annahme – wie sich zeigen sollte.

Die Realität: Stark unterschiedliche Zeitersparnis

Dann kam Claude ins Spiel. Hier das Endergebnis:

Kategorie	Geschätzt (Normal)	Real (mit Claude)	Ersparnis
Setup & Infrastruktur	44h	22,5h	49%
UI & Frontend	68h	26h	62%
Backend & Daten	48h	35h	27%
Tests & Qualität	44h	40h	9%
Integration & Services	20h	13h	35%
Gesamt	248h	140h	44%

In Summe haben wir 108 Stunden im Vergleich zu unserer Normal-Schätzung gespart. Das sind über 2,5 Arbeitswochen! Die Zeitersparnis war jedoch extrem ungleich verteilt über die verschiedenen Aufgabentypen.

Wo die größten Zeitgewinne liegen

Die Daten zeigen ein klares Muster bei bestimmten Aufgabentypen:

Aufgabe	Geschätzt (Normal)	Real	Ersparnis
Mock Data	4h	0,5h	87%
Basic Frontend Setup	8h	1h	87%
Dental Chart	16h	4h	75%
Basic Backend Setup	2h	0,5h	75%
Result Tabellen	32h	12h	63%

Diese Tasks hatten eines gemeinsam: Sie waren strukturiert, repetitiv oder folgten bekannten Mustern.

Mock Data? Claude generiert in Sekunden realistische JSON-Strukturen. Frontend-Setup? Boilerplate-Code ist Claudes Spezialität. Das Dental Chart? Eine strukturierte UI-Komponente mit klaren Anforderungen – perfekt für Claude.

Die Erkenntnis: Claude ist gut bei schwierigen Aufgaben aber brillant bei strukturierten, mechanischen Aufgaben, die für Menschen zeitaufwendig sind, aber klaren Mustern folgen.

Das Paradox: Trivial, aber doch überschätzt

Wir hatten Mock Data als "trivial" kategorisiert. Keine Unsicherheit, Best-Case = Normal-Case = Worst-Case = 4 Stunden.

Realität: 30 Minuten.

Wir lagen um Faktor 8 daneben – aber nicht, weil wir die Aufgabe falsch verstanden hätten. Mock Data ist trivial im Sinne von "keine komplexen Entscheidungen". Aber trivial heißt nicht schnell. Als Menschen müssen wir:

Die Datenstruktur durchdenken
Realistische Werte überlegen
JSON schreiben
Validieren
Edge Cases bedenken

Für Claude ist das ein Prompt: "Generiere 50 Mock-Patienten mit Namen, Geburtsdaten, Zahnstatus und Behandlungshistorie."

Neue Perspektive: Eine Aufgabe ist nicht trivial, wenn sie einfach ist. Sie ist trivial, wenn sie strukturiert ist. Und strukturierte Aufgaben sind Claudes Sweet Spot.

Wo menschliches Urteilsvermögen zählt

Nicht alle Aufgaben zeigten dramatische Zeitersparnisse. Interessanterweise lagen wir aber nur bei zwei Tasks schlechter als dem Best-Case – aber auch in diesen beiden Fällen waren wir immer noch im erwarteten Bereich:

Aufgabe	Best	Normal	Real	Ersparnis
Tests	18h	20h	20h	0% (= Normal)
Data Model	8h	12h	12h	0% (= Normal)
Deployment	10h	14h	8h	43% (besser als Best!)
Refactoring	20h	24h	16h	33% (besser als Best!)

Tests: Keine Zeitersparnis gegenüber dem Normal-Case. Warum? Weil Tests strategisches Denken erfordern:

Welche Edge Cases sind wirklich relevant?
Wie testet man diese spezifische Business-Logik sinnvoll?
Was ist ein wertvoller Test vs. ein redundanter Test?

Claude kann Test-Code schreiben. Aber er kann nicht entscheiden, was getestet werden sollte. Das erfordert menschliches Urteilsvermögen und Verständnis für das Gesamtsystem.

Data Model: Ebenfalls beim Normal-Case gelandet. Architektur-Entscheidungen bleiben fundamental menschlich:

Welche Entitäten brauchen wir wirklich?
Wie modellieren wir Beziehungen optimal?
Welche Normalisierung macht in diesem Kontext Sinn?

Claude kann Schemas generieren. Aber die strategischen Entscheidungen, die die langfristige Wartbarkeit und Erweiterbarkeit bestimmen, bleiben beim Entwicklungsteam.

Das Positive: Bei allen 17 Aufgaben haben wir mindestens den Normal-Case erreicht, in den allermeisten Fällen sogar den Best-Case oder besser. Kein einziges Mal sind wir in den Worst-Case gerutscht. Claude hat sämtliche Projekt-Risiken eliminiert.

Die Schnelleingabe: Komplexität in der Praxis

Die komplexeste Aufgabe war die "Schnelleingabe" – ein Parsing-System für medizinische Kurzeingaben:

Geschätzt: 60h (Normal), mit 40h Unsicherheitsspanne
Real: 32h
Ersparnis: 47%

Das ist beeindruckend – fast die Hälfte der Zeit gespart. Gleichzeitig waren es immer noch 32 Stunden absolut. Warum diese Diskrepanz?

Die Aufgabe bestand aus mehreren Schichten:

Parsing-Logik: Strukturiertes Problem → Claude exzellent (70% gespart)
Edge Cases: Weniger strukturiert → Claude hilfreich (40% gespart)
Domain-Wissen: Medizinische Notation → Claude unterstützend (20% gespart)
UX-Entscheidungen: Was soll bei Mehrdeutigkeiten passieren? → Menschliche Entscheidung (kaum Ersparnis)

Claude hat die Arbeit halbiert, aber nicht revolutioniert. Bei wirklich komplexen Tasks mit vielen menschlichen Entscheidungspunkten bleibt substantielle Arbeit übrig – aber wir bleiben deutlich unter dem Normal-Case und sogar unter dem Durchschnitt.

Das Risiko-Paradox: Worst-Cases werden Best-Cases

Erinnerst du dich an unsere Risiko-Einschätzungen? Backoffice Setup: 4x Unsicherheit. Token Management: höchstes Risiko.

Die Realität:

Aufgabe	Best	Normal	Worst	Real mit Claude	Ergebnis
Backoffice Setup	2h	4h	8h	2h	Best-Case erreicht!
Token Management	8h	12h	20h	8h	Best-Case erreicht!
Deployment	10h	14h	18h	8h	Besser als Best-Case!
Tests	18h	20h	26h	20h	Normal-Case
Data Model	8h	12h	16h	12h	Normal-Case

Die entscheidende Erkenntnis: Bei 15 von 17 Aufgaben haben wir den Best-Case erreicht oder geschlagen. Bei den verbleibenden 2 Aufgaben (Tests, Data Model) landeten wir exakt beim Normal-Case – nie schlechter.

Das bedeutet: Claude hat nicht nur Zeit gespart, sondern sämtliche Risiken eliminiert. Worst-Case-Szenarien sind mit Claude faktisch verschwunden. Die Tasks, bei denen wir die größten Unsicherheiten hatten, liefen außergewöhnlich glatt.

Warum? Unsere "unbekannten Risiken" waren gar nicht so unbekannt. Es waren typische Setup-Probleme und klassische Integration-Issues. Probleme, die tausende Entwickler vor uns hatten – und deren Lösungen in Claudes Training-Daten stecken.

Claude hat bekannte Problemmuster zu routinemäßig lösbaren Aufgaben gemacht. Zudem ermöglicht Claude das Ausprobieren verschiedener Lösungswege, da die Ergebnisse schnell generiert sind. Der Entwickler kann dann an konkreten Implementierungen die Vor- und Nachteile analysieren (lassen) und bessere Entscheidungen für die Umsetzung treffen.

Zwei Arten von Unsicherheit

Die Daten zeigen ein klares Muster. Es gibt zwei fundamental verschiedene Arten von Unsicherheit:

Typ A: "Bekannte Komplexität"

Beispiele: UI-Komponenten, Parsing-Logik, Setup-Tasks

Charakteristik:

Komplex, aber strukturiert
Folgt bekannten Patterns
Viele Teilschritte, aber klare Logik
Zeitaufwendig für Menschen

Claude-Effekt: 47-87% Zeitersparnis

Die alte Schätzung: "Das ist unsicher, weil es viel Arbeit ist"
Die neue Realität: Diese "Unsicherheit" war eigentlich nur menschliche Arbeitszeit

Typ B: "Fundamentale Entscheidungskomplexität"

Beispiele: Tests, Data Model, Architektur

Charakteristik:

Erfordert strategisches Denken
Abwägungen ohne klare "richtige" Antwort
Domain-Wissen und Kontext entscheidend
Kreativität und Urteilsvermögen nötig

Claude-Effekt: 0-25% Zeitersparnis

Das Ergebnis: Bei diesen Aufgaben landeten wir exakt beim Normal-Case – keine Zeitersparnis, aber auch keinerlei Risiko. Die Unsicherheit (Worst-Case-Szenarien) wurde vollständig eliminiert, auch wenn die Grundarbeit bestehen blieb.

Die Tatsache, dass die Auwände auch bei komplexen Aufgaben nicht einmal annähernd aus der Schätzung hinauslaufen, ist ein starkes Argument für den Einsatz einer KI/Claude. Gerade diese Themen neigen dazu, die geschätzen Aufwände massiv zu überschreiten, was dann Auswirkungen auf das gesamte Projekt haben kann.

Übersicht: So performed Claude

Basierend auf diesen Daten hier eine Übersicht, wo Claude wie stark beschleunigt:

Task-Typ	Typische Ersparnis	Beispiele aus dem Projekt
Setup & Boilerplate	75-87%	Frontend/Backend Setup, Mock Data
UI-Komponenten (strukturiert)	63-75%	Dental Chart, Result Tabellen
Parsing & Formatierung	~50%	Schnelleingabe
Business-Logik (CRUD)	33-40%	Reparatur Page, Token Management
Integration & APIs	35-43%	AI-Service, Deployment
Tests & QA	0-10%	Tests (Design = menschlich)
Architektur & Design	0%	Data Model

Die Daten zeigen klar: Je strukturierter und mechanischer eine Aufgabe, desto höher die Zeitersparnis mit Claude.

Was bedeutet das für längere Projekte?

Unser Prototyp dauerte 6 Wochen – aber was bedeuten diese Zahlen für ein typisches 12-Monats-Projekt? Die Antwort ist nicht trivial, da sich die Aufgabenverteilung über die Projektlaufzeit je nach Art des Projekts verschiebt.

Die Aufgabenverteilung im Projektverlauf

Wir haben Annahmen zu einer möglichen Verteilung getroffen, um realistische Werte für einen prozentualen Anteil an den Gesamtaufwänden zu bekommen.

Projektphase	Setup/Infra	UI-Komponenten	Business-Logik	Tests	Architektur
Monate 1-2	40%	30%	15%	10%	5%
Monate 3-6	5%	30%	40%	15%	10%
Monate 7-12	2%	20%	45%	20%	13%
Anteil	~10%	25%	~40%	~15%	~10%

Hochrechnung auf 12 Monate

Wir nehmen an, dass wir über 12 Monate einen Umfang von 2.000 Entwicklungsstunden abbilden. Die Anteile haben wir etwas angepasst, um mit runden Stundenwerten rechnen zu können:

Aufgabentyp	Stunden	Anteil	Claude-Ersparnis	Eingesparte Zeit
Setup & Boilerplate	150h	7,5%	80%	120h
UI-Komponenten	500h	25%	65%	325h
Business-Logik	700h	35%	35%	245h
Tests & QA	400h	20%	5%	20h
Architektur	250h	12,5%	0%	0h
Gesamt	2.000h	100%		710h (35%)

Der Ablauf für längerer Projekte:

Frühe Phase (Monate 1-3): Massive Beschleunigung durch Claude
- Setup, UI-Grundgerüst, Boilerplate dominieren
- Zeitersparnis: 50-60%
Mittlere Phase (Monate 4-8): Moderate Beschleunigung
- Mix aus UI, Business-Logik, Tests
- Zeitersparnis: 30-40%
Späte Phase (Monate 9-12): Begrenzte Beschleunigung
- Komplexe Business-Logik, Architektur-Refinements, umfangreiche Tests
- Zeitersparnis: 20-25%

Die strategische Implikation

Bei einem 12-Monats-Projekt mit Claude:

Ohne Claude: 2.000 Stunden = 50 Arbeitswochen = 12,5 Monate
Mit Claude: ~1.300 Stunden = 32,5 Arbeitswochen = 8 Monate

Das sind 4,5 Monate Ersparnis – aber sie sind nicht gleichmäßig verteilt. Die ersten 3 Monate werden zu 1,5 Monaten, während die letzten 3 Monate nur zu 2,5 Monaten werden.

Der Realitäts-Check: Worst-Case-Verzögerungen

Die Extrapolation der Werte aus einem 6 Wochenprojekt in ein 12 Monatsprojekt ist eine interessante Betrachtung, die jedoch auch sehr theoretisch ist. In der Praxis verzögern sich viele Projekte über die ursprünglichen Worst-Case-Schätzungen hinaus.

Beispiel-Szenario ohne Claude:

Geplant: 2.000h (Normal-Case)
Worst-Case-Puffer: +500h
Reale Verzögerungen: weitere +300-500h durch unerwartete Probleme
Tatsächlich: 2.800-3.000h = 15-18 Monate statt 12

Mit Claude:

Geplant: 1.300h
Worst-Case-Risiken: eliminiert (15/17 Tasks unter Best-Case)
Verzögerungen durch unerwartete Probleme: minimal
Tatsächlich: ~1.400-1.500h = 8-9 Monate

Der wahre Vorteil ist also nicht nur die 35% Zeitersparnis, sondern auch die erhöhte Planbarkeit. Es gibt zwar auch mit Claude-Situationen, die länger als erwartet dauern aber insgesamt bewegt man sich dabei in einem kleineren Zeitrahmen und kommt schneller zu Lösungen.

Fazit: Ein neues Arbeitsmodell

Die Zahlen aus diesem Projekt zeigen: Software-Entwicklung mit KI bietet erhebliche Vorteile. Zudem verändert sich die Art und Weise, wie Software entwickelt und designed wird.

Was in den Hintergrund tritt:

Boilerplate-Code schreiben
Setup-Probleme debuggen
Strukturierte UI-Komponenten bauen
Mock-Daten generieren
Standard-CRUD implementieren

Was in den Vordergrund rückt:

Architektur-Entscheidungen treffen
Test-Strategien entwickeln
Business-Logik verstehen und modellieren
Edge Cases durchdenken
Code reviewen und verstehen

Es ist absolut kritisch und unverzichtbar, die Ergebnisse der KI zu verstehen und zu verifizieren. Die KI erzeugt in den wenigsten Fällen im ersten Versuch fehlerfreie Software, die auch noch alle zusätzlichen Anforderungen wie Coding-Conventions erfüllt. Ein reines Vibe-Coding, was ohne weitere Prüfung alle Ergebnisse übernimmt, führt Schritt für Schritt zu einer Erhöhung der technischen Schuld. Der Quellcode wird mit jeder Weiterentwicklung unsauberer und unstrukturierter. Das führt wiederum dazu, dass die KI den Code immer schlechter versteht, sodass auch die KI erzeugten Ergebnisse schlechter werden. Ein Teufelskreis, den man so früh wie möglich unterbrechen muss.

Architektur für die KI-Ära

Es wird zunehmend sinnvoll, Architekturen zu wählen, die von KI gut unterstützt werden. Lose gekoppelte Systeme mit klaren APIs haben dabei einen entscheidenden Vorteil:

Reduzierte Komplexität: Jede Komponente kann isoliert betrachtet werden
Context-Management: Der Context der KI wird nicht mit unnötigen Abhängigkeiten überfrachtet
Klarere Schnittstellen: Gut definierte APIs sind für KI leichter zu verstehen und umzusetzen
Bessere Testbarkeit: Isolierte Komponenten können einzeln getestet werden

Monolithische, stark verkoppelte Systeme werden zum Flaschenhals, weil die KI den gesamten Kontext verstehen muss. Je stärker der KI-Context mit "Rauschen" belastet wird, desto ungenauer werden die Antworten der KI. Modulare Systeme mit klaren Grenzen maximieren den KI-Benefit.

Mehr erfahren

Sie haben Gesprächsbedarf? Jetzt Termin für ein Erstgespräch reservieren.

Dieser Blog-Artikel wurde mit Claude zusammen geschrieben.

Anhang: Vollständige Rohdaten

Alle Aufgaben mit Schätzungen und Realität

Aufgabe	Best	Normal	Worst	Durchschnitt	Claude (Real)	Ersparnis vs Normal
Projekt-Setup	8,00	12,00	16,00	12,00	6,00	50%
Basic Frontend Setup	4,00	8,00	10,00	7,33	1,00	87%
Database Setup	3,00	4,00	5,00	4,00	3,00	25%
Basic Backend Setup	1,00	2,00	2,00	1,67	0,50	75%
Dental Chart	10,00	16,00	18,00	14,67	4,00	75%
Schnelleingabe, parsing, formatting	40,00	60,00	80,00	60,00	32,00	47%
Tabs Setup	2,00	4,00	4,00	3,33	2,00	50%
Mock Data	4,00	4,00	4,00	4,00	0,50	87%
Result Tabellen	24,00	32,00	40,00	32,00	12,00	63%
Backoffice Setup	2,00	4,00	8,00	4,67	2,00	50%
Deployment	10,00	14,00	18,00	14,00	8,00	43%
Tests	18,00	20,00	26,00	21,33	20,00	0%
Reparatur Page	8,00	12,00	14,00	11,33	8,00	33%
Data Model	8,00	12,00	16,00	12,00	12,00	0%
Token Account creation und Management	8,00	12,00	20,00	13,33	8,00	33%
Anbindung AI-Service	8,00	8,00	10,00	8,67	5,00	37%
Refactoring	20,00	24,00	30,00	24,67	16,00	33%
Summe	178,00	248,00	321,00	249,00	140,00	44%

Vergleich: Best-Case vs. Realität

Aufgabe	Best	Claude	Verhältnis	Interpretation
Mock Data	4,00	0,50	0,13	88% unter Best-Case
Basic Frontend Setup	4,00	1,00	0,25	75% unter Best-Case
Dental Chart	10,00	4,00	0,40	60% unter Best-Case
Basic Backend Setup	1,00	0,50	0,50	50% unter Best-Case
Projekt-Setup	8,00	6,00	0,75	25% unter Best-Case
Deployment	10,00	8,00	0,80	20% unter Best-Case
Backoffice Setup	2,00	2,00	1,00	Best-Case erreicht
Tabs Setup	2,00	2,00	1,00	Best-Case erreicht
Token Management	8,00	8,00	1,00	Best-Case erreicht
Database Setup	3,00	3,00	1,00	Best-Case erreicht
Reparatur Page	8,00	8,00	1,00	Best-Case erreicht
Anbindung AI-Service	8,00	5,00	0,63	Best-Case geschlagen
Result Tabellen	24,00	12,00	0,50	Best-Case geschlagen
Schnelleingabe	40,00	32,00	0,80	Best-Case geschlagen
Refactoring	20,00	16,00	0,80	Best-Case geschlagen
Tests	18,00	20,00	1,11	Normal-Case
Data Model	8,00	12,00	1,50	Normal-Case

Ergebnis: 15 von 17 Aufgaben erreichten Best-Case oder besser. Kein einziger Worst-Case trat ein.

Unsicherheits-Analyse

Aufgabe	Unsicherheit (Worst-Best)	Anteil an Gesamt-Unsicherheit
Schnelleingabe, parsing, formatting	40,00	28,0%
Result Tabellen	16,00	11,2%
Token Account creation und Management	12,00	8,4%
Deployment	8,00	5,6%
Tests	8,00	5,6%
Projekt-Setup	8,00	5,6%
Data Model	8,00	5,6%
Dental Chart	8,00	5,6%
Backoffice Setup	6,00	4,2%
Basic Frontend Setup	6,00	4,2%
Reparatur Page	6,00	4,2%
Refactoring	10,00	7,0%
Anbindung AI-Service	2,00	1,4%
Database Setup	2,00	1,4%
Tabs Setup	2,00	1,4%
Basic Backend Setup	1,00	0,7%
Mock Data	0,00	0,0%
Summe	143,00	100,0%

Kategorisierung nach Ersparnis

Kategorie	Ersparnis-Range	Aufgaben	Durchschnittliche Ersparnis
Game-Changer	75-87%	4	81%
High Impact	47-63%	3	53%
Moderate Hilfe	33-50%	8	41%
Limited Impact	0-25%	2	13%

Game-Changer: Mock Data, Basic Frontend Setup, Basic Backend Setup, Dental Chart
High Impact: Result Tabellen, Schnelleingabe, Projekt-Setup
Moderate Hilfe: Tabs Setup, Backoffice, Token Management, Reparatur Page, Refactoring, Anbindung AI-Service, Deployment, Database Setup
Limited Impact: Tests, Data Model

nach oben