Claude Code in echten Projekten: Was funktioniert, was nicht

Vor einigen Monaten habe ich hier geschrieben, Claude Code sei der Akkuschrauber der Softwareentwicklung. Das Bild stimmt immer noch – aber nach Monaten intensiver Nutzung in echten Kundenprojekten will ich ergänzen: Ein Akkuschrauber in der falschen Hand beschädigt das Werkstück schneller, als man „Undo" sagen kann.

Claude Code ist ein außergewöhnlich starkes Werkzeug. Die Produktivitätsgewinne sind real. Aber sie entstehen nicht durch die KI allein – sie entstehen, wenn ein Entwickler mit Erfahrung daraufschaut, jede Änderung versteht und Fehler erkennt, bevor sie im Produktivsystem landen.

Was wirklich gut funktioniert

Bestimmte Aufgaben erledigt Claude Code verlässlich und in einem Bruchteil der Zeit:

• Boilerplate und Routinecode: DTOs, API-Endpoints, CRUD-Logik, Migrationen – alles, wo das Muster klar ist und nur der Kontext variiert.
• Refactoring in überschaubarem Umfang: Methoden umbenennen, Logik extrahieren, Typen enger fassen. Die KI sieht Zusammenhänge über viele Dateien hinweg.
• Testabdeckung aufbauen: Unit-Tests für bestehende, gut strukturierte Funktionen.
• Dokumentation und Kommentare: Nachträgliches Erklären von Code, Changelog-Einträge, README-Pflege.
• Fehlersuche im Explorationsmodus: Stack-Traces interpretieren, Hypothesen aufstellen, Log-Ausgaben ergänzen.

In diesen Bereichen ist der Output meistens brauchbar – mit Korrekturen vielleicht, aber ohne grobe Schnitzer.

Wo es regelmäßig danebengeht

Je weiter man sich von Standardmustern entfernt, desto häufiger produziert Claude Code Code, der auf den ersten Blick plausibel aussieht, aber falsch ist. Einige Beispiele aus der Praxis:

• Erfundene APIs und Methoden: Die KI ruft Funktionen auf, die es in der verwendeten Bibliotheksversion nicht gibt – weil sie in einer anderen Version existierten oder nach Mustern aus ähnlichen Libraries erfunden wurden.
• Subtile Logikfehler: Ein Off-by-one beim Paginieren, falsche Behandlung von null vs. undefined, verwechselte Vergleichsoperatoren in Filterbedingungen. Der Code kompiliert, läuft, liefert plausible Ergebnisse – aber eben nicht die richtigen.
• Nebenwirkungen übersehen: Eine Änderung an einer gemeinsam genutzten Funktion bricht an drei anderen Stellen etwas, die Claude nicht mit angefasst hat.
• Halbfertige Implementierungen: Funktionen, die wie vollständig wirken, aber einen Edge Case stillschweigend ignorieren – oft als // TODO getarnt oder ganz ohne Hinweis.
• Security-Fallstricke: Fehlende Input-Validierung, zu offene CORS-Einstellungen, Geheimnisse in Logs. Die KI kennt die Regeln, aber wendet sie nicht immer konsequent an.
• Architektur-Drift: Die KI löst ein konkretes Problem, legt dabei aber eine zweite Abstraktion neben eine bereits vorhandene an. Über Monate entsteht so ein Wildwuchs, den niemand bemerkt, wenn nur Zeile-für-Zeile reviewt wird.

Wichtig: Keiner dieser Fehler ist ein Grund, das Tool wegzulegen. Alle diese Fehler machen auch Menschen. Der Unterschied ist die Geschwindigkeit, mit der Claude Code sie produziert – und wie überzeugend sie formuliert sind.

Warum Erfahrung der entscheidende Faktor ist

Claude Code ist im Kern ein sehr gut belesener Junior, der rund um die Uhr arbeitet, nie müde wird und in fünf Sprachen gleichzeitig zuhause ist. Aber wie ein Junior braucht er jemanden, der prüft, einordnet und Richtung gibt.

Diese Prüfung funktioniert nur, wenn der Mensch davor die Materie versteht. Wer nicht weiß, wie die verwendete Bibliothek intern funktioniert, bemerkt nicht, dass die KI eine nicht existierende Methode aufgerufen hat – der Compiler-Fehler lässt sich ja „mit KI-Hilfe" wegfixen, bis irgendwann nichts mehr zusammenpasst. Wer die Geschäftslogik nicht im Kopf hat, nimmt eine plausible Filterlogik an, obwohl sie das Gegenteil tut, was der Kunde will.

Konkret heißt das: Ein erfahrener Entwickler muss

• jede generierte Zeile lesen, nicht nur überfliegen,
• gegen das tatsächliche System prüfen, nicht gegen die Beschreibung der KI,
• die Testabdeckung verantworten, weil Claude fröhlich Tests schreibt, die zum Bug passen statt zur Spezifikation,
• Architekturentscheidungen selbst treffen, nicht an die KI delegieren,
• wissen, wann man „Stop" sagt und eine Aufgabe manuell erledigt, weil das KI-Ergebnis schneller kaputt als fertig wäre.

Das ist keine Bremse – das ist genau die Arbeit, die das Engineering ausmacht. Claude Code nimmt die Mechanik ab, damit der Entwickler sich auf die Urteile konzentrieren kann, für die er bezahlt wird.

Die gefährliche Abkürzung

Was mir in Gesprächen immer wieder begegnet: Die Annahme, Claude Code sei der Einstieg für Nicht-Entwickler. „Damit kann doch jetzt jeder programmieren." Das ist so wahr wie „mit einem Akkuschrauber kann jeder Möbel bauen". Richtig ist: Wer Möbel bauen kann, baut sie schneller. Wer es nicht kann, baut schneller Müll.

In Kundenprojekten sehe ich regelmäßig Code, der sichtbar mit KI-Hilfe entstanden ist, ohne dass jemand mit Erfahrung darauf geschaut hat. Die Symptome sind immer ähnlich: inkonsistente Muster, tote Abstraktionen, Tests die nichts testen, Kommentare die lügen, Fehlerbehandlung die Fehler schluckt. So ein Projekt wieder in einen wartbaren Zustand zu bringen, kostet oft mehr als es von Hand neu zu schreiben.

Mein Fazit

Claude Code ist aus meinem Arbeitsalltag nicht mehr wegzudenken. Die Zeitersparnis ist echt, die Qualität meines Outputs ist nicht schlechter, sondern in vielen Fällen besser geworden, weil ich mehr Zeit für Architektur und Review habe.

Aber: Der Produktivitätsgewinn ist ein Multiplikator, kein Ersatz. Ein erfahrener Entwickler, der Claude Code nutzt, ist deutlich schneller als ohne. Ein unerfahrener Entwickler mit Claude Code produziert schneller Code – aber nicht schneller funktionierende Software.

Wer Softwareentwicklung ernst meint, sollte KI-Tools einsetzen. Und gleichzeitig daran festhalten, dass die Verantwortung für jede Zeile Code bei einem Menschen liegt, der versteht, was er tut.