Vergleich der Umsetzungszeit mit Claude gegen eine grobe Schätzung für einen erfahrenen Entwickler ohne KI-Unterstützung, je Version seit v1.0.0. Wird bei jeder neuen Version ergänzt.
4.0 KiB
4.0 KiB
Zeitaufwand
Übersicht, wie lange die Umsetzung der einzelnen Versionen mit Claude gedauert hat, zum Vergleich mit der Schätzung für einen erfahrenen Entwickler ohne KI-Unterstützung. Wird bei jeder neuen Version ergänzt.
Methodik
- „Zeit bei Claude" basiert auf den Git-Commit-Zeitstempeln zwischen zwei Versions-Tags. Das ist kein reiner Rechenzeit-Wert, sondern enthält auch die Zeit, die der Nutzer zum Lesen/Antworten gebraucht hat – aber es ist der einzige objektiv messbare Anhaltspunkt.
- Große Lücken zwischen zwei Tags (mehrere Stunden bis über einen Tag) markieren eindeutig eine neue Sitzung, kein durchgehendes Arbeiten – diese sind als „neue Sitzung" markiert statt als Zeitangabe.
- „Erfahrener Entwickler" ist eine grobe Schätzung für jemanden, der mit dem Stack (Next.js, PostgreSQL, TypeScript) vertraut, aber neu in diesem Projekt ist, inkl. Testen/Verifikation, exkl. Code-Review durch Dritte.
Übersicht
| Version | Datum | Kern der Version | Zeit bei Claude | Erfahrener Entwickler |
|---|---|---|---|---|
| v1.0.0/v1.1.0 | 17.07. | Grundgerüst: öffentliche Speisekarte, Login (Passwort+Passkey), Kantinen-/Admin-Bereich, Supabase-Schema+RLS, Docker-Setup, lokale PG-Kopie | nicht messbar (erster Commit) | 3–5 Tage (24–40 h) |
| v1.2.0 | 18.07. | Heute-Button, mobile Tages-/Wochenansicht, Allergen-Chips, Passwort-Wiederholung, Passkey-Pflicht, SITE_TITLE/Favicon, UX-Politur | 56 min | 1–1,5 Tage (8–12 h) |
| v1.3.0 | 18.07. | Volle Mehrsprachigkeit DE/EN/PL, DeepL-Anbindung, Rezeptvorschläge (öffentlich + Sichtung), 2 Bugfixes | 1 h 23 min | 1,5–2 Tage (12–16 h) |
| v1.4.0 | 18.07. | Essenszeiten variabel (CRUD + Sortierung), 2 Bugfixes | (neue Sitzung) | 0,5–1 Tag (4–8 h) |
| v1.5.0 | 18.07. | Supabase komplett entfernt: eigene DB/Auth/Passkeys/Storage, 2 Sicherheitsfixes (Passkey-Pflicht serverseitig, SVG-XSS) | 3 h 26 min | 2–3 Tage (16–24 h) |
| v1.6.0 | 18.07. | RSS-Feed, Vorschläge-Badge, DEPLOYMENT.md, Supabase-Doku-Reste entfernt | 33 min | 0,5–1 Tag (4–8 h) |
| v1.6.1 | 18.07. | DB-Port abgesichert, Troubleshooting-Doku | 1 h 58 min | 1–2 h |
| v1.6.2 | 18.07. | Bootstrap-Admin-Fehlerbehandlung + Doku-Fix | 22 min | 1–2 h |
| v1.6.3 | 18.07. | Docker BRANDING_DIR-Bugfix |
20 min | 0,5–1 h |
| v1.7.0 | 19.07. | CSV-Import/-Export (3 Ressourcen), RSS-Fix | (neue Sitzung) | 0,5–1 Tag (4–8 h) |
| v1.8.0 | 19.07. | Umschaltbarer Hinweismodus für Allergene/Zusatzstoffe | 45 min | 0,5–1 Tag (4–6 h) |
| v1.8.1 | 20.07. | update.sh Deployment-Skript |
10 min | 1–2 h |
| v1.9.0 | 20.07. | SSO-Login per OpenID Connect (PKCE, JWKS-Prüfung) | 26 min | 1–1,5 Tage (8–12 h) |
| v1.9.5 | 20.07. | Interner Bereich mobil nutzbar (Hamburger-Nav, Tab-Wochenansicht, 5 Komponenten) | 21 min | 1 Tag (6–10 h) |
| v1.10.0 | 20.07. | Dynamisches Sprachpaket-System (Teil 1 Mehrsprachig-Umbau) | (neue Sitzung) | 1–1,5 Tage (8–12 h) |
| v1.11.0 | 20.07. | Speiseplan-Inhalte variabel (Teil 2, inkl. Produktionsdaten-Migration) | 35 min | 1–1,5 Tage (8–12 h) |
| v1.11.1 | 20.07. | Sprach-Fallback-Bugfix (deaktiviertes Deutsch) | 12 min | 0,5–1,5 h |
| v1.12.0 | 20.07. | Tage als geschlossen markierbar (Feiertage o. Ä.), mehrsprachiger Grund, RSS-Integration | 1 h 12 min | 0,5–1 Tag (4–8 h) |
| v1.12.1 | 20.07. | Schloss-Symbol statt Textlink, durchgehendes Geschlossen-Banner über alle Essenszeiten | 14 min | 2–4 h |
| Gesamt | ~12,3 h messbare aktive Zeit (+ 1 nicht messbarer Grundgerüst-Block) | ~114–187 h ≈ 15–24 Arbeitstage (real eher 1–2 Monate Kalenderzeit) |
Warum der Unterschied?
Der Zeitvorteil kommt vor allem daher, dass zwischen Planung, Umsetzung und Test keine Wartezeit liegt (Code-Review, Freigaben, andere Aufgaben dazwischen) – nicht daher, dass grundsätzlich "schneller gedacht" wird. Ein Mensch bräuchte für dieselbe Sorgfalt vermutlich nicht weniger Zeit pro Aufgabe, aber deutlich mehr Kalenderzeit durch Kontextwechsel.