florian.wilde
1096993120
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.
55 lines
4.0 KiB
Markdown
55 lines
4.0 KiB
Markdown
# 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.
|