Ein Berliner Startup migriert seine Django-API auf FastAPI. Drei Entwickler, 40 Endpunkte, 180 Tests. Der Teamlead setzt Claude Code ein und erwartet, die Migration in zwei Tagen abzuschließen statt in einer Woche. Nach vier Tagen ist das Team noch nicht fertig. Claude Code hat jede einzelne Route korrekt übersetzt, aber die Architektur der neuen API sieht aus wie ein eins-zu-eins-Abzug der alten, weil keine der FastAPI-spezifischen Möglichkeiten genutzt wurde. Die Middleware-Schicht ist identisch, nur mit anderer Syntax. Dafür hat das Team vier Tage mit dem Prüfen und Nachbessern von generiertem Code verbracht.
Das ist kein Einzelfall, sondern das häufigste Muster, das beim Einsatz von AI-Coding-Tools schief läuft.
Zur Einordnung: Claude Code ist Anthropics Terminal-basierter AI-Coding-Agent, der eigenständig Dateien lesen, bearbeiten und Shell-Befehle ausführen kann. In Teil 1 dieser Serie ging es um die technischen Grundlagen. Dieser Teil behandelt die Frage, wie man das Tool produktiv einsetzt, welche Workflows funktionieren und welche Fehler am meisten Zeit kosten.
METR, eine Organisation für AI-Sicherheitsforschung, veröffentlichte im Juli 2025 eine Studie mit einem Ergebnis, das die Branche aufschreckte: Erfahrene Open-Source-Entwickler arbeiteten mit AI-Coding-Tools 19 Prozent langsamer als ohne. Nicht schneller. Langsamer. Die 16 teilnehmenden Entwickler hatten im Schnitt jahrelange Erfahrung mit Repositories von über 22.000 Stars und mehr als einer Million Codezeilen. Sie durften jedes beliebige AI-Tool verwenden, die meisten wählten Cursor mit Claude Sonnet. Und trotzdem: 19 Prozent mehr Zeit pro Aufgabe.
Die spannendste Erkenntnis betrifft die Wahrnehmung. Die Entwickler schätzten, dass sie mit AI 20 Prozent schneller seien. Die gemessene Realität war das Gegenteil. Diese Diskrepanz zwischen Gefühl und Messung ist der Schlüssel zum Verständnis produktiver AI-Nutzung. Denn die Studie zeigt nicht, dass AI-Tools nutzlos sind, sondern dass die Art der Nutzung über Gewinn oder Verlust entscheidet.
Das Produktivitätsparadox der AI-Codegenerierung
Anthropic selbst liefert Zahlen, die das Paradox verdeutlichen. Eine interne Befragung von 132 eigenen Entwicklern ergab: 67 Prozent mehr gemergte Pull Requests pro Tag, der Anteil von Claude Code an der täglichen Arbeit stieg von 28 auf 59 Prozent, und die selbst eingeschätzte Produktivitätssteigerung lag zwischen 20 und 50 Prozent. Gleichzeitig bewegten sich die Delivery-Metriken auf Teamebene kaum.
Faros AI bestätigt dieses Muster mit Daten von über 10.000 Entwicklern auf 1.255 Teams. Ergebnis: Teams mit hoher AI-Adoption mergten 98 Prozent mehr Pull Requests und schlossen 21 Prozent mehr Tasks ab. Das klingt beeindruckend. Der Haken: Die Review-Zeiten stiegen um 91 Prozent, die Bugrate erhöhte sich um 9 Prozent, und die DORA-Metriken auf Organisationsebene blieben flach. Mehr Output, aber nicht mehr Ergebnis.
Der Flaschenhals verschiebt sich: Code schreiben wird billiger, während Code verstehen, prüfen und warten teurer wird. Teams, die diesen Effekt ignorieren, produzieren schneller mehr technische Schulden.
Warum werden erfahrene Entwickler langsamer?
Die METR-Studie identifiziert mehrere Ursachen. Die Akzeptanzrate lag unter 44 Prozent, was bedeutet, dass mehr als die Hälfte des generierten Codes verworfen wurde, nachdem die Entwickler ihn gelesen, getestet und angepasst hatten. Die Zeit fürs Prüfen überstieg die Ersparnis beim Schreiben.
Ein zweiter Faktor: Kontextwechsel. Die Entwickler kannten ihre Codebases seit Jahren. Sie wussten, wo welche Funktion liegt, warum ein bestimmter Workaround existiert, welche Abhängigkeiten kritisch sind. Das AI-Tool ignorierte dieses implizite Wissen regelmäßig und schlug Lösungen vor, die technisch korrekt, aber kontextuell falsch waren. Die Entwickler mussten dann erklären, korrigieren, erneut prüfen. Das ist das „generate-then-fix“-Antipattern: Code generieren, Probleme finden, reparieren, erneut generieren. Eine Schleife, die mehr Zeit kostet als manuelles Arbeiten.
Meine Einschätzung: Das Problem liegt nicht bei den Tools, sondern an einem fundamentalen Missverständnis darüber, was AI-Codegenerierung ist. Sie ist kein schnellerer Texteditor, sondern ein Werkzeug, das einen grundlegend anderen Arbeitsstil erfordert.
Plan-then-Execute: Exploration und Implementierung trennen
Der wirksamste Ansatz gegen das generate-then-fix-Problem ist simpel: Erst denken, dann ausführen. In der Praxis bedeutet das, zwei klar getrennte Phasen einzuhalten.
Phase eins ist Exploration. Hier geht es darum, das Problem zu verstehen, nicht es zu lösen. Ein konkretes Beispiel: Eine Django-Anwendung soll Caching für die meistgenutzten API-Endpunkte bekommen. Statt sofort „Implementiere Redis-Caching für alle GET-Routen“ zu schreiben, beginnt die Exploration anders.
Schritt eins: Bestandsaufnahme. Der Entwickler bittet Claude Code, die bestehende Architektur zu analysieren. Welche Endpunkte existieren? Welche haben die höchste Last? Gibt es bereits Caching-Mechanismen, etwa Django-eigene Dekoratoren oder Query-Caches auf Datenbankebene? Claude Code liest die relevanten Dateien und erstellt eine Übersicht.
Schritt zwei: Optionenbewertung. Der Entwickler diskutiert mit Claude Code verschiedene Caching-Strategien. Redis vs. Memcached vs. Django-internes Caching. Invalidierungsstrategien. TTL-Werte für verschiedene Endpunkttypen. Das ist ein Gespräch, keine Codegenerierung, und am Ende steht ein Plan, kein Code.
Schritt drei: Umsetzungsanweisung. Erst jetzt formuliert der Entwickler einen präzisen Auftrag, der auf dem Plan basiert. „Implementiere Redis-Caching für die Endpunkte /api/products/ und /api/categories/ mit einem TTL von 300 Sekunden. Verwende django-redis. Invalidiere den Cache bei POST/PUT/DELETE auf die gleichen Ressourcen. Schreibe Tests für Cache-Hit und Cache-Miss.“
Der Unterschied zum generate-then-fix-Ansatz: Die Richtung stimmt von Anfang an. Claude Code implementiert nicht blind, sondern auf Basis eines durchdachten Plans, wodurch sich die Korrekturschleifen drastisch reduzieren.
Wie hilft der Plan Mode dabei?
Claude Code bietet seit 2025 einen Plan Mode, der genau dieses Vorgehen unterstützt. Im Plan Mode analysiert das Tool die Aufgabe und erstellt einen strukturierten Umsetzungsplan, bevor es eine einzige Zeile Code schreibt. Der Entwickler kann den Plan prüfen, Schritte ändern, Prioritäten verschieben. Erst nach Freigabe beginnt die Implementierung.
Der Plan Mode ist kein Allheilmittel. Bei kleinen Änderungen wie Bugfixes, Typos oder einfachem Refactoring verzögert er unnötig, während er bei Aufgaben, die manuell mehr als zehn Minuten dauern würden, fast immer Zeit spart. Die Faustregel: Wenn die Aufgabe komplex genug ist, dass ein menschlicher Entwickler erst nachdenken würde, bevor er tippt, sollte auch Claude Code erst planen.
Test-Driven Development als stärkster Beschleuniger
Wenn es ein einzelnes Pattern gibt, das den Produktivitätsunterschied bei Claude Code am stärksten beeinflusst, dann ist es TDD. Das überrascht selbst erfahrene Entwickler, die TDD als akademisch oder zeitaufwändig abtun.
Der Grund ist strukturell. AI-Coding-Tools haben ein fundamentales Problem: Sie bekommen kein eindeutiges Feedback. Wenn Claude Code eine Funktion schreibt, weiß es nicht, ob die Funktion korrekt ist. Es kann den Code syntaktisch prüfen und gegen bekannte Muster vergleichen, aber es kann nicht verifizieren, ob das Ergebnis den Anforderungen entspricht. Tests lösen dieses Problem. Sie liefern binäres Feedback: Grün oder Rot, bestanden oder nicht bestanden.
Das macht TDD zum idealen Partner für agentic Coding. Der Red-Green-Refactor-Zyklus gibt Claude Code in jedem Schritt ein klares Signal, ob die Richtung stimmt.
Ein TDD-Workflow in der Praxis
Beispiel: Eine Funktion soll Datumsangaben aus deutschsprachigen Texten extrahieren. „15. März 2026“, „03/2026“, „Q1 2026“. Der TDD-Workflow mit Claude Code sieht so aus.
Red: Der Entwickler schreibt einen einzelnen fehlschlagenden Test. Zum Beispiel: assert extract_date(„Bis zum 15. März 2026 muss der Antrag eingehen“) == date(2026, 3, 15). Dieser Test definiert das erwartete Verhalten präzise. Claude Code sieht den Test und weiß exakt, was die Funktion leisten muss.
Green: Claude Code schreibt die minimale Implementierung, die den Test bestehen lässt. Nicht mehr, kein Code für Fälle, die noch nicht getestet sind. Der Entwickler fügt den nächsten Test hinzu: assert extract_date(„Vertragsende 03/2026“) == date(2026, 3, 1). Claude Code erweitert die Implementierung.
Refactor: Nach vier oder fünf grünen Tests räumt Claude Code den Code auf. Duplizierungen werden entfernt, Regex-Muster zusammengefasst und Edge Cases abgesichert, während die bestehenden Tests sicherstellen, dass das Refactoring nichts kaputt macht.
Ein entscheidendes Detail: Die Tests müssen vor der Implementierung committet werden. Claude Code hat die Tendenz, Tests an die Implementierung anzupassen statt umgekehrt. Wer die Tests vorher einfriert, hat eine Sicherheitslinie. Jeder Diff zeigt sofort, ob Claude Code die Tests oder den Code verändert hat.
Das halte ich für den größten Hebel, den Entwickler bei der Arbeit mit AI-Tools haben. TDD verwandelt ein probabilistisches Werkzeug in eines mit deterministischem Feedback. Jeder Red-Green-Refactor-Zyklus gibt dem Agenten eine klare Rückmeldung, ohne dass ein Mensch jede Zeile prüfen muss.
CLAUDE.md als Projektgedächtnis
Claude Code vergisst: Nach jeder Session beginnt es mit einem leeren Kontext, ohne Erinnerung an vorherige Entscheidungen oder Vereinbarungen. Die CLAUDE.md-Datei im Projektverzeichnis löst dieses Problem, indem sie dem Tool persistentes Wissen gibt. Jede Session beginnt mit dem Lesen dieser Datei.
Was einfach klingt, erfordert in der Praxis Disziplin. Eine schlecht strukturierte CLAUDE.md richtet mehr Schaden an als keine. Das Tool befolgt die Anweisungen wörtlich. Vage Formulierungen führen zu vagem Verhalten, und widersprüchliche Regeln erzeugen inkonsistenten Code.
Was gehört in die CLAUDE.md?
Vier Kategorien haben sich als produktiv erwiesen. Erstens: Projektarchitektur. Ein Überblick über die Verzeichnisstruktur, die wichtigsten Module und ihre Beziehungen zueinander. Nicht jede Datei, sondern die Struktur auf einer Ebene, die ein neuer Teammitglied am ersten Tag brauchen würde.
Zweitens: Konventionen. Namensgebung für Variablen, Dateien, Branches. Import-Reihenfolge. Teststruktur. Logging-Format. Alles, was im Code-Review beanstandet würde, wenn es falsch ist. Konkret formuliert, nicht abstrakt. „Verwende snake_case für Funktionsnamen“ statt „Halte dich an die Namenskonventionen“.
Drittens: Verbotenes. Was darf Claude Code nicht tun? Keine force-Pushes. Keine Änderungen an der Datenbank-Migration ohne explizite Freigabe. Kein Hinzufügen neuer Dependencies ohne Rückfrage. Diese negativen Regeln verhindern die teuersten Fehler.
Viertens: Befehle. Welches Skript die Tests ausführt, wie die Entwicklungsumgebung startet, welchen Linter das Projekt verwendet. Claude Code kann Shell-Befehle ausführen, aber nur wenn es weiß, welche.
Das Memory-System für sessionübergreifenden Kontext
Seit 2025 unterstützt Claude Code eine dreistufige Memory-Hierarchie. Auf der obersten Ebene liegt ~/.claude/CLAUDE.md mit persönlichen Präferenzen, die für alle Projekte gelten. Darunter die CLAUDE.md im Projektstammverzeichnis für teamweite Konventionen. Und in Unterverzeichnissen können modulspezifische CLAUDE.md-Dateien liegen, die nur für bestimmte Teile der Codebase gelten.
Seit Ende 2025 kommt eine weitere Schicht hinzu: der Ordner .claude/rules/ für modulare Regeldateien. Statt eine einzige CLAUDE.md immer größer werden zu lassen, können Teams spezifische Regeln in eigene Dateien auslagern und bei Bedarf auf Feature-Branches ergänzen.
Eine praktische Faustregel zum Umfang: Die offizielle Empfehlung von Anthropic lautet, CLAUDE.md-Dateien unter 200 Zeilen zu halten. Dateien, die diese Grenze deutlich überschreiten, verschwenden kostbaren Kontext aus dem 200.000-Token-Fenster von Claude Opus 4.6. Und bei längeren Dateien riskiert man, dass spätere Anweisungen bei der Kontextkomprimierung verloren gehen.
Eine gute CLAUDE.md hat eine Eigenschaft, die viele übersehen: Sie ist testbar. Jede Regel sollte so formuliert sein, dass ein Reviewer anhand des Outputs erkennen kann, ob sie befolgt wurde. „Verwende 2-Space-Einrückung“ ist testbar. „Schreibe sauberen Code“ ist es nicht.
Welche Antipatterns kosten am meisten Zeit?
Neben dem bereits beschriebenen generate-then-fix-Problem gibt es vier weitere Muster, die regelmäßig zu Produktivitätsverlusten führen.
Antipattern eins: Die vage Aufgabenbeschreibung. „Refaktoriere das Backend“ ist keine Aufgabe, sondern ein Wunsch. Claude Code interpretiert vage Anweisungen nach bestem Wissen, und dieses Wissen stimmt nicht immer mit den Erwartungen des Entwicklers überein. Das Ergebnis sind Änderungen, die technisch möglich, aber nicht gewünscht waren. Die Korrektur dauert länger als eine präzise Anweisung von Anfang an.
Antipattern zwei: Alles auf einmal. Ein Prompt, der gleichzeitig ein neues Feature implementieren, bestehende Tests anpassen, die Dokumentation aktualisieren und das Logging verbessern soll, überfordert selbst das beste Modell. Jede Teilaufgabe beeinflusst die anderen, und Claude Code verliert bei zu vielen gleichzeitigen Zielen den Fokus. Besser: Eine Aufgabe pro Interaktion, sequenziell abarbeiten.
Antipattern drei: Blind vertrauen. Claude Code kann mit großer Überzeugung Code schreiben, der eine API-Funktion aufruft, die nicht existiert. Oder eine Library-Version referenziert, die längst veraltet ist. Die METR-Studie zeigt: Selbst erfahrene Entwickler fallen gelegentlich darauf herein, weil der generierte Code so plausibel aussieht. Jeder Output braucht Verifikation. Ohne Ausnahme.
Antipattern vier: Die endlose Session. Claude Code komprimiert ältere Nachrichten automatisch, wenn das Kontextfenster voll wird. Dabei gehen Details verloren, und eine Entscheidung, die am Anfang der Session getroffen wurde, kann am Ende vergessen sein. Der Effekt sind inkonsistenter Code, widersprüchliche Änderungen und erneute Korrekturrunden, weshalb kürzere, fokussierte Sessions mit klarem Scope deutlich produktiver sind als Marathon-Sitzungen.
Antipattern fünf: Code-Review überspringen. Teams, die AI-generierten Code ohne gründliche Prüfung mergen, handeln sich Probleme ein, die später teuer werden. Die Faros-AI-Daten sprechen eine klare Sprache: 98 Prozent mehr Pull Requests, aber 91 Prozent längere Review-Zeiten und 9 Prozent mehr Bugs. Ohne gleichzeitige Skalierung der Review-Kapazität verschieben sich Probleme in die Produktion.
Das halte ich für den teuersten Fehler in dieser Liste. Alle anderen Antipatterns kosten Entwicklerzeit. Fehlende Reviews kosten Produktqualität.
Wann sollte man Claude Code nicht verwenden?
Nicht jede Aufgabe profitiert von AI-Unterstützung, und die Grenzen zu kennen ist genauso wichtig wie die Stärken. Es gibt Bereiche, in denen Claude Code zuverlässig die falsche Wahl ist.
Sicherheitskritischer Code. Kryptographie-Implementierungen, Authentifizierungslogik, Zugriffskontrolle: Das sind Bereiche, in denen ein subtiler Fehler katastrophale Folgen haben kann. Claude Code produziert hier Code, der auf den ersten Blick korrekt aussieht, aber Timing-Schwachstellen, unzureichende Eingabevalidierung oder fehlerhafte Zufallszahlengenerierung enthalten kann. Ein BSI-Audit unterscheidet nicht zwischen menschlichem und maschinellem Code, und die Haftung bleibt in jedem Fall beim Entwickler.
Performance-kritische Algorithmen. Wenn jede Mikrosekunde zählt, wenn SIMD-Instruktionen, Cache-Hierarchien oder Lock-free-Datenstrukturen zum Einsatz kommen, reicht „funktioniert“ nicht aus. Claude Code optimiert auf Korrektheit, nicht auf Performance. Der generierte Code läuft, aber nicht schnell genug für High-Performance-Computing, Echtzeitsysteme oder latenzempfindliche Finanzapplikationen wie den Hochfrequenzhandel, wo manuelles Tuning unverzichtbar bleibt.
Legacy-Code ohne Testsuite. Claude Code arbeitet am besten, wenn es Feedback bekommt. Ohne Tests fehlt dieses Feedback komplett. In einer Legacy-Codebase mit 200.000 Zeilen PHP und null Tests kann Claude Code Änderungen vornehmen, aber niemand weiß, ob sie etwas kaputt machen. Das Risiko unentdeckter Regressionen steigt mit jeder generierten Zeile. Hier gilt: Erst Tests schreiben (möglicherweise mit Claude Code), dann die eigentliche Aufgabe angehen.
Regulatorisch geprüfter Code. In Branchen wie Medizintechnik, Luftfahrt oder Automobilbau unterliegt Software strengen Zertifizierungsprozessen nach Normen wie IEC 62304 oder DO-178C. Diese Normen fordern lückenlose Nachvollziehbarkeit jeder Codeänderung. AI-generierter Code schafft hier neue Fragen: Wer ist verantwortlich für eine Änderung, die ein probabilistisches Modell vorgeschlagen hat? Für DACH-Unternehmen in regulierten Branchen ist das aktuell ein ungeklärtes Feld.
Was kostet produktive Nutzung im Alltag?
Die Frage nach den Kosten ist untrennbar mit der Frage nach der Produktivität verbunden. Anthropic beziffert den durchschnittlichen API-Verbrauch auf etwa 6 US-Dollar pro Entwickler und Tag. Bei 90 Prozent der Nutzer bleibt der Tagesverbrauch unter 12 US-Dollar. Das ergibt monatlich etwa 100 bis 200 Euro pro Entwickler, wenn ausschließlich Sonnet zum Einsatz kommt.
Prompt Caching reduziert diese Kosten erheblich. Das Schreiben in den Cache kostet 25 Prozent mehr als der normale Input-Token-Preis, aber das Lesen aus dem Cache kostet nur 10 Prozent des normalen Preises. Bei einer Cache-Trefferrate von 90 Prozent sinken die Kosten einer 100-Dollar-Session auf etwa 19 Dollar. Claude Code erreicht im Praxisbetrieb Cache-Trefferraten von über 90 Prozent, weil System-Prompt, Tool-Definitionen, CLAUDE.md und der Gesprächsverlauf systematisch gecacht werden.
Nach meiner Erfahrung unterschätzen die meisten Teams den Caching-Effekt bei der Kostenplanung. Die Differenz zwischen dem Listenpreis und den tatsächlichen Kosten mit aktivem Cache ist so groß, dass sie die gesamte ROI-Rechnung verändert.
Für ein fünfköpfiges Entwicklerteam in München sieht die Rechnung so aus: Claude Max-Abonnements für alle fünf Entwickler kosten rund 460 Euro monatlich (bei ca. 92 Euro pro Lizenz in der unteren Stufe). API-basierte Nutzung liegt zwischen 500 und 1.000 Euro, je nach Intensität. Zum Vergleich: Eine einzelne Entwicklerstunde kostet in München als Vollkosten (Gehalt, Lohnnebenkosten, Overhead) zwischen 65 und 95 Euro. Wenn Claude Code pro Entwickler auch nur eine Stunde pro Woche einspart, amortisiert sich die Investition. Die Frage ist nicht, ob es sich lohnt, sondern ob das Team die Workflows beherrscht, die den Zeitgewinn tatsächlich realisieren.
Ausblick
Die METR-Studie hat einen wertvollen Beitrag geleistet, indem sie den Blick von den Marketing-Versprechen auf die messbare Realität gelenkt hat. 19 Prozent langsamer ist ein Befund, der ernst genommen werden muss. Aber er beschreibt einen Durchschnitt, nicht ein Naturgesetz. Entwickler, die Plan-then-Execute, TDD-Workflows und eine durchdachte CLAUDE.md einsetzen, berichten von anderen Ergebnissen.
Die zentrale Erkenntnis dieses Artikels: Produktivität mit Claude Code ist kein Zufall und kein Feature, sondern eine erlernte Fähigkeit. Wer das Tool wie einen schnelleren Texteditor behandelt, wird enttäuscht. Wird es dagegen als Agent verstanden, der klare Aufträge, eindeutiges Feedback und projektspezifischen Kontext braucht, lässt sich damit genuiner Zeitgewinn erzielen.
Ich halte die Kombination aus TDD, Plan Mode und CLAUDE.md für den effektivsten Einstieg. Diese drei Elemente adressieren die häufigsten Fehlerquellen: fehlende Richtung (Plan Mode), fehlendes Feedback (TDD) und fehlenden Kontext (CLAUDE.md). Als Einstieg empfehle ich TDD, weil es den unmittelbarsten Effekt hat.
Im nächsten Teil dieser Serie geht es um fortgeschrittene Techniken: das Model Context Protocol (MCP), Multi-Agent-Workflows mit Subagenten und Prompt-Strategien für komplexe Projekte. Teil 3 richtet sich an Entwickler, die die Grundlagen aus diesem Teil beherrschen und das volle Potenzial des Tools ausschöpfen wollen.
Quellen
- METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, Juli 2025 (metr.org)
- Faros AI: AI Coding Tools Impact Analysis, 10.000+ Developers on 1.255 Teams, Juli 2025 (faros.ai)
- Anthropic: Claude Code Best Practices, 2025–2026 (code.claude.com/docs/en/best-practices)
- Anthropic: Prompt Caching, 2025 (platform.claude.com/docs/en/build-with-claude/prompt-caching)
- Anthropic: Claude Code Memory System, 2025–2026 (code.claude.com/docs/en/memory)
- Anthropic: Manage Costs Effectively, 2026 (code.claude.com/docs/en/costs)
- Hays: Gehaltsstudie 2025/2026, IT-Fachkräfte Deutschland (hays.de)
- The New Stack: Claude Code and the Art of Test-Driven Development, 2026 (thenewstack.io)
- Bloomberg: AI Coding Agents Are Fueling a Productivity Panic in Tech, Februar 2026 (bloomberg.com)