Claude Code ist kein Code-Generator. Es ist ein Agent. Wer es wie GitHub Copilot behandelt — Prompt rein, Code raus — verschenkt 90% des Potenzials und verbrennt dabei jede Menge Tokens. Power-User bauen stattdessen eine Umgebung, in der Claude eigenständig denken, planen und arbeiten kann.
Was Claude Code wirklich ist
Der häufigste Fehler: Claude Code als smarten Autocomplete zu benutzen. Einzeiliger Prompt, fix Ergebnis, weiter. Das funktioniert — aber es ist ungefähr so, als würde man einen Seniorentwickler ausschließlich für Copy-Paste-Aufgaben einsetzen.
Claude Code wurde als Agentic Coding Tool konzipiert. Es kann:
- Codebasen selbstständig navigieren und verstehen
- Mehrere Dateien gleichzeitig bearbeiten
- Bash-Befehle ausführen und Ergebnisse interpretieren
- Iterativ arbeiten: planen, ausführen, prüfen, korrigieren
Der Unterschied zwischen einem Power-User und einem Gelegenheitsnutzer liegt fast immer nicht im Prompt-Skill, sondern in der Umgebung, die sie für Claude einrichten.
Die CLAUDE.md — der größte einzelne Hebel
Eine CLAUDE.md-Datei im Projektstamm ist das Erste, was Claude Code beim Start liest. Wer diese Datei nicht hat, gibt Claude jeden Tag die gleichen Kontextinformationen im Prompt mit — oder eben nicht, was zu inkonsistenten Ergebnissen führt.
Eine gute CLAUDE.md enthält:
# Projektkontext
Dieses Projekt ist ein Rust-basiertes CLI-Tool für Netzwerkanalyse (libpcap + eBPF).
Target: Linux aarch64, CUDA 12.x.
# Architektur
- src/capture/ — libpcap-Integration
- src/ebpf/ — eBPF-Programme und Loader
- src/ui/ — Ratatui-basiertes TUI
# Conventions
- Fehlerbehandlung: anyhow überall, thiserror für öffentliche APIs
- Tests: cargo nextest, nicht cargo test
- Kein unwrap() in Produktionscode
# Häufige Befehle
- Build: cargo build --release
- Test: cargo nextest run
- Lint: cargo clippy -- -D warnings
Faustregel: Alles, was du einem neuen Kollegen in der ersten Stunde erklären würdest, gehört in die CLAUDE.md. Je spezifischer, desto besser.
Der Research-Plan-Implement-Workflow
Statt direkt mit „schreib mir eine Funktion für X“ anzufangen, trennen Power-User konsequent drei Phasen:
1. Research
Lies src/capture/mod.rs und src/ebpf/loader.rs.
Verstehe, wie die beiden Module aktuell kommunizieren.
Schreib noch nichts.
Claude liest die relevanten Dateien und gibt dir eine Zusammenfassung. Du prüfst, ob es richtig verstanden hat.
2. Plan
Ich will einen Ringbuffer einbauen, der eBPF-Events mit pcap-Paketen
korreliert. Wie würdest du das angehen? Zeig mir einen Plan,
bevor du irgendetwas implementierst.
Claude schlägt eine Lösung vor. Du diskutierst, korrigierst, ergänzt.
3. Implement
Gut. Jetzt implementiere Schritt 1 aus dem Plan.
Nur Schritt 1, nichts anderes.
Der Schritt-für-Schritt-Ansatz klingt langsamer, ist es aber nicht. Ohne Plan produziert Claude oft Code, der technisch funktioniert aber die falsche Abstraktion wählt — und dann fängst du von vorne an.
Kontextmanagement: /clear ist dein bester Freund
Der Kontext-Overhead ist real. Eine lange Session mit vielen Dateien, Shell-Outputs und hin-und-her Korrekturen kostet Tokens — und irgendwann fängt Claude an, frühere Entscheidungen zu „vergessen“ oder widersprüchliche Korrekturen zu machen.
Drei Regeln:
/clearzwischen unverwandten Aufgaben. Feature A und Feature B gehören nicht in dieselbe Session, wenn sie nichts miteinander zu tun haben.- Regelmäßige Checkpoints. Lass Claude nach einer komplexen Implementierung kurz zusammenfassen, was es getan hat. Das dient als Kontextverdichtung und zeigt dir, ob es auf dem richtigen Weg ist.
- Große Dateien gezielt laden. Statt „lies das gesamte Projekt“ lieber: „lies src/ebpf/loader.rs und erkläre, wie der BPF-Map-Zugriff funktioniert.“
Permissions und MCP-Server: einmal sauber einrichten
Wer Claude Code produktiv nutzt, konfiguriert es einmal richtig und nie wieder:
~/.claude/settings.json (global):
{
"permissions": {
"allow": [
"Bash(cargo:*)",
"Bash(git:*)",
"Bash(grep:*)",
"Bash(find:*)"
]
}
}
Ohne diese Konfiguration fragt Claude bei jedem Bash-Befehl nach — was bei einem Agenten, der 20 Befehle pro Aufgabe ausführt, schnell nervtötend wird.
MCP-Server erweitern Claude Code um externe Tools: GitLab-Integration, Datenbankzugriff, interne APIs. Der Aufwand für die Einrichtung zahlt sich aus, sobald Claude Code selbstständig Issues erstellen, PRs kommentieren oder gegen Staging-APIs testen kann.
Häufige Fehler und wie man sie vermeidet
„Mach das einfach fertig“
Zu breite Aufgaben führen zu Code, der technisch „fertig“ ist, aber nicht das tut, was du wolltest. Besser: Aufgaben in Teilschritte zerlegen, jeden bestätigen lassen.
Kein Feedback bei Korrekturen„Nein, das ist falsch" ohne Erklärung führt oft dazu, dass Claude die gleiche Lösung leicht variiert wiederholt. Besser: „Das funktioniert nicht, weil [Grund]. Versuche stattdessen [Richtung]."
Die Session als einzige Quelle der Wahrheit
Was im Chat gesagt wurde, ist nach /clear weg. Wichtige Entscheidungen und Konventionen gehören in die CLAUDE.md, nicht in den Chat.
Tool-Calls ignorieren
Claude Code zeigt dir jeden Bash-Befehl, den es ausführen will. Das ist kein Lärm — das ist der Blick in den Denkprozess. Wenn ein Befehl falsch aussieht, stopp und korrigiere. Billiger als danach aufzuräumen.
Fazit: Infrastruktur schlägt Prompt-Talent
Die besten Claude Code-Nutzer sind keine besseren Prompt-Schreiber. Sie haben bessere Infrastruktur:
- Eine gepflegte CLAUDE.md mit echtem Kontext
- Saubere Permissions-Konfiguration
- Konsequentes Session-Management
- Aufgaben, die klein genug sind, um verifizierbar zu sein
Claude Code ist ein Multiplikator — aber Multiplikator mal schlechte Struktur ergibt immer noch Chaos. Mit der richtigen Umgebung wird es zum schnellsten Entwickler-Kollegen, den du je hattest.
