45.000 Zeilen Code. Null davon selbst geschrieben. Ein Erfahrungsbericht.

Darf ich vorstellen: Mein Coding Team Claude (Quelle: ChatGPT).

Wie ich in 17 Abenden und Wochenenden eine vollständige Anwendung gebaut habe – nur durch Prompting mit Claude Code. Und warum mich das Ergebnis mindestens ebensosehr beunruhigt wie begeistert.

Wie alles begann

KI finde ich spannend. Im Job entwickeln wir Software. Was liegt also näher, als KI-gestützte Softwareentwicklung selbst auszuprobieren? Nicht theoretisch, nicht als Konferenz-Talk, sondern hands-on: ein echtes Projekt, echte Komplexität, echte Ergebnisse.

Am 9. Februar 2026 – einem Montagabend – habe ich Claude Code gestartet und meine Idee für eine datengetriebene Analyse-Anwendung beschrieben. Claude stellte ein paar Rückfragen zur Architektur und den gewünschten Features. Eine Stunde später lief die erste Version: eine Streamlit-Oberfläche, eine SQLite-Datenbank, die Anbindung externer Datenquellen über APIs und erste Analyse-Seiten. Funktionsfähig. Deploybar. An einem Abend.

Ich hatte keine einzige Zeile Code geschrieben. Nur Anforderungen formuliert – in natürlicher Sprache.

Was dann passierte

Was als Experiment begann, entwickelte eine bemerkenswerte Eigendynamik. Die Anwendung wuchs – Abend für Abend, Wochenende für Wochenende:

Woche 1 (9.–11. Feb): Grundgerüst. Die App bekam ein Dashboard, eine News-Anbindung mit Sentiment-Analyse, persistierte Einstellungen, eine wachsende Testabdeckung. Von 6.800 auf knapp 10.000 Zeilen Code in drei Tagen.

Woche 2 (13.–19. Feb): Feature-Aufbau. Detail-Seiten mit Deep-Linking, Performance-Optimierung durch paralleles Prefetching. Am 18. Februar: die erste Engine – mit Logging, CSV-Export und KI-gestützter Vorschau. Am Ende der Woche: 17.400 Zeilen, über 600 Tests.

Woche 3 (21.–23. Feb): Infrastruktur-Upgrade. Hier wurde es spannend. Die ursprüngliche Architektur stieß an ihre Grenzen. SQLite skalierte nicht mehr, Streamlit war für Multi-User-Betrieb nicht gebaut. Die Entscheidung: kompletter Umbau. Migration auf PostgreSQL, Wechsel des gesamten UI-Stacks auf FastAPI mit HTMX und Alpine.js, Einführung einer Worker-Thread-Architektur. Ein massiver Eingriff, den ich Claude in mehreren Iterationen erklärt habe. Nach zwei Abenden lief alles wieder – auf einem komplett neuen Fundament.

Woche 4 (24. Feb – 4. Mär): Funktionale Erweiterung. Erweiterte Engine-Funktionalität, Zwei-Schichten-Architektur mit Fast Lane und Slow AI Lane, Anbindungen mehrerer externer APIs, Ablöse Claude API durch lokale KI-Algorithmen (es wurde mir dann doch etwas zu teuer ;)). Und nach einer Diskussion mit Claude über IT-Security: Multi-User mit JWT-Authentication, argon2id-Passwort-Hashing, verschlüsselte Credentials, ein Durchgang durch die OWASP Top 10 mit anschließender Härtung. MFA eingebaut, in ~30 Minuten. Zwei Abende für ein Sicherheitsniveau, das viele produktive Systeme nicht erreichen.

Das Ergebnis in Zahlen

Nach 17 aktiven Entwicklungstagen, 98 Commits und im Durchschnitt 2.650 neuen Zeilen Code pro Tag steht eine Anwendung mit:

45.100 Zeilen Code (Python, HTML, JavaScript)
914 automatisierte Tests
PostgreSQL-Datenbank, FastAPI-Backend, modernes Frontend
KI-Integration (Claude API), mehrere externe Datenquellen
Broker-Anbindungen mit OAuth2 und MFA
Verschlüsselung, Authentifizierung, Audit Trail

Wachstum der App

Wachstum der App

Das Ergebnis ist deutlich mehr als ein Prototyp. Das ist eine funktionale, getestete, architektonisch durchdachte Anwendung. Gebaut von jemandem, der seit Jahren keinen produktiven Code mehr geschrieben hat. An Feierabenden und Wochenenden.

Das Suchtpotenzial

Was ich nicht erwartet hatte: der Sog. „Nur noch dieses eine Feature …” – und schon sind die Tokens erschöpft. Man denkt in Möglichkeiten, nicht in Aufwänden. Das System wächst Funktion um Funktion, und jede neue Fähigkeit inspiriert die nächste.

Auch die Sackgassen gehören dazu. Der Moment, als die Architektur an ihre Grenzen kam, war frustrierend – aber auch lehrreich. Claude Code konnte den Umbau nicht in einem Rutsch erledigen. Es brauchte mehrere, durchdachte Prompts, klare Vorgaben zur Zielarchitektur und iteratives Vorgehen. Aber nach zwei intensiven Abenden stand die neue Architektur. Ein Umbau, für den ein kleines Team normalerweise Wochen gebraucht hätte.

Was ich gelernt habe

Claude Code funktioniert. Erschreckend gut. Nicht perfekt – es braucht Führung, architektonisches Verständnis und die Fähigkeit, Anforderungen klar zu formulieren. Aber die Produktivität ist atemberaubend.

Die Rolle des Entwicklers verändert sich fundamental. Ich habe in diesem Projekt nicht programmiert. Ich habe Architektur entworfen, Anforderungen spezifiziert, Ergebnisse geprüft und Richtungsentscheidungen getroffen. Genau die Skills, die in meinem ersten Artikel als Zukunft der Softwareentwicklung beschrieben sind – ich habe sie erlebt.

KI unterstützt auch bei der Fachlichkeit. Ich würde gerne behaupten, dass die Fachlichkeit der Applikation mir komplett bekannt ist. Ich würde lügen. Also was macht man in diesem Fall? Richtig - wenn es um Ideen geht, wie man ein Problem angehen kann, fragt man Claude. Und aus dem Feedback habe ich den Weg nach vorne definiert. Und wenn es eine Sackgasse war (was sehr selten vorkam)? Rinse & Repeat. Problem gelöst.

Und dann kamen die Gedanken, die nicht mehr aufhörten. Wenn ich das kann – an Feierabenden, ohne aktive Coding-Praxis – was bedeutet das für mein Team? Für unseren Job? Für die Firma? Für die IT-Branche? Für Europa?

Ich habe mein Diplom in Informatik 2001 gemacht. Im Studium habe ich noch gelernt, dass ein guter Entwickler pro Tag ca. 23 Zeilen produktiven Code erzeugt. Ein Blick in die Literatur:

Die bekannteste Referenz ist Fred Brooks’ The Mythical Man-Month (1975), der für das OS/360-Projekt rund 10 LOC/Tag ermittelte – allerdings für ein hochkomplexes Betriebssystem mit sehr hohen Qualitätsanforderungen.
Capers Jones hat über Jahrzehnte Projekte vermessen und kam je nach Projekttyp auf 16–38 LOC/Tag. Steve McConnell (Code Complete) differenziert stärker nach Projektgröße: bei kleinen Projekten (~10.000 LOC) sind 20–125 LOC/Tag realistisch, bei großen Systemen (10 Mio. LOC) sinkt das auf 1,5–25 LOC/Tag, weil Koordination, Integration und Testing überproportional wachsen.
Wichtig dabei: Diese Zahlen meinen netto – also getesteten, funktionierenden, in Produktion überführbaren Code, gemittelt über die gesamte Projektlaufzeit inklusive Design, Meetings, Debugging, Reviews und Testing. An einzelnen Tagen schreibt jeder Entwickler natürlich deutlich mehr.

Als praxistaugliche Faustregel für 2025/2026 gilt für einen professionellen Entwickler in einer Hochsprache: 10–50 LOC/Tag netto je nach Projektgröße und Komplexität, mit einem häufig zitierten Mittelwert um 20–30 LOC/Tag. Harness/SEI nennt als Industriestandard 125–185 LOC/Monat, was bei ~22 Arbeitstagen auf 6–8 LOC/Tag hinausläuft – das ist allerdings eher konservativ und bezieht sich auf große Enterprise-Projekte.

Der Vergleich ist brutal: Mein Projekt kam auf ~2.650 LOC/Tag netto. Selbst wenn man großzügig 50 LOC/Tag als oberes Ende für einen guten Entwickler ansetzt, ist das ein Faktor 50–100. Und das von jemandem, der keine Zeile selbst geschrieben hat.

Das verändert alles.

Und so entstand der Artikel, den viele von euch bereits gelesen haben: KI schreibt jetzt Code. Was bedeutet das – für Unternehmen, für Europa, für uns alle?

Dieser Erfahrungsbericht ist die Geschichte dahinter. Nicht Theorie, sondern Praxis. Nicht Marktanalyse, sondern persönliches Erleben.

Was ich mitnehme

An alle, die noch zögern: Probiert es aus. Nicht morgen, nicht nächstes Quartal. Jetzt. Ihr braucht kein Entwicklerteam, um zu digitalisieren und Ideen umzusetzen. Ihr braucht eine Idee, die Fähigkeit sie zu erklären – und den Willen, euch auf etwas einzulassen, das die eigene Vorstellung davon, was möglich ist, grundlegend verschiebt.

Und an alle Entwickler da draußen - bei reinem Coding gibt es nun sehr sehr harte Konkurrenz. Aber: Entwickler zu sein bedeutet nicht (nur) Coden, es bedeutet ein Problem in seine Teile zu zerlegen, und gute und effiziente Lösungen dafür zu finden. Einen Plan zu haben, und diesen zum Ende zu verfolgen. Und die Implementierung der Einzelschritte? Da gibt es jetzt Hilfe. Tools wie Claude Code zu ignorieren wäre gleichzeitig fatal.

Und an alle, die es schon nutzen: Lasst uns darüber reden. Offen, ehrlich, mit allen Chancen und Risiken.