Claude Code im Entwicklerteam ausrollen: ein pragmatisches Playbook aus der Praxis

Claude Code ist erstaunlich leistungsfähig, und genau das ist das Problem für Teams. Ein Tool, das selbständig Dateien analysiert, Code schreibt, Befehle ausführt und sich über mehrere Schritte durch ein Problem arbeitet, sollte man in einem Entwicklerteam nicht einfach installieren und beobachten, was passiert. Für einen einzelnen Entwickler ist das eine echte Hilfe. Für ein Team wird es zur Governance-Frage.

Ich schreibe das nicht aus theoretischer Perspektive. In den letzten Monaten habe ich Claude Code und ähnliche Agenten in Projekten mit Astro 5, Next.js, FastAPI, PostgreSQL, Ghost 5.x und Hetzner-Deployments eingesetzt. Bei abgegrenzten Tasks waren die Ergebnisse oft beeindruckend, bei gewachsenen Brownfield-Projekten wurde es schnell unübersichtlich – besonders dann, wenn der Agent ohne saubere Projektregeln gestartet wurde.

Claude Code braucht Leitplanken. Nicht als Bürokratie, sondern als Schutz vor teurem Unsinn. Dieser Artikel ist mein technisches Playbook für Teams, die Claude Code ernsthaft einsetzen wollen: mit CLAUDE.md, Permissions, Managed Settings, Hooks, MCP, sinnvollen Metriken und realistischen Rollout-Schritten.

Die Grundthese ist einfach: Das Harness ist wichtiger als das Modell. Ein gut geführtes Sonnet-Setup mit klarer Projektdatei schlägt in vielen Fällen ein unkontrolliertes Premium-Modell, das blind durch die Codebase arbeitet.

Warum Claude Code anders ist als Copilot

GitHub Copilot ist im Alltag stark bei Autocomplete, kleinen Funktionen, Boilerplate und Vorschlägen direkt im Editor. Der Entwickler bleibt durchgehend in der Kontrolle und entscheidet Zeile für Zeile.

Claude Code funktioniert grundsätzlich anders. Es ist ein agentisches System: Das Tool arbeitet direkt im Repository, analysiert Dateien, plant Änderungen, schreibt Code, führt Tests aus und startet Shell-Befehle. Anthropic beschreibt Claude Code als Werkzeug, das auf Projektebene operiert, also den vollständigen Codebase liest, einen Ansatz über mehrere Dateien hinweg plant, Änderungen umsetzt, Tests ausführt und auf Fehlschläge reagiert (Anthropic, „Claude Code“).

Damit verschiebt sich die Arbeit. Statt jede Zeile selbst zu schreiben, steuert man Arbeitspakete, prüft Pläne, reviewt Diffs und stoppt falsche Abzweigungen frühzeitig. Das klingt produktiv, und das ist es manchmal auch.

In einem Astro-Projekt habe ich Claude Code eine alte Komponentenstruktur analysieren lassen: mehrere Layout-Komponenten, wild verteilte Tailwind-Klassen, SEO-Logik teilweise in Page-Files versteckt. Die erste Analyse war brauchbar, der erste Umsetzungsversuch jedoch nicht. Claude wollte zu viel auf einmal anfassen: Komponenten, Routing, Styles und Content Collections in einem Rutsch. Ohne Projektregeln wird ein Agent schnell zu einem sehr höflichen Chaosgenerator.

Der eigentliche Trade-off: Geschwindigkeit gegen Kontrolle

Claude Code kann Code schneller vorbereiten, als ein Entwickler ihn von Hand schreiben würde. Refactorings über mehrere Dateien, ergänzte Tests, angeglichene API-Routen, vorbereitete Migrationen, geschriebene Dokumentation – alles möglich. Aber Geschwindigkeit ist keine Produktivität, wenn anschließend zwei Tage lang Diffs entwirrt werden müssen.

In reifen Codebases zählen andere Fragen. Hat der Agent die bestehende Architektur verstanden? Wurden Tests wirklich ausgeführt oder nur behauptet? Sind neue Dependencies dazugekommen? Wurde ein Edge Case gelöscht, weil er unnötig aussah? Hat jemand im Team den erzeugten Code verstanden?

Für mich sind deshalb diese vier Messpunkte wichtiger als Lines of Code:

Bereich	Frage
Speed	Kommt ein Task schneller bis zum Review?
Quality	Bleiben Tests, Typen und Architektur stabil?
Ownership	Versteht das Team den erzeugten Code?
Rework	Muss der AI-Code nach 7 oder 14 Tagen wieder repariert werden?

Gerade der letzte Punkt ist brutal ehrlich. AI-Code sieht oft gut aus, aber erst nach zwei Wochen weiß man, ob er wirklich gut war.

Die METR-Studie von 2025 liefert hier einen guten Reality Check. In einer randomisierten kontrollierten Studie mit 16 erfahrenen Open-Source-Entwicklern und 246 Tasks in eigenen, vertrauten Repositories erwarteten die Teilnehmer eine Beschleunigung von rund 24 Prozent durch AI-Tools. Tatsächlich brauchten sie mit AI-Unterstützung im Durchschnitt 19 Prozent länger, also langsamer statt schneller (Becker et al., METR, 2025). Das heißt nicht, dass AI-Coding nichts bringt. Es heißt: Gefühl reicht nicht aus, man muss messen.

CLAUDE.md: Die wichtigste Datei im Projekt

Wenn ich Claude Code in ein Projekt lasse, beginne ich nicht mit einem Prompt, sondern mit der Datei CLAUDE.md. Diese Datei wird laut Anthropic zu Beginn jeder Session automatisch in den Kontext geladen und enthält persistente Anweisungen für das Projekt (Anthropic, „How Claude remembers your project“). Sie ist Projektgedächtnis, Arbeitsvertrag und Warnschild zugleich. Sie erklärt dem Agenten, wie das Projekt funktioniert und wo er nichts anfassen soll.

Für ein Astro-5-Projekt mit Tailwind, Content Collections und Ghost 5.x als Content-Quelle würde ich zum Beispiel so starten:

markdown

# CLAUDE.md

## Projekt
Astro 5 Website mit TypeScript, Tailwind CSS und statischem Build.
Ghost 5.x wird als Headless CMS genutzt. Content kommt über die Ghost Content API.

## Commands
- Dev: `npm run dev`
- Build: `npm run build`
- Preview: `npm run preview`
- Lint: `npm run lint`

## Architektur
- Pages liegen in `src/pages/`.
- Komponenten liegen in `src/components/`.
- Layouts liegen in `src/layouts/`.
- Ghost-Content ist read-only.
- API-Logik gehört nicht in Astro-Komponenten.

## Regeln
- Keine neuen Dependencies ohne Rückfrage.
- Keine SEO-URLs ändern.
- Keine Änderungen an `.env` oder Secrets.
- Vor großen Refactorings zuerst Plan schreiben.
- Nach Codeänderungen immer `npm run build` ausführen.

Kurz, konkret und kopierbar. Je größer das Projekt, desto wichtiger wird die Hierarchie der Memory-Dateien. Claude Code unterstützt mehrere Ebenen, die kombiniert geladen werden – Enterprise-Policy, Projekt-Memory, Directory-Memory und Personal-Memory (Anthropic, Memory-Dokumentation). Eine Organisation kann eine globale CLAUDE.md haben, ein Frontend-Team eine eigene, und ein einzelnes Produkt noch einmal projektspezifische Regeln.

text

/CLAUDE.md
/apps/admin/CLAUDE.md
/apps/marketing-site/CLAUDE.md
/services/api/CLAUDE.md

Ich nutze das besonders gerne in Projekten, in denen FastAPI und Astro nebeneinander laufen. Der Agent muss wissen, dass UI-Änderungen nicht automatisch Backend-Migrationen bedeuten. Sonst versucht er schnell, sauber zu sein, und räumt Dinge auf, die absichtlich getrennt sind.

Permissions: Hier entscheidet sich, ob es professionell wird

Permissions sind kein Nebenthema. Sie sind der Unterschied zwischen kontrollierter Agentenarbeit und einem Tool, das zu viel darf. Permission-Regeln werden in der settings.json definiert und in einer festen Reihenfolge ausgewertet: Erst Deny-Regeln, dann Ask-Regeln, dann Allow-Regeln. Die erste passende Regel gewinnt (Anthropic, „Claude Code settings“).

Wichtig zu wissen: acceptEdits ist kein reiner Lesemodus. Je nach Claude-Code-Konfiguration können Dateiänderungen und bestimmte lokale Aktionen automatisch erlaubt sein. Für Solo-Projekte kann das angenehm sein, für Teams ist es heikel.

Ich blocke riskante Shell-Kommandos lieber explizit, besonders alles, was löschen, Rechte ändern, Pakete installieren, Container starten oder Git-History manipulieren kann.

json

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": [
      "Bash(rm:*)",
      "Bash(sudo:*)",
      "Bash(chmod:*)",
      "Bash(chown:*)",
      "Bash(git push:*)",
      "Bash(git reset:*)"
    ],
    "ask": [
      "Bash(npm install:*)",
      "Bash(pnpm add:*)",
      "Bash(npx:*)",
      "Bash(docker:*)",
      "Bash(docker compose:*)",
      "Bash(alembic upgrade:*)"
    ]
  }
}

Das ist kein universeller Standard, sondern eine vorsichtige Startlinie. In meinen FastAPI-Projekten setze ich Alembic-Kommandos fast immer auf „ask“. Eine Migration ist kein harmloser Formatierungsschritt. Wenn Claude eine Tabelle umbaut, will ich vorher den Plan sehen, immer.

Bei Hetzner-Deployments bin ich noch konservativer. Docker Compose, Caddy, Volumes, Backup-Pfade und Postgres-Dumps sind alles Dinge, die ein Agent nicht einfach ausprobieren sollte. Eine produktive Umgebung ist nicht der Ort, an dem ein Agent lernen sollte.

Managed Settings für Teams

Lokale Settings sind okay für Einzelkämpfer, Teams brauchen jedoch zentrale Regeln. Managed Settings haben in der Hierarchie die höchste Priorität: Sie können von keinem User-, Local- oder Project-Setting überschrieben werden (Anthropic, „Claude Code settings“). Damit sorgt eine Organisation dafür, dass nicht jeder Entwickler seine eigene Sicherheitslogik erfindet. Default-Modus, blockierte Tools, erlaubte Tools und Modellvorgaben werden zentral definiert.

Ein Minimalbeispiel:

json

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": [
      "Bash(rm:*)",
      "Bash(sudo:*)",
      "Bash(git push:*)"
    ],
    "ask": [
      "Bash(npm install:*)",
      "Bash(docker:*)",
      "Bash(alembic:*)"
    ]
  },
  "model": "sonnet"
}

Das Ziel ist nicht, Entwickler zu bremsen, sondern Vorhersehbarkeit zu schaffen. Wenn fünf Entwickler Claude Code nutzen, sollten sie nicht fünf verschiedene Risikoprofile haben. Einer erlaubt docker compose down, der andere blockt alles, der dritte lässt git push automatisch laufen. So entsteht kein Team-Workflow, sondern Zufall.

Ein wichtiger Hinweis aus der Praxis: In der Vergangenheit gab es offene GitHub-Issues, in denen Allow- und Deny-Regeln nicht zuverlässig durchgesetzt wurden (anthropics/claude-code Issue #18846). Wer auf maximale Sicherheit angewiesen ist, sollte deshalb kritische Einschränkungen zusätzlich über Hooks absichern, statt sich allein auf die Permission-Konfiguration zu verlassen.

Hooks: Audit-Trail statt Blackbox

Tools, die Logs schreiben, sind langfristig wartbar. Claude Code sollte in Teamumgebungen nicht unsichtbar arbeiten, und Hooks sind dafür einer der wichtigsten Bausteine. Sie machen sichtbar, welche Tools aufgerufen wurden, welche Dateien betroffen waren und welche Aktionen blockiert oder erlaubt wurden. Die offizielle Dokumentation kennt mehrere Hook-Events über den gesamten Lebenszyklus einer Session, darunter PreToolUse, PostToolUse, UserPromptSubmit, Notification und Stop (Anthropic, „Hooks reference“). Besonders relevant ist dabei PreToolUse, weil dieser Hook als einziger Aktionen vor der Ausführung blockieren kann.

Ein einfaches Audit-Setup kann so aussehen:

text

Claude Code
  -> Hook Event
  -> FastAPI Audit Endpoint
  -> PostgreSQL
  -> kleines internes Dashboard

Für ein eigenes Setup mit FastAPI reicht am Anfang ein sehr kleiner Endpoint:

python

from datetime import datetime
from fastapi import FastAPI, Request
from pydantic import BaseModel

app = FastAPI()

class ClaudeToolEvent(BaseModel):
    user: str | None = None
    project: str | None = None
    tool_name: str
    command: str | None = None
    file_path: str | None = None
    status: str

@app.post("/audit/claude-code")
async def log_claude_event(event: ClaudeToolEvent, request: Request):
    record = {
        "timestamp": datetime.utcnow().isoformat(),
        "ip": request.client.host if request.client else None,
        **event.model_dump()
    }
    print(record)
    return {"ok": True}

Natürlich ist print() kein Production-Logging, aber für den Start zeigt es die Richtung. Später geht das in PostgreSQL, ClickHouse oder ein bestehendes Logging-System. Was ich tracken würde: Tool-Name, Projekt, User, Command, Pfad, Status und Timestamp. Mehr braucht es am Anfang nicht.

Damit findet man schnell Muster. Ein Entwickler hat ständig Permission Denials? Vielleicht sind die Regeln zu eng. Ein Projekt erzeugt ungewöhnlich viele Edit-Calls? Vielleicht fehlt eine bessere CLAUDE.md. Ein Agent versucht regelmäßig npm install? Dann lohnt sich genaueres Hinsehen.

MCP: Stark, aber nicht harmlos

Das Model Context Protocol (MCP) ist ein offener Standard von Anthropic, der AI-Modelle mit externen Datenquellen und Tools verbindet, von GitHub und Playwright über Figma bis zu internen Datenbanken und eigenen APIs (Anthropic, „Introducing the Model Context Protocol“). Das macht Claude Code mächtig, und genau deshalb muss es kontrolliert werden.

In einem Contypio-ähnlichen Headless-CMS-Projekt wäre MCP interessant, um den Agenten mit interner API-Dokumentation, OpenAPI-Schemas, Design-System-Regeln und Playwright-Tests zu verbinden. Dann muss Claude nicht raten, wie ein Block funktioniert, sondern kann nachsehen. Aber direkt auf produktive Datenbanken sollte man MCP niemals als Startpunkt loslassen.

Ein sauberer Ansatz wäre:

text

Claude Code
  -> MCP Server
  -> read-only OpenAPI docs
  -> read-only component registry
  -> Playwright test runner
  -> no production database access

Gerade für Headless-CMS-Arbeit ist das stark. Claude kann prüfen, welche API-Felder existieren, welche UI-Komponenten vorhanden sind und welche Tests fehlschlagen, ohne automatisch die Macht zu bekommen, Daten zu verändern. Anthropic weist in der Sicherheitsdokumentation ausdrücklich darauf hin, dass MCP-Server nicht von Anthropic sicherheitsgeprüft werden und Vertrauen explizit verifiziert werden muss (Anthropic, „Claude Code Security“). Read-only zuerst, klein anfangen.

Agentic Search vs. RAG bei Code

RAG ist gut für Dokumentation, für Code ist es nicht immer die beste erste Wahl. Code hat Struktur: Imports, Funktionsaufrufe, Typen, Tests, Dateipfade, Build-Konfigurationen. Ein semantischer Treffer ist nicht automatisch der richtige Treffer.

Claude Code arbeitet oft sehr effektiv mit klassischen Tools:

bash

find . -name "*.ts" | head
grep -R "createUser" src/
grep -R "PUBLIC_API_URL" .
grep -R "from '@/components" src/

Das klingt banal, ist es aber nicht. Ein Agent kann diese Ergebnisse lesen, neue Suchfragen ableiten und iterativ weitergehen. Für Refactorings ist das oft besser als ein alter Embedding-Index, der den letzten Umbau noch nicht kennt.

Ich würde es so einordnen:

Aufgabe	Geeigneter Ansatz
API-Endpunkt in Codebase finden	Agentic Search
ähnliche Bugfixes in Dokumentation finden	RAG
interne Wissensdatenbank durchsuchen	RAG
Multi-File-Refactoring vorbereiten	Agentic Search
Code + Docs gemeinsam auswerten	Hybrid

Für meine Projekte heißt das: RAG ist nützlich für Dokumentation, Spezifikationen und längere Konzepttexte. Für Code lasse ich den Agenten zuerst mit echten Projektdateien arbeiten.

Claude Code vs. Copilot vs. Cursor

Diese Tools sollte man nicht in einen simplen Gewinner-Vergleich pressen, weil sie unterschiedliche Rollen haben.

Tool	Stark bei	Schwächer bei
GitHub Copilot	Autocomplete, kleine Funktionen, GitHub-Flow	größere autonome Refactorings
Cursor	schnelles Arbeiten im Editor, kleinere Repos, Inline-Chat	sehr große Brownfield-Projekte
Claude Code	Multi-File-Änderungen, Analyse, Refactoring, Tests	braucht klare Regeln und Review
Aider	CLI-basierte Codeänderungen, Git-orientierte Workflows	weniger komfortabel für visuelle UI-Arbeit
Continue	Open-Source, eigene Modelle, kontrollierte Setups	mehr Setup-Aufwand

Mein persönlicher Workflow ist meistens gemischt. Für schnelle Ideen nutze ich ChatGPT oder Claude im Browser, für Recherche Perplexity oder offizielle Docs, für konkrete Codebase-Arbeit Claude Code oder Codex-ähnliche CLI-Tools, und für kleine Inline-Sachen reicht Copilot. Ein Tool für alles klingt bequem, ist in echten Projekten aber selten die beste Lösung.

Rollout: Erst Pilot, dann Breite

Claude Code sollte man in einem Team niemals sofort für alle freischalten. Anthropic empfiehlt in der eigenen Rollout-Anleitung explizit einen Pilot-Ansatz mit einer kleinen Gruppe von Early Adopters, die zu internen Multiplikatoren werden (Anthropic, „Scaling Agentic Coding Across Your Organization“).

Eine sinnvolle erste Liste hat genau drei Punkte:

1. Ein echtes Projekt auswählen, kein Demo-Repo.
2. Eine saubere CLAUDE.md schreiben.
3. Permissions defensiv konfigurieren.

Danach lässt man 3 bis 5 Entwickler damit arbeiten, nicht einen Nachmittag, eher zwei Wochen. Das ist genug Zeit für echte Tasks, Build-Fehler, falsche Annahmen und brauchbare Diffs.

Die Pilotfragen sind simpel: Wo spart es Zeit? Wo produziert es Unsinn? Welche Befehle will Claude zu oft ausführen? Welche Regeln fehlen in CLAUDE.md? Welche Änderungen wurden übernommen und welche verworfen?

Erst danach würde ich auf Teamgröße skalieren. Dann kommen Managed Settings, Hooks, interne Beispiele, ein kleines Dashboard und ein Owner dazu. Dieser Owner ist wichtig, denn Claude Code ist kein einmaliges Setup. Die Regeln veralten, Modelle ändern sich, neue Features kommen dazu und Teams lernen dazu. Ohne Pflege wird das Setup schleichend schlechter.

Metriken, die nicht lügen

Lines of Code lügen fast immer. Für Claude Code interessieren mich andere Zahlen:

Metrik	Warum sie zählt
Weekly Active Developers	Wird das Tool wirklich genutzt?
Sessions pro Entwickler	Wird es regelmäßig oder nur neugierig genutzt?
Permission Denials	Sind Regeln zu eng oder genau richtig?
Edit Acceptance Rate	Wird der Output übernommen?
Rework nach 14 Tagen	War der Output wartbar?
Build/Test Failure Rate	Macht Claude stabile Änderungen?
Review-Kommentare pro AI-PR	Spart es Review-Zeit oder erzeugt es Arbeit?

Die beste Metrik ist für mich Rework. Wenn ein AI-generierter PR nach zwei Wochen großflächig korrigiert wird, war er nicht billig, sondern nur spät teuer.

Für Git-basierte Teams kann man das relativ einfach messen: PRs mit Label ai-assisted, Follow-up-Commits tracken, Build-Ergebnisse prüfen, Review-Kommentare zählen. Nicht perfekt, aber besser als Bauchgefühl.

Praxis: Ghost 5.x, Astro 5 und FastAPI

Ein Setup, das ich oft sinnvoll finde:

text

Ghost 5.x
  -> Content API
Astro 5
  -> Static Build
FastAPI
  -> Custom API / PostgreSQL
Hetzner
  -> Docker / Caddy / Postgres / Backups

Claude Code kann hier helfen, aber nur mit klaren Grenzen. Ghost-Content ist read-only, Astro baut die Seiten, FastAPI macht Custom Logic, PostgreSQL bleibt geschützt, und Docker und Deployment werden nicht automatisch verändert.

Eine passende CLAUDE.md für so ein Setup:

markdown

# CLAUDE.md

## Stack
- Ghost 5.x als Headless CMS
- Astro 5 als statisches Frontend
- FastAPI für Custom API
- PostgreSQL für persistente Daten
- Deployment auf Hetzner mit Docker Compose und Caddy

## Regeln
- Ghost Content API ist read-only.
- Astro API Routes bleiben thin.
- Business Logic gehört in FastAPI.
- Keine Docker- oder Caddy-Änderungen ohne Plan.
- Keine Änderungen an Backup-Pfaden.
- Keine neuen npm- oder Python-Packages ohne Rückfrage.

## Commands
- Astro Build: `npm run build`
- FastAPI Tests: `pytest`
- Alembic Status: `alembic current`

Das schützt vor typischen Agentenfehlern. Claude neigt sonst dazu, Dinge aufzuräumen, die bewusst getrennt sind.

Bei einem Ghost/Astro-Projekt wollte ein Agent einmal Content-Fetching, Routing und SEO-Metadaten in einem Schritt umbauen. Das sah sauber aus, war aber zu groß. Ich habe den Task gestoppt und in drei kleinere Schritte zerlegt: zuerst Fetching, dann Types, dann SEO. Danach war das Ergebnis brauchbar. Kleine Tasks gewinnen.

Praxis: Contypio und Headless-CMS-Architektur

Bei einem eigenen Headless CMS wie Contypio ist Claude Code noch wertvoller und noch riskanter. Solche Systeme haben viele Schichten: Collections, Pages, Blocks, API-Schemas, Admin-UI, Astro-Ausspielung, Berechtigungen und Datenbankmigrationen.

Ein Agent kann hier sehr gut analysieren, doppelte Patterns zwischen Blocks finden, API-Felder vergleichen, UI-Komponenten konsolidieren und Tests vorschlagen. Aber er darf nicht einfach das Datenmodell umbauen, nur weil es ihm eleganter erscheint.

Eine gute Projektregel wäre:

markdown

# CLAUDE.md

## Contypio Architektur
Collections sind die Datenebene.
Pages und Blocks sind die Präsentationsebene.
Beide laufen über eine gemeinsame API.

## Backend
- FastAPI
- SQLAlchemy
- Alembic
- PostgreSQL

## Frontend/Admin
- Komponentenbasierte Admin-UI
- bestehende Design Tokens verwenden
- keine neue Navigationslogik ohne UX-Begründung

## Kritische Regeln
- Keine Alembic-Migration ohne Plan.
- Keine Spalten löschen.
- Keine API-Feldnamen ändern ohne Kompatibilitätsprüfung.
- Keine Vermischung von Collection-Modell und Page-Block-Modell.

Der passende Prompt wäre nicht „mach das CMS besser“, sondern enger gefasst:

text

Analysiere die bestehenden Block-Komponenten für Gallery, Image und CTA.
Finde doppelte Patterns und Inkonsistenzen.
Erstelle einen Refactoring-Plan mit betroffenen Dateien.
Ändere noch keinen Code.

Das ist der Stil, mit dem Claude Code nützlich wird: erst Analyse, dann Plan, dann kleine Umsetzung. Anthropic empfiehlt in den eigenen Best Practices genau diesen Ablauf, „Explore, plan, code, commit“, mit dem ausdrücklichen Hinweis, dass die Anweisung „noch nicht codieren“ am Anfang einer Task die Ergebnisqualität deutlich erhöht (Anthropic, „Best practices for Claude Code“).

Kosten: Nicht jeder braucht das stärkste Modell

Bei Teams sehe ich oft den Reflex, allen das stärkste Modell zu geben in der Annahme, dass es schon passen wird. Das halte ich für falsch.

Viele Tasks brauchen kein Premium-Modell. Boilerplate, Tests, kleine Komponenten und einfache Refactorings funktionieren oft mit einem Standardmodell und guter Projektkonfiguration. Für Architekturentscheidungen, große Migrationen oder schwierige Brownfield-Probleme kann ein stärkeres Modell sinnvoll sein.

Entscheidend ist Task-Routing:

text

kleine UI-Fixes        -> Standardmodell / Editor-AI
große Refactorings     -> Claude Code mit Plan und Review
Architekturfragen      -> starkes Modell, aber ohne Schreibzugriff
Deployment-Änderungen  -> nur mit menschlicher Freigabe

Das spart Geld und reduziert Risiko. Ein unkontrolliertes starkes Modell bleibt unkontrolliert, nur teurer.

Der wichtigste praktische Prompt

Wenn ich nur eine Regel weitergeben müsste, wäre es diese: Analysiere zuerst, erstelle einen Plan, ändere noch nichts. Das klingt langweilig, funktioniert aber.

Claude Code ist am gefährlichsten, wenn Analyse und Umsetzung in einem großen Prompt vermischt werden. Dann bekommt man oft einen riesigen Diff mit halbguten Entscheidungen. Wenn man erst den Plan erzwingt, kann man früh eingreifen. Für Brownfield-Projekte ist das Pflicht.

Ein guter Startprompt:

text

Untersuche diese Codebase für den folgenden Task: [TASK].
Lies die relevanten Dateien.
Erstelle eine Liste der betroffenen Dateien, Risiken und vorgeschlagenen Schritte.
Führe keine Änderungen aus.

Danach folgt:

text

Setze nur Schritt 1 um.
Keine neuen Dependencies.
Nach der Änderung Tests oder Build ausführen.
Fasse die geänderten Dateien zusammen.

Das ist langsamer als „mach alles“, aber es spart Nerven.

Fazit: Claude Code braucht Führung

Claude Code kann Entwicklerteams schneller machen, aber nicht automatisch. Ohne CLAUDE.md, Permissions, Hooks und Review-Prozess wird es schnell zu einem Tool, das überzeugend klingt und zu viel verändert. Mit klaren Regeln wird es zu einem ernsthaften Bestandteil des Engineering-Workflows.

Für mich ist Claude Code am stärksten bei Analyse, Refactoring, Tests und Multi-File-Änderungen. Am schwächsten ist es dort, wo Projektkontext fehlt, Ziele unklar sind oder ein Agent Deployment- und Datenbankentscheidungen treffen soll.

Die Zukunft ist nicht „AI ersetzt Entwickler“, sondern: Entwickler steuern agentische Systeme und übernehmen Verantwortung für Architektur, Qualität und Betrieb. Genau dort trennt sich Spielzeug von professionellem Engineering.

Quellen

[1] Anthropic, „Claude Code – an agentic coding system“: https://www.anthropic.com/product/claude-code

[2] Anthropic, „How Claude remembers your project“ (Memory & CLAUDE.md): https://code.claude.com/docs/en/memory

[3] Anthropic, „Claude Code settings“ (Permissions & Managed Settings): https://code.claude.com/docs/en/settings

[4] Anthropic, „Hooks reference“: https://code.claude.com/docs/en/hooks

[5] Anthropic, „Claude Code Security“: https://code.claude.com/docs/en/security

[6] Anthropic, „Introducing the Model Context Protocol“: https://www.anthropic.com/news/model-context-protocol

[7] Anthropic, „Best practices for Claude Code“: https://www.anthropic.com/engineering/claude-code-best-practices

[8] Anthropic, „Scaling Agentic Coding Across Your Organization“ (PDF): https://resources.anthropic.com/hubfs/Scaling%20agentic%20coding%20across%20your%20organization.pdf

[9] Becker, J., Rush, N., Barnes, E., Rein, D., „Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity“, METR, Juli 2025: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

[10] Becker, J. et al., arXiv-Preprint zur METR-Studie: https://arxiv.org/abs/2507.09089

[11] anthropics/claude-code, Issue #18846 zu Bash-Permissions: https://github.com/anthropics/claude-code/issues/18846