Wie man mit Claude Code entwickelt wie ein Fünferteam

• Das AI-Tool Claude Code ist nicht nur ein einfacher Code-Generator, sondern ein Produktivitätswerkzeug, das das Gefühl vermittelt, Aufgaben an einen Kollegen zu delegieren
• Es schafft ein Umfeld, in dem man sich statt auf repetitive Implementierung auf genuin menschliche Fähigkeiten wie Systemdesign, Produktdenken und Kommunikation konzentrieren kann
• Durch parallele Arbeit, mehrstufiges Debugging und GitHub-Integration entsteht der Effekt, dass selbst kleine Teams Ergebnisse auf dem Niveau großer Entwicklungsteams liefern können
• Allerdings gibt es auch Einschränkungen und eigentümliche Verhaltensweisen, etwa das Schreiben übermäßig vieler Tests oder das Überbearbeiten einfacher Aufgaben, die vom Nutzer gesteuert werden müssen
• Letztlich verschiebt sich dadurch die Rolle des Entwicklers vom Implementierer zum Dirigenten und eröffnet breite Möglichkeiten – von der Ausbildung von Junior-Entwicklern über Produktivitätssteigerungen für Seniors bis hin zur Umsetzung von Projekten durch Nicht-Entwickler

---

Von AI geschriebener Code und der Wandel der Entwicklerrolle

• Der gesamte Code, der in den letzten zwei Monaten geschrieben wurde, wurde nicht von Menschen, sondern direkt von Claude Code verfasst
  • Der Nutzer konzentriert sich statt auf die Implementierung auf Architekturdesign und Ergebnisdefinition
  • Der Trend geht dahin, dass repetitives und kleinteiliges Tippen zunehmend überflüssig wird
• Dabei verschiebt sich der Wert des Entwicklers hin zu Produktplanung, systemischem Denken und ästhetischem Urteilsvermögen

Mehrstufige Debugging-Fähigkeiten

• Bei einem Fehler in einer Queue-Task analysierte Claude Code Tausende Zeilen externen Bibliothekscodes und fand die Ursache
  • Es löste ein Problem durch nicht übereinstimmende Queue-Namen zwischen Entwicklungs- und Produktionsumgebung
• Das ist ein Beispiel dafür, wie sich Probleme, für die Entwickler normalerweise Stunden oder Tage brauchen würden, in kurzer Zeit lösen lassen

Arbeiten wie ein Orchesterdirigent

• Durch das parallele Ausführen mehrerer Claude-Code-Instanzen lassen sich mehrere Funktionen gleichzeitig entwickeln
  • Jede Aufgabe läuft in einer separaten git worktree, um Konflikte zu vermeiden
• Entwickler übernehmen statt des direkten Codens die Rolle eines Managers, der Aufgaben dirigiert und Reviews durchführt
• So kann auch bei nachlassender Energie oder Konzentration effektiv weitergearbeitet werden

Alltägliche Nutzung und minimale Reibung

• Im Gegensatz zu IDE-basierten Tools wie Cursor, Copilot ist Claude Code nicht an eine bestimmte Umgebung gebunden
• Es integriert sich nahtlos in bestehende Entwickler-Workflows mit CLI, git, tmux usw.
• Wichtige Befehle:
  • /issues → GitHub-Issue erstellen
  • /work → issuebasierte Entwicklung und PR-Erstellung
  • /review → PR-Review und Verbesserung
• Dadurch wird die Reibung in Forschung, Implementierung und Review-Prozess minimiert

Grenzen und Eigenheiten

• Manchmal zeigt es übertriebenes Verhalten, indem es zu viele Tests schreibt oder einfache Aufgaben unnötig kompliziert behandelt
• Wenn es in die falsche Richtung läuft, kann es sofort gestoppt werden
• Ein Vorteil ist, dass es auch Dinge bereitwillig erledigt, die Entwickler lästig finden, etwa wiederholte Stilkorrekturen

Junior-Entwickler und Lernen

• Junior-Entwickler können Claude Code als einen Mentor, dem man unablässig Fragen stellen kann, nutzen
  • "Was ist das Problem mit meinem PR?"
  • "Worin unterscheiden sich die Ansätze von Python und Ruby?"
  • "Welche Fallstricke und Vorsichtspunkte gibt es je nach Sprache?"
• Dadurch steigen Lerngeschwindigkeit und praktischer Beitrag erheblich

Beispiel für einen realen Workflow

• 9:00 Uhr: Fehlerbericht an Claude Code übergeben → Reproduktion und automatische Erstellung eines GitHub-Issues
• 9:20 Uhr: In 4 Tabs parallel unterschiedliche Aufgaben ausführen (Bugfix, PR-Review, Changelog schreiben, Hintergrundrecherche)
• 10:00–11:00 Uhr: Automatische Erstellung der einzelnen PRs, inklusive Dokumentation und Fehlerbehandlung
• 11:30 Uhr: Mensch prüft final und korrigiert UX und Code-Stil
• 11:45 Uhr: Kundenfeedback analysieren und automatisch in Issues umwandeln

Fazit und empfohlene Zielgruppen

• Ein Zweierteam investiert monatlich 400 US-Dollar und erreicht damit Ergebnisse auf dem Niveau großer Teams
• Empfohlene Zielgruppen:
  • Senior-Entwickler, die sich statt auf Implementierung auf Strategie und Qualität konzentrieren möchten
  • Team-Leads, die mehr erreichen wollen
  • Gründer ohne Entwicklerhintergrund und Einsteiger in die Entwicklung
• Der Einstieg ist mit einem Abo für 20 US-Dollar pro Monat möglich; entscheidend für eine kürzere Lernkurve ist es, Claude Code direkt an realen Projekten arbeiten zu lassen
• Die Zukunft des Codens verschiebt sich weg von direkter Implementierung hin zu Ergebnissteuerung und Delegation

[kaydash]

Menschen streiten, aber Programme streiten nicht und sind rational ..

[bluekai17]

Ich finde, schon die sinnvolle Nutzung von Worktrees ist ziemlich gut.

[bhjun]

So etwas umzusetzen, dürfte mit Pro auf keinen Fall möglich sein.
Ich erstelle als Nicht-Entwickler gerade eine iOS-App, aber bei Pro ist das Limit viel zu schnell erreicht.
Jedes Mal ist nach nicht einmal zwei Stunden Schluss.

Andererseits ist es vielleicht auch ganz gut, dass das Erreichen des Limits zugleich das Ende der Arbeit bedeutet ...
(so nach dem Motto: Für heute reicht’s,,, haha)

[bluekai17]

Wenn man das Max-$100-Paket nutzt, ist es trotzdem ziemlich entspannt. Ich bin zwar kein Nicht-Entwickler, aber App-Entwicklung war Neuland für mich, deshalb habe ich es einen Monat lang ausprobiert. Bisher habe ich insgesamt etwa $566.93 ausgegeben.

[fanotify]

Wenn man morgens 2–3 Stunden damit arbeitet, erreicht man noch vor dem Mittag das Limit (Pro-Nutzer).
Es steht da, dass es ab 15 Uhr zurückgesetzt wird, aber wenn man nicht Max hat, kann man es wohl kaum den ganzen Tag nutzen (wobei es bei Max vermutlich auch nicht allzu schwer ist, ans Limit zu kommen).

[neodasida]

Fühlt sich wie ein automatisches 2-Stunden-Pomodoro an, haha

[click]

Selbst wenn man im 20-Dollar-Pro-Plan nur die von allen empfohlene Vorgehensweise nutzt – also erst im Plan-Modus eine detaillierte Planung analysieren und erstellen lassen und dann in den Edit-Modus wechseln –, erreicht man ziemlich schnell das Limit.
Die Codequalität wird dadurch zwar definitiv besser, aber gefühlt ist der Token-Verbrauch mindestens dreimal so hoch wie wenn man dumm einfach von Anfang an im Edit-Modus startet.

[hanay]

Im kostenlosen Tarif ist das nicht möglich, oder?

[bluekai17]

Wenn man das 100-Dollar-Paket nutzt, könnte es das immerhin einigermaßen abdecken.

[helio]

Selbst mit 20 Dollar ist das schwer. Um so etwas zu schreiben wie „Der gesamte in den letzten zwei Monaten geschriebene Code wurde nicht von Menschen, sondern direkt von Claude Code verfasst“,

müsste man doch erst mal 200 Dollar verbrennen und wenn dann das Limit greift, noch mal 200 Dollar ausgeben, oder?

[muroa96]

Ich nutze ebenfalls das 100-Dollar-Abo. Bevor ich Code schreibe, erstelle ich den Plan mit dem Opus-Modell, und für das eigentliche Coding nutze ich Sonnet. In den letzten etwa zwei Monaten hat Claude Code fast meinen gesamten Code (mindestens mehrere tausend Zeilen) direkt geschrieben, und ich bin dabei fast nie an ein Limit gestoßen. Außer wenn ich versehentlich Code mit Opus geschrieben habe, ist das praktisch gar nicht passiert.
Aktuell nutze ich den kürzlich erschienenen Opus Plan Mode, und seit ich ihn verwende, erscheint auch die Warnmeldung "Approaching limit" kaum noch.

[progdesigner]

Ich arbeite bereits genauso~
Wenn man in der Community abstimmt,
sieht es so aus, als würden sich 80–90 % gerade in diese Richtung verändern.