Mein Junior-Dev heißt jetzt Claude — 60 Tage Tagebuch aus der Praxis

Die Idee

Mitte Februar war ich in einer typischen Solo-Gründer-Situation: zu viele Projekte, zu wenig Hände, nicht genug Budget für einen Vollzeit-Junior. Klassisches Problem. Ich hab mir gedacht: probieren wir was. Ich behandle Claude Code zwei Monate lang wie einen echten Junior-Entwickler. Kein "KI-Tool als Beigabe" — sondern vollwertiges Teammitglied mit Aufgaben, Deadlines, Reviews.

60 Tage später hab ich klare Antworten. Manche überraschend. Manche ernüchternd.

Das Setup

Ich arbeite aktuell an drei Kundenprojekten parallel: eine Fastapi-Backend-Migration, eine Next.js-Webseite mit CMS-Anbindung, und ein Datenanalyse-Tool für eine Controller-Firma. Normal würde ich zwischen den Projekten wechseln und alles allein machen.

Für den Test hab ich eine klare Regel aufgestellt: Wenn ich eine Aufgabe als "Junior-Level" einschätze, wandert sie zu Claude. Code-Review mach ich selbst. Wenn der Code nicht passt, geht's zurück — genau wie bei einem echten Junior.

Die Aufgaben-Kategorien die an Claude gingen:

• Neue Endpoints basierend auf bestehenden Mustern
• Pydantic-Schemas generieren aus Specs
• Test-Suites für vorhandenen Code
• Refactoring von legacy-Code in saubere Patterns
• Dokumentation (API-Docs, READMEs)
• Bug-Fixing bei nachvollziehbaren Fehlern

Was ich mir selbst behalten hab:

• Architektur-Entscheidungen
• Auth- und Security-kritischer Code
• Client-Kommunikation
• Deploy-Prozesse
• Finale Qualitätssicherung

Die ersten zwei Wochen — Euphorie

Ich muss zugeben, die ersten Tage waren beeindruckend. Aufgabe: "Hier ist unsere FastAPI-Struktur, bau mir die CRUD-Endpoints für eine neue Invoice-Entität nach demselben Muster wie Customer." Fünfzehn Minuten später hatte ich einen PR mit 180 Zeilen Code, allen CRUD-Operationen, Pydantic-Schemas, sauberen Dependency-Injections, und sogar den passenden Tests.

Ich hab den Code durchgelesen. Klein gemeckert an einer Stelle wo die Fehlerbehandlung inkonsistent war, das zurückgegeben, Claude hat's gefixt, ich hab gemergt.

Das war mein Moment wo ich dachte: okay, das kann tatsächlich funktionieren.

In Woche 2 hab ich Claude dann eine komplette Test-Suite für ein bestehendes Service-Modul generieren lassen. 230 Zeilen Code, 30 Tests, coverage ging von 34% auf 87%. Ich hätte dafür selbst zwei Nachmittage gebraucht. Claude war in 45 Minuten fertig, inklusive meiner Review-Zyklen.

Woche 3-4 — Ernüchterung

Dann kamen die Probleme.

Der erste Bug der mich zwei Stunden gekostet hat: Claude hat eine Celery-Task implementiert die auf den ersten Blick korrekt aussah. In der Review hab ich nichts gefunden. Im Test-Environment lief's. In Produktion, nach einem Deploy am Freitagnachmittag, ging's kaputt. Grund: Claude hatte eine Dependency zwischen zwei Tasks eingebaut die auf dem einen Worker-Setup funktionierte, auf dem anderen nicht. Ich hab den Bug erst gefunden als die Kundin Freitagabend schrieb "das System tut nichts mehr".

Das Problem ist nicht der Bug selbst — solche Sachen passieren auch menschlichen Juniors. Das Problem ist mein blinder Fleck: Ich hab nicht mit dem Bug gerechnet weil "Claude macht sowas nicht." Ein menschlicher Junior bekommt von mir automatisch mehr Skepsis.

Das war die erste harte Lektion.

Der zweite Bug — subtiler: Ich hatte Claude gebeten, eine ältere Funktion zu refactorn. Die Funktion hatte einen kommentierten-aus Code-Block am Ende mit dem Hinweis "altes Verhalten, einige Kunden brauchen das noch." Claude hat den Block im Refactoring gelöscht — nachvollziehbar, tot war tot — aber prompt kam eine Beschwerde von einem dieser Kunden.

Der Punkt: Claude liest Context gut, aber es hat keine Geschichte mit dem Code. Ein menschlicher Junior hätte gefragt. Claude hat einfach "sauber aufgeräumt."

Woche 5-6 — ich lerne besser zu delegieren

Nach den Schlägen hab ich meine Prompts umgestellt. Drei Regeln die sich rauskristallisiert haben:

Erste Regel: Context-Dumps funktionieren nicht. "Hier ist unser Repo, mach X" ist schlechter als "Hier ist spezifisch File A, B, C. Lies die. Dann mach X. Dokumentier deine Annahmen bevor du schreibst." Die zweite Version funktioniert viel besser.

Zweite Regel: Claude ist gut in der Breite, schlecht in der Tiefe. Wenn ich eine neue Feature brauche die ein bekanntes Muster folgt — perfekt. Wenn ich einen Bug in einer altem Subsystem debuggen muss — schlecht. Die Stunden die ich mit Claude am Debugging verbracht habe hätte ich besser selbst investiert.

Dritte Regel: Review ist nicht optional, auch wenn's nervt. Bei meinen ersten erfolgreichen Runs hab ich angefangen Claude zu vertrauen. Die Bugs in Woche 3-4 waren direkt die Folge. Ich lese inzwischen jeden Claude-generierten Code gründlich, selbst wenn es lästig ist.

Woche 7-8 — der tatsächliche Produktivitätsgewinn

Zum Ende des Experiments konnte ich Zahlen geben:

Ich hab etwa 30 Prozent meiner Gesamt-Entwicklungszeit an Claude delegiert. Davon waren:

• 80 Prozent beim ersten Wurf verwendbar (mit kleinen Anpassungen)
• 15 Prozent brauchten einen zweiten Round-Trip
• 5 Prozent mussten ich selbst übernehmen

Netto-Zeitgewinn gegenüber "alles allein machen": schätzungsweise 20 Prozent. Klingt wenig, ist aber real. In einer 40-Stunden-Woche sind das acht Stunden.

Dabei bleiben 15 Prozent Kollateral-Zeitverlust durch Bug-Suche und Review-Zyklen die ohne Claude nicht nötig gewesen wären.

Unterm Strich: Etwa 5-10 Prozent echte Produktivität gewonnen, bei deutlich weniger Kognitions-Belastung bei Routine-Aufgaben.

Was Claude nicht kann — und ein echter Junior schon

Das ist der wichtigste Abschnitt. Weil die Twitter-Debatte gern so tut als würden Junior-Entwickler überflüssig.

Claude lernt nichts über Zeit. Nach 60 Tagen weiß Claude immer noch nicht mehr über mein Projekt als am ersten Tag. Jede Session fängt von vorne an (auch mit CLAUDE.md-Files — das hilft aber nur begrenzt). Ein echter Junior baut Wissen auf. Nach sechs Monaten kennt ein echter Junior das Repo besser als ich.

Claude fragt nicht zurück wenn's wichtig wäre. Ein Junior bei Unklarheit fragt nach. Claude macht eine plausible Annahme und implementiert sie. Sie ist oft richtig. Manchmal nicht. Und bei "manchmal nicht" liegt das Geld.

Claude kennt keinen Kunden. Wenn der Kunde Schmidt anruft und sagt "das Ding tut wieder nicht was wir besprochen hatten", weiß der Junior nach sechs Monaten wo er suchen muss. Claude weiß das nie.

Claude hat keine Karriere-Trajectory. Ein Junior wächst zum Senior. Man investiert in ihn. Mit Claude investiert man in Prompts und Tools die morgen vielleicht überholt sind.

Meine ehrliche Bilanz

Claude Code hat meinen Alltag als Solo-Entwickler verbessert. Ich arbeite effizienter, ich delegiere Routine-Arbeit, ich komme schneller zu Fertig-Zuständen.

Was es nicht tut: einen echten Junior ersetzen. Wer glaubt er kann sein Team halbieren und die andere Hälfte durch Claude ersetzen, fliegt auf die Schnauze. Vor allem wenn die verbleibenden Menschen dadurch zu Review-Bottlenecks werden und ihre eigentliche Arbeit nicht mehr schaffen.

Was es schon tut: Einen Solo-Entwickler in die Nähe eines kleinen Zweier-Teams bringen. Für Freelancer, Solo-Gründer, kleine Agenturen ist das ein realer Hebel.

Konkrete Empfehlungen nach 60 Tagen

Wenn du Claude Code in deinen Alltag einbauen willst:

• Fang klein an. Eine Woche lang nur Dokumentation und Tests. Nix Produktions-Relevantes.
• Review-Disziplin einüben. Ob du Lust hast oder nicht — jeden Claude-PR gründlich durchgehen, auch wenn's nach zwei Wochen langweilig wird.
• Halte ein "Claude hat's versaut"-Logbuch. Alle Fälle wo Claude Bugs gebaut hat, mit Muster. Das ist dein persönliches Prompt-Improvement-Backlog.
• Setz klare Grenzen für kritische Aufgaben. Auth-Code, Payment-Code, DSGVO-Code — nicht an Claude delegieren. Punkt. Bei einem echten Junior hättest du ähnliche Vorsicht.

Weiterlesen

Der nächste Artikel in der Coding-Säule wird ein direkter Benchmark: Claude Code vs Cursor vs GPT-5 Codex mit 50 identischen Aufgaben. Wenn du MCP-Server bauen willst um Claude zu erweitern siehe auch MCP-Server-Artikel.

Eigene Erfahrungen, Prompt-Patterns, Review-Workflows? Im Discord Zone "Coding & Projekte" tauschen wir die aus. Keine Marketing-Sprüche, nur echte Learnings.