Claude Code in der Praxis: Was der Terminal-Agent wirklich kann — und wo er scheitert

Über KI-Coding-Werkzeuge gibt es zwei Sorten von Texten: begeisterte Erfahrungsberichte aus der ersten Woche und Abrechnungen von Leuten, die nach einem enttäuschenden Versuch aufgegeben haben. Beide sind wenig hilfreich, wenn man entscheiden muss, ob so etwas in den Arbeitsalltag eines Teams gehört.

Wir nutzen Claude Code seit Monaten produktiv in Kundenprojekten — dieser Artikel ist übrigens damit entstanden, inklusive der Keyword-Recherche, die ihm zugrunde liegt. Was folgt, ist eine nüchterne Einordnung: was das Werkzeug ist, wo es sich von Copilot und Cursor unterscheidet, welche Aufgaben tatsächlich funktionieren, was es kostet und an welchen Stellen es verlässlich scheitert.

Was Claude Code ist

Claude Code ist ein KI-Agent von Anthropic, der im Terminal läuft und direkten Zugriff auf ein Projektverzeichnis hat. Er kann Dateien lesen und schreiben, Befehle ausführen, Tests laufen lassen, Git bedienen und über MCP externe Systeme anbinden. Neben dem CLI gibt es inzwischen eine Desktop-Anwendung, eine Web-Variante und Erweiterungen für VS Code und JetBrains.

Der entscheidende Unterschied zu den bekannteren Werkzeugen liegt in der Betriebsart:

	Autovervollständigung	IDE-Chat	Terminal-Agent
Beispiel	GitHub Copilot	Cursor, Windsurf	Claude Code
Arbeitseinheit	Nächste Zeilen	Datei oder Auswahl	Aufgabe über viele Dateien
Kennt das Projekt	Offene Dateien	Indexierten Kontext	Sucht selbst, was es braucht
Führt Befehle aus	Nein	Eingeschränkt	Ja — Tests, Build, Git
Arbeitet eigenständig	Nein	Kaum	Über viele Schritte
Gut für	Tippen beschleunigen	Lokale Umbauten	Abgegrenzte Aufgaben

Diese Unterscheidung ist keine Haarspalterei, sondern erklärt fast alle Enttäuschungen. Wer Claude Code wie eine Autovervollständigung benutzt, zahlt für Fähigkeiten, die er nicht abruft. Wer ihm umgekehrt eine unklar formulierte Großaufgabe hinwirft, bekommt viel Code, den niemand verantworten kann.

Was in der Praxis funktioniert

Aus unseren Projekten, geordnet nach Verlässlichkeit:

Die stärkste Einzelanwendung ist in unseren Projekten die Fehlersuche mit einem reproduzierbaren Fall. Wenn es einen fehlschlagenden Test oder einen klaren Reproduktionsweg gibt, arbeitet sich der Agent selbstständig durch: Hypothese, Änderung, Test, nächste Hypothese. Das ist genau die Schleife, die Menschen ermüdet und Maschinen nicht.

Die zweitstärkste ist Arbeit in fremdem Code. Ein gewachsenes Django-Projekt zu übernehmen, hieß früher: zwei Wochen lesen. Heute lässt sich in Stunden beantworten, wo etwas passiert, was womit zusammenhängt und welche Stellen bei einer Änderung mitbetroffen sind.

Kontext ist die eigentliche Arbeit

Der größte Hebel liegt nicht im Prompt, sondern in dem, was der Agent über euer Projekt weiß, bevor er anfängt. Claude Code liest dafür eine Datei namens CLAUDE.md im Projektverzeichnis.

Der häufigste Fehler ist, dort hineinzuschreiben, was das Projekt tut. Das kann der Agent selbst herausfinden. Nützlich ist, was er nicht herausfinden kann:

# Projektregeln

- Migrationen niemals bearbeiten, nachdem sie in main sind — immer eine neue.
- Tests laufen gegen echtes PostgreSQL, nicht SQLite: `make test`.
- Der Django-Admin ist nur für Stammdaten. Prozesse gehören in eigene Views.
- Kein neues Fremdpaket ohne Rückfrage. Wir tragen jede Abhängigkeit jahrelang.
- Fehlermeldungen an Nutzende auf Deutsch, Log-Ausgaben auf Englisch.

Fünf Zeilen dieser Art verändern die Ergebnisse deutlich stärker als jede Prompt-Formulierung. Es sind die ungeschriebenen Regeln, die ein neues Teammitglied in den ersten Wochen durch Korrekturen im Review lernt — nur dass man sie hier einmal aufschreibt.

Faustregel: Wenn ihr eine Anmerkung im Code-Review zum zweiten Mal schreibt, gehört sie in die CLAUDE.md.

Was es kostet

Claude Code ist entweder über ein Abonnement nutzbar oder über die API nach Verbrauch. Für ein Team, das täglich damit arbeitet, ist das Abonnement in aller Regel deutlich günstiger und vor allem planbar — die Nutzung nach Verbrauch kann bei langlaufenden Agentenaufgaben stark schwanken.

Der ehrlichere Kostenvergleich läuft aber nicht über die Rechnung, sondern über die eingesparte Zeit. Bei uns hat sich das Werkzeug in genau zwei Kategorien klar bezahlt gemacht: bei Aufgaben, die vorher aus Zeitmangel liegen blieben (Tests nachziehen, Abhängigkeiten aktualisieren, Dokumentation), und bei der Einarbeitung in fremden Code. Bei der eigentlichen Feature-Entwicklung an Systemen, die wir gut kennen, ist der Gewinn spürbar kleiner, als die Begeisterung im Netz vermuten lässt.

Die Grenzen, über die selten geschrieben wird

Es baut überzeugend an der Aufgabe vorbei

Der Agent schreibt zu jeder Aufgabe etwas, das funktioniert. Ob es das Richtige ist, prüft er nicht — dafür bräuchte er ein Verständnis eures Geschäfts, das er nicht hat. Die Konsequenz: Alles, was mit fachlicher Bedeutung zu tun hat, braucht ein Review durch jemanden, der die Fachlichkeit kennt. Das ist keine Übergangserscheinung, sondern strukturell.

Große Umbauten werden unübersichtlich

Eine Änderung über fünf Dateien ist gut prüfbar. Eine über vierzig ist es nicht — und genau solche produziert der Agent bereitwillig, wenn man ihn lässt. Wir arbeiten deshalb in kleinen Schritten mit Zwischen-Commits. Wenn ein Ergebnis nicht in einem Review erfassbar ist, war die Aufgabe zu groß gestellt.

Es sagt zu selten „das ist eine schlechte Idee“

Bittet man um eine fragwürdige Umsetzung, bekommt man sie meist — sauber gebaut. Ein erfahrener Mensch hätte nachgefragt. Für Teams ohne erfahrene Reviewer ist das ein echtes Risiko: Man kann sich damit sehr effizient in eine schlechte Architektur hineinarbeiten.

Das Ökosystem verändert sich schneller als die Dokumentation

Fähigkeiten, Bedienung und Grenzen ändern sich in Monatsabständen. Jeder Text darüber — dieser eingeschlossen — hat eine begrenzte Haltbarkeit. Wer eine Einschätzung von vor einem Jahr liest, liest über ein anderes Werkzeug.

Datenschutz und Unternehmenseinsatz

Für deutsche Unternehmen sind drei Punkte vor dem Einsatz zu klären, und sie sind alle lösbar:

• Auftragsverarbeitung. Für die geschäftliche Nutzung ist ein AV-Vertrag mit dem Anbieter nötig — bei Anthropic für Unternehmenskunden verfügbar.
• Trainingsnutzung. In den Geschäftstarifen wird euer Code standardmäßig nicht zum Modelltraining verwendet. Das gehört trotzdem einmal schriftlich geprüft, nicht angenommen.
• Was rausgeht. Der Agent sendet Dateiinhalte, die er liest. Produktionsdaten, Zugangsdaten und personenbezogene Daten gehören deshalb nicht in das Verzeichnis, in dem er arbeitet — was ohnehin gilt, aber hier konkrete Folgen hat.

Wer keine Daten außer Haus geben darf oder will, kommt zu offenen Modellen auf eigener Hardware. Das ist möglich, aber ein anderes Projekt — mit spürbaren Abstrichen bei der Qualität agentischer Aufgaben.

Wie wir es im Team eingeführt haben

Fazit

Claude Code ist kein Ersatz für Entwicklerinnen und Entwickler und auch nicht das Spielzeug, für das Skeptiker es halten. Es ist ein Werkzeug mit einem klaren Profil: stark bei abgegrenzten, überprüfbaren Aufgaben in bestehendem Code, schwach überall dort, wo Urteilsvermögen über Fachlichkeit gefragt ist.

Der Nutzen hängt weniger vom Werkzeug ab als von zwei Dingen, die ihr mitbringen müsst: aufgeschriebene Projektregeln und ein funktionierendes Code-Review. Teams, die beides haben, gewinnen spürbar Zeit. Teams, die keines von beidem haben, produzieren schneller Code, den niemand versteht — und das war schon vor der KI ein teures Problem.