Claude Code ist kein „Chat mit KI“.

Es ist ein agentenbasiertes Betriebssystem für Softwareentwicklung.

Wenn du Claude Code wie ChatGPT benutzt, bekommst du ChatGPT-Resultate.

Wenn du Claude Code wie ein Dev-Environment mit KI-Kern benutzt, bekommst du etwas völlig anderes:

eine Mischung aus IDE, DevOps-Agent, Code-Reviewer und Junior-Team.

Der wichtigste mentale Shift:

Claude Code ist kein Tool, das Code schreibt.

Es ist ein Tool, das Entwicklungsprozesse ausführt.

Das ist der Grund, warum Features wie:

• Hooks

• Subagents

• MCP-Server

• CLAUDE.md

• Ralph-Loops

überhaupt existieren ( ).

Sie wären für einen normalen Chatbot sinnlos – hier sind sie das eigentliche Produkt.

---

Warum die meisten Claude Code falsch benutzen

Die typische Nutzung sieht so aus:

"Kannst du mir Feature X implementieren?"

Das Ergebnis:

• Ein Haufen Code

• Keine Architektur

• Kein Kontext

• Kein Lernprozess

• Kein deterministischer Ablauf

Das ist, als würdest du in einer Firma jeden Morgen sagen:

„Baut mir heute irgendwas Cooles.“

Profis arbeiten anders:

Sie bauen Systeme, in denen Claude vorhersehbar arbeitet.

---

Die drei Ebenen von Claude Code

Claude Code hat intern drei Schichten:

1. Das Sprachmodell

Das ist das, was du aus ChatGPT kennst.

2. Das Agenten-Runtime-System

Hier passieren Dinge wie:

• Tool-Aufrufe

• Dateizugriffe

• Subagents

• Hooks

• MCP-Server

Das ist der eigentliche Game-Changer.

3. Dein Projekt als Regelwerk

Das entsteht durch:

• CLAUDE.md

• .claude/settings.json

• Hooks

• Agent-Definitionen

• MCP-Konfiguration

Du programmierst also nicht nur dein Projekt,

sondern auch das Verhalten des KI-Systems, das daran arbeitet ( ).

---

Claude Code ist ein Betriebssystem für Agenten

Wenn du es richtig einrichtest, sieht der Ablauf so aus:

1. Du beschreibst ein Ziel

2. Claude plant

3. Subagents erkunden den Code

4. Hooks sichern Regeln ab

5. MCP-Server liefern externe Fähigkeiten

6. Ralph-Loops treiben es zur Fertigstellung

7. GitHub Actions reviewen das Ergebnis

Das ist keine „KI die programmiert“.

Das ist eine KI-basierte Entwicklungsmaschine.

---

Warum CLAUDE.md wichtiger ist als jeder Prompt

In Claude Code gilt:

80 % der Qualität kommt aus dem Kontext, nicht aus dem Prompt.

Deine CLAUDE.md-Dateien sind:

• deine Coding-Standards

• deine Architektur

• deine No-Go-Zonen

• dein Projektgedächtnis

Ohne sie arbeitet Claude wie ein Freelancer ohne Briefing.

Mit ihnen arbeitet Claude wie ein interner Senior-Dev.

(Genau darauf baut das gesamte Setup aus  auf.)

Wenn du nur eine Sache in Claude Code richtig machst, dann diese:

Deine CLAUDE.md.

Sie ist kein Readme.

Sie ist kein Wiki.

Sie ist das Betriebssystem für deinen KI-Entwickler.

Fast alle „Claude ist dumm“-Momente kommen daher, dass die CLAUDE.md schlecht ist – nicht das Modell.

---

Was CLAUDE.md wirklich ist

CLAUDE.md ist für Claude das, was für einen Entwickler ist:

• Projekt-Setup

• Coding-Guidelines

• Architekturwissen

• Arbeitsanweisungen

• Tabus

Der Unterschied:

Ein Mensch vergisst,

Claude verliert Kontext.

CLAUDE.md ist das persistente Gedächtnis, das jedes neue Agenten-Gehirn beim Start bekommt.

---

Die wichtigste Regel

CLAUDE.md beschreibt nicht, was Claude tun soll,

sondern wie Claude herausfindet, was zu tun ist.

Schlechte CLAUDE.md:

„Bitte schreibe sauberen Code.“

Gute CLAUDE.md:

„Lint, Tests und Architekturregeln definieren, was ‘sauber’ bedeutet.“

---

Die Hierarchie (die fast niemand nutzt)

Profis haben nicht eine CLAUDE.md, sondern mehrere:

~/.claude/CLAUDE.md        → dein persönlicher Stil
./CLAUDE.md              → Projekt-Wahrheit
./src/CLAUDE.md          → Code-spezifische Regeln
./backend/CLAUDE.md      → API-Logik

Claude lädt sie rekursiv.

Das heißt:

• Root = große Regeln

• Tiefer = spezifischer

So vermeidest du:

„Bitte halte dich an Regel X, außer hier, außer dort, außer…“

Die Struktur erledigt das für dich.

---

Die perfekte Minimalstruktur

Eine gute Root-CLAUDE.md sieht ungefähr so aus:

# Projekt: <Name>

## Tech Stack
- Framework: …
- Sprache: …
- Datenbank: …

## Wichtige Befehle
- <wie man testet>
- <wie man lintet>
- <wie man startet>

## Architektur
- Wo ist was
- Welche Patterns gelten

## Verbote
- Was darf Claude niemals tun

Nicht mehr.

Nicht weniger.

Alles andere gehört in Unter-CLAUDE.md oder ins Repo.

---

Warum „Verbote“ so wichtig sind

Claude ist ein LLM.

Wenn es eine Datei sieht, denkt es:

„Vielleicht sollte ich die ändern?“

Ohne Verbote bekommst du:

• Änderungen an Migrations

• Zerstörte Legacy-Systeme

• Unbeabsichtigte Rewrites

Profis schreiben explizit:

## Verbote
- Keine Änderungen an src/legacy/**
- Keine direkten Commits auf main
- Keine .env lesen

Das ist kein Overhead.

Das ist Risikomanagement.

---

Was NICHT in CLAUDE.md gehört

Nie hier rein:

• Coding-Style (dafür gibt es Linter)

• Tool-Anleitungen

• Einmalige Fixes

• „Bitte sei vorsichtig“

Warum?

Weil Claude sonst lernt:

„Diese Datei ist ein Müllcontainer für Sonderfälle.“

Und dann hört es irgendwann auf, sie ernst zu nehmen.

---

Die wichtigste Technik: Progressive Disclosure

Schreibe nicht alles rein.

Schreibe rein, wo es steht.

Schlecht:

„Unsere Authentifizierung ist kompliziert und basiert auf 12 Services…“

Gut:

„Siehe docs/authentication.md für Auth-Architektur.“

Claude kann lesen.

Lass es lesen, statt es vollzupacken.

---

Mentales Modell

Deine CLAUDE.md ist:

Ein Vertrag zwischen dir und einem nicht-menschlichen Entwickler.

Je klarer dieser Vertrag ist, desto weniger musst du später im Prompt kämpfen.

Autonome Entwicklung mit Ralph-Wiggum

(Wie Claude aufhört zu antworten und anfängt zu arbeiten)

Ohne Ralph-Wiggum ist Claude Code ein sehr schlauer Praktikant.

Mit Ralph-Wiggum wird er zu einem unermüdlichen Junior-Team, das nicht aufhört, bis ein Ziel erreicht ist.

Der Unterschied ist fundamental.

---

Das Grundproblem von LLMs

Ein normales LLM denkt so:

„Ich habe geantwortet, meine Arbeit ist erledigt.“

Ein Entwickler denkt so:

„Es ist erst erledigt, wenn die Tests grün sind.“

Claude ohne Ralph hört auf, sobald er glaubt, dass eine gute Antwort gegeben wurde.

Claude mit Ralph hört erst auf, wenn ein technisches Kriterium erfüllt ist.

---

Was Ralph-Wiggum wirklich macht

Ralph ist kein Plugin, das „mehr Intelligenz“ gibt.

Er ist ein Stop-Hook.

Jedes Mal, wenn Claude denkt:

„Ich bin fertig“

wird Ralph aufgerufen und fragt:

„Bist du wirklich fertig – oder nur müde?“

Dann zwingt er Claude in die nächste Iteration, bis ein vorher definiertes Ziel erreicht wurde.

Genau das ist in der offiziellen Version implementiert (nicht als Bash-Loop, sondern als Session-Hook).

---

Der wichtigste Parameter: Completion-Promise

Ralph funktioniert nur, wenn du Claude exakt sagst, wann etwas als fertig gilt.

Beispiel:

Output <promise>DONE</promise> when:
- All tests pass
- No TypeScript errors
- Lint has zero warnings

Damit wird aus:

„Schreibe mir ein Feature“

ein:

„Arbeite, bis diese drei messbaren Zustände wahr sind.“

Das ist der Unterschied zwischen Chat und Engineering.

---

Warum Profis immer ein Iterations-Limit setzen

Ralph ist gnadenlos.

Wenn du ihm kein Limit gibst, kann er:

• 50 Durchläufe machen

• 100 Durchläufe machen

• dein Token-Budget verbrennen

Deshalb:

--max-iterations 20

Wenn es bis dahin nicht fertig ist, zwingst du Claude, zu erklären:

• Was blockiert?

• Was wurde versucht?

• Was wäre der nächste Ansatz?

Das ist besser als ein Zombie-Loop.

---

Ralph ist kein Autopilot – er ist ein Fließband

Ein häufiger Denkfehler:

„Ralph macht mein Projekt automatisch fertig.“

Nein.

Ralph macht Claude unermüdlich.

Du musst:

• das Ziel definieren

• die Completion-Kriterien setzen

• die Regeln (CLAUDE.md) liefern

Ralph sorgt nur dafür, dass Claude nicht frühzeitig aussteigt.

---

Typischer Profi-Workflow

1. Ziel formulieren

2. Tests oder Kriterien festlegen

3. Ralph starten

4. Claude iteriert

5. Tests laufen

6. Fehler → nächste Iteration

7. Erst wenn alles stimmt: DONE

Das ist exakt, wie menschliche Entwickler arbeiten – nur ohne Müdigkeit.

---

Wann Ralph Pflicht ist

Ralph solltest du immer nutzen bei:

• Feature-Implementierungen

• Refactorings

• Bugfixes mit Reproduktion

• Performance-Optimierungen

Nicht sinnvoll bei:

• Architektur-Diskussionen

• Design-Fragen

• Planung

Dafür gibt es Plan Mode.

Hooks – Wie du Claude von einer KI zu einer Maschine machst

Hooks sind der Grund, warum Claude Code ernstzunehmende Teams ersetzen kann.

Ohne Hooks ist Claude kreativ.

Mit Hooks ist Claude kontrolliert.

Und Kontrolle schlägt Kreativität in der Softwareentwicklung fast immer.

---

Was Hooks wirklich sind

Ein Hook ist ein Event-Handler für Claudes Gehirn.

Immer wenn etwas passiert wie:

• Claude will ein Tool ausführen

• Claude hat eine Datei geschrieben

• Claude will beenden

• Claude fragt nach einer Berechtigung

… wird dein Code aufgerufen.

Nicht Claudes Code.

Dein Code.

---

Warum das so mächtig ist

Normalerweise läuft ein LLM so:

Denken → Tool → Ergebnis → Weiter

Mit Hooks läuft es so:

Denken → Tool → Dein Skript → Ergebnis → Weiter

Das heißt:

• Du kannst Dinge blockieren

• Validieren

• Umformatieren

• Logging machen

• Sicherheitschecks durchführen

• Git-Branches wechseln

• Tests starten

Claude wird damit Teil deiner Toolchain, nicht andersherum.

---

Die wichtigste Kategorie: PostToolUse

Das ist der Profi-Hack.

Immer wenn Claude eine Datei ändert, kannst du automatisch:

• Formatter laufen lassen

• Linter ausführen

• Tests starten

• Typchecks erzwingen

Das bedeutet:

Claude kann keinen schlechten Code mehr abliefern, selbst wenn er wollte.

Beispiel-Denke:

„Claude darf Python schreiben, aber Black und MyPy entscheiden, ob es existieren darf.“

Claude schreibt.

Hook korrigiert oder blockiert.

Claude lernt daraus.

---

PreToolUse = Dein Sicherheitsgurt

Bevor Claude etwas Gefährliches tut (z. B. Bash ausführen), kannst du:

• Pfade prüfen

• Whitelists anwenden

• Secrets blockieren

• destructive Commands verhindern

Das verhindert:

• rm -rf

• Leaks von .env

• Git-Historie-Zerstörung

Ohne Hooks ist Claude vertrauensbasiert.

Mit Hooks ist Claude sandboxed.

---

Stop-Hook = Warum Ralph funktioniert

Ralph-Wiggum ist technisch nur ein spezieller Stop-Hook.

Wenn Claude denkt:

„Ich bin fertig“

… springt Ralph dazwischen und sagt:

„Nicht, solange das Promise nicht erfüllt ist.“

Das heißt:

Hooks sind nicht Add-ons.

Sie sind die Kontrollinstanz über den Lebenszyklus der KI.

---

Der größte Denkfehler

Viele denken:

„Hooks automatisieren Dinge für Claude.“

Nein.

Hooks erzwingen Regeln gegenüber Claude.

Das ist der Unterschied zwischen:

• „Bitte formatiere den Code“

• „Unformatierter Code existiert hier nicht“

Das zweite skaliert.

Das erste nicht.

---

Warum Hooks Claude besser machen

Claude ist probabilistisch.

Hooks sind deterministisch.

Die Kombination ist extrem:

• Claude findet Lösungen

• Hooks sorgen dafür, dass sie valide sind

Du bekommst:

• Kreativität + Verlässlichkeit

• Geschwindigkeit + Sicherheit

Das ist exakt das, was menschliche Teams schwer hinbekommen.

MCP-Server – Wie Claude Werkzeuge bekommt statt nur Wörter

Ohne MCP ist Claude ein sehr intelligenter Textprozessor.

Mit MCP wird Claude zu einem Systemadministrator, Datenbank-Client, DevOps-Agent und Produktmanager zugleich.

MCP steht für Model Context Protocol – in der Praxis heißt das:

Externe Systeme sprechen mit Claude so, als wären sie native Tools.

---

Was ein MCP-Server wirklich ist

Ein MCP-Server ist kein Plugin.

Er ist ein Adapter zwischen Claude und einer echten Softwarewelt.

Zum Beispiel:

• GitHub

• Datenbanken

• Browser

• Cloudflare

• Notion

• Sentry

• CI-Systeme

Claude bekommt nicht „Infos“.

Er bekommt APIs.

Er kann:

• Issues lesen

• PRs erstellen

• Logs abrufen

• SQL ausführen

• Webseiten steuern

• Tickets verschieben

Das ist nicht Simulation.

Das ist echte Systemintegration.

---

Warum MCP Claude radikal verändert

Ohne MCP:

„Claude, hier ist ein Fehlerlog, analysiere ihn.“

Mit MCP:

„Claude, hole dir selbst den Fehlerlog aus Sentry und untersuche ihn.“

Der Unterschied:

• Ohne MCP bist du der Mensch im Loop.

• Mit MCP ist Claude der Operator.

---

MCP ist Context + Action

Ein MCP-Server liefert zwei Dinge:

1. Schemas (Was ist möglich?)

2. Aktionen (Was kann ich tun?)

Diese werden beim Start der Session geladen.

Claude weiß dann:

„Ich kann GitHub-Issues lesen, PRs schreiben, Workflows triggern…“

Das ist der Grund, warum man MCP-Server gezielt aktivieren und deaktivieren muss:

Sie verbrauchen Context, aber sie geben Fähigkeiten.

---

MCP richtig benutzen (Profi-Regel)

Aktiviere nur die Server, die du für die aktuelle Aufgabe brauchst.

Beispiel:

• Bugfix → GitHub + Sentry

• Feature → GitHub + DB

• Design → Playwright + Figma

Claude Code erlaubt:

/mcp disable …
/mcp enable …

Das ist Context-Management auf Systemebene.

---

Warum MCP Claude nicht „smarter“, sondern gefährlicher macht

Mit MCP kann Claude:

• Datenbanken verändern

• Repos committen

• Tickets schließen

• Releases bauen

Deshalb brauchst du:

• Permissions

• Hooks

• Verbote in CLAUDE.md

Ein MCP ohne Kontrolle ist wie ein Root-User ohne sudo.

---

Mentales Modell

MCP macht Claude zu:

Einem Headless-Entwickler, der direkt mit deiner Infrastruktur spricht.

Ohne MCP ist Claude ein Berater.

Mit MCP ist Claude ein Mitarbeiter.

Subagents – Wie Claude mehrere Gehirne gleichzeitig benutzt

Subagents sind der Punkt, an dem Claude Code aufhört, wie ein einzelner Entwickler zu wirken –

und anfängt, wie ein kleines Engineering-Team zu arbeiten.

Die meisten Nutzer sehen nur einen Chat.

In Wirklichkeit kannst du eine Agenten-Orchestrierung steuern.

---

Was ein Subagent wirklich ist

Ein Subagent ist:

Ein eigener Claude mit eigenem Kontextfenster, eigenen Tools und eigener Aufgabe.

Das ist kein Thread.

Das ist kein Prompt.

Das ist ein separates Arbeitsgedächtnis.

Wenn du einen Subagenten losschickst, verbrennt er nicht deinen Haupt-Context –

er hat seinen eigenen.

---

Warum das so mächtig ist

Ohne Subagents:

Eine Aufgabe nach der anderen, alles im selben Kopf.

Mit Subagents:

5 Agenten durchsuchen parallel eine Codebase.

Beispiel:

• Einer liest frontend/

• Einer liest backend/

• Einer liest infra/

• Einer sucht nach Security-Issues

• Einer analysiert Performance

Der Hauptagent bekommt danach nur die Ergebnisse.

Das ist genau das, was Senior-Entwickler mit Junioren tun.

---

Die eingebauten Subagents

Claude bringt zwei mit:

Explore

Read-only.

Perfekt für:

• Codebase scannen

• Architektur verstehen

• Abhängigkeiten finden

Plan

Wird im Plan Mode benutzt.

Er analysiert, bevor irgendetwas geplant oder geändert wird.

Diese Agenten sind leichtgewichtig und extrem schnell.

---

Eigene Subagents bauen

Profis legen sich Spezialisten an:

• SQL-Agent

• Frontend-Agent

• Security-Agent

• Refactor-Agent

Diese leben in .claude/agents/

und haben:

• eigene Tools

• eigene Beschreibung

• manchmal sogar ein anderes Modell

Das heißt:

Du kannst dir ein ganzes Team aus KI-Rollen zusammenstellen.

---

Wann Subagents unverzichtbar sind

Subagents solltest du immer nutzen bei:

• großen Codebases

• Legacy-Systemen

• Performance-Analysen

• Security Reviews

• Refactorings

Nicht sinnvoll bei:

• kleinen Tasks

• Einzelfeatures

• kreativen Designentscheidungen

---

Der wichtigste Punkt

Subagents sind nicht für Output da.

Sie sind für Orientierung da.

Sie sorgen dafür, dass dein Haupt-Claude:

• nicht den Überblick verliert

• nicht rät

• nicht halluziniert

Er bekommt strukturierte Informationen statt roher Dateien.

Context-Management – Wie Profis verhindern, dass Claude „vergisst“

Claude Code hat riesige Context-Windows.

Das bedeutet nicht, dass sie unendlich sind.

Fast alle Probleme mit:

• Halluzinationen

• falschen Annahmen

• widersprüchlichem Verhalten

kommen daher, dass der Context zugemüllt ist.

---

Was Context wirklich ist

Context ist:

Alles, was Claude in seinem Arbeitsgedächtnis hält.

Dazu gehören:

• dein Prompt

• alle bisherigen Antworten

• geladene Dateien

• CLAUDE.md

• MCP-Schemas

• Subagent-Reports

Wenn das Fenster voll ist, muss Claude Dinge vergessen –

und er vergisst nicht intelligent, sondern statistisch.

---

Die 80-Prozent-Regel

Profis lassen Claude nie über ~80 % Context laufen.

Warum?

Ab dort beginnt:

• aggressives Komprimieren

• Verlust von Details

• instabile Entscheidungen

Claude Code zeigt dir den Füllstand:

/context

Das ist eines der wichtigsten Kommandos überhaupt.

---

Was du bei 80 % tun musst

Sobald du in den roten Bereich kommst:

1. Checkpoint erzwingen

   Lass Claude alles aufschreiben:

   • Was wurde gebaut

   • Welche Entscheidungen wurden getroffen

   • Welche TODOs offen sind

2. Session leeren

/clear

3. Catchup

/catchup

Claude lädt dann:

• Git-Diff

• relevante Dateien

• CLAUDE.md

  statt tausende alte Nachrichten.

Das ist wie ein sauberer Neustart mit Projektgedächtnis.

---

Warum Auto-Compact schlecht ist

Claude versucht selbst, den Context zu komprimieren.

Das ist bequem – aber gefährlich.

Warum?

Claude entscheidet selbst:

„Das hier ist unwichtig.“

Das kann:

• Architekturregeln

• Edge-Cases

• implizite Annahmen

löschen.

Profis compakten manuell:

/compact "Fasse zusammen:
- aktuelle Architektur
- offene Bugs
- nächste Schritte"

So kontrollierst du, was bleibt.

---

Checkpoints als Projektgedächtnis

In langen Projekten arbeiten Profis mit echten Dateien:

checkpoint-phase1.md
checkpoint-auth-refactor.md

Am Ende einer Phase:

„Schreibe den kompletten Stand in checkpoint.md“

In neuer Session:

„Lies checkpoint.md und fahre fort“

Damit wird Claude über Sessions hinweg stabil –

so, als hätte er Langzeitgedächtnis.

---

Mentales Modell

Claude hat kein Gehirn mit Erinnerungen.

Er hat ein Notizblatt mit begrenzter Größe.

Context-Management ist:

Das bewusste Umschreiben dieses Notizblatts, bevor es zu voll wird.

GitHub-Automatisierung – Wenn Claude Teil deines Teams wird

Ohne GitHub-Integration ist Claude ein lokaler Assistent.

Mit GitHub-Integration wird Claude ein Teammitglied, das Pull Requests liest, Issues versteht und auf Kommentare reagiert.

Das ist der Punkt, an dem Claude Code von „Dev-Tool“ zu „Engineering-System“ wird.

---

Was die GitHub-Integration wirklich macht

Claude bekommt:

• Zugriff auf dein Repository

• Zugriff auf Pull Requests

• Zugriff auf Issues

• die Fähigkeit, Commits und Reviews zu erzeugen

Aber nicht interaktiv, sondern:

Ereignisgesteuert, wie ein CI-System.

Claude reagiert auf:

• neue PRs

• Updates

• Kommentare mit @claude

Das ist keine Spielerei.

Das ist Agenten-Orchestrierung in deiner Delivery-Pipeline.

---

Der wichtigste Use-Case: PR-Reviews

Du kannst Claude automatisch bei jedem PR laufen lassen:

• Bugs suchen

• Security prüfen

• Stil analysieren

• Architekturverletzungen finden

Das Ergebnis:

Jeder PR bekommt ein KI-Review, bevor ein Mensch ihn sieht.

Damit wird Claude zu deinem immer wachen Code-Reviewer.

---

Der zweite große Use-Case: @claude als Trigger

In einem Issue oder PR-Kommentar:

@claude bitte implementiere das Caching für diesen Endpoint

Claude:

• liest den Kontext

• checkt den Code aus

• macht Änderungen

• öffnet oder aktualisiert den PR

Das ist kein Chat.

Das ist Remote-Arbeit.

---

Warum das so mächtig ist

Normalerweise ist Claude:

An deine aktive Session gebunden.

Mit GitHub Actions ist Claude:

An dein Repository gebunden.

Das heißt:

• dein Team kann Claude nutzen

• ohne dass du online bist

• mit denselben Regeln (CLAUDE.md, Hooks, Permissions)

Claude wird zu einer geteilten Ressource.

---

Die heimliche Superkraft: Determinismus

Weil GitHub Actions:

• saubere Umgebungen

• feste Inputs

• reproduzierbare Läufe

haben, wird Claude dort viel stabiler als im Chat.

Kein Context-Müll.

Kein Vergessen.

Nur:

Event → Prompt → Ergebnis.

---

Mentales Modell

Claude in GitHub Actions ist:

Ein autonomer Entwickler, der in deinem Repo lebt.

Nicht in deinem Browser.

Nicht in deinem Terminal.

In deiner Infrastruktur.

Plan Mode & Thinking Budgets – Wie du Claude zum Architekten machst

Claude ist standardmäßig ein Ausführungsmodell.

Er will helfen, indem er Dinge tut.

Aber große Systeme scheitern nicht an der Implementierung –

sie scheitern an schlechten Entscheidungen davor.

Plan Mode zwingt Claude, erst zu denken, dann zu handeln.

---

Was Plan Mode wirklich ist

Im Plan Mode:

• Claude darf nichts ändern

• keine Dateien schreiben

• keine Befehle ausführen

• nur analysieren und planen

Das ist extrem wichtig, weil:

Sobald Claude handeln darf, hört er auf, tief zu denken.

Plan Mode schaltet ihn in einen reinen Architektur- und Analysemodus.

---

Warum Thinking Budgets existieren

Claude hat unterschiedliche Tiefenstufen des Denkens.

Wenn du nichts sagst, denkt er:

„So wenig wie möglich, so schnell wie möglich.“

Wenn du sagst:

• think

• think hard

• think harder

• ultrathink

… bekommt er mehr internen Denkraum.

Das ist wichtig für:

• Architektur

• Refactoring

• Datenbankdesign

• Sicherheitsmodelle

• Performance

Nicht für:

• Boilerplate

• CRUD

• einfache Bugs

---

Der Profi-Workflow

So arbeiten erfahrene Teams mit Claude:

1. Plan Mode aktivieren

2. „Analysiere das System und schlage einen Umbau vor“

3. Claude denkt und schreibt einen Plan

4. Plan prüfen

5. Plan in plan.md speichern lassen

6. Plan Mode verlassen

7. „Implementiere Phase 1 aus plan.md“

Damit trennst du:

Denken und Ausführen.

Das ist extrem wichtig, um Chaos zu vermeiden.

---

Warum das alles stabiler macht

Ohne Plan Mode:

Claude erfindet Architektur während er Code schreibt.

Mit Plan Mode:

Claude entscheidet Architektur vorher

und implementiert danach.

Das reduziert:

• Rewrites

• Sackgassen

• inkonsistente Patterns

---

Mentales Modell

Plan Mode ist:

Ein Meetingraum, in dem Claude nicht programmieren darf.

Thinking Budgets sind:

Wie viel Zeit er in diesem Raum bekommt, bevor er spricht.

Die Produktions-Checkliste

(Wann Claude Code kein Spielzeug mehr ist)

Claude Code wird nicht dadurch produktionsreif, dass du ein gutes Modell nutzt.

Er wird produktionsreif, wenn seine Umgebung stimmt.

Diese Checkliste ist das, was erfahrene Nutzer implizit aufgebaut haben.

---

1. Dein Projekt hat eine saubere CLAUDE.md-Struktur

Du hast:

• eine Root-CLAUDE.md

• verzeichnis-spezifische CLAUDE.md

• klare Verbote

• klare Befehle

Claude weiß:

Was ist das Projekt?

Wie wird es gebaut?

Was darf ich nicht anfassen?

Wenn das nicht klar ist, ist alles andere egal.

---

2. Hooks erzwingen Qualität

Mindestens:

• Formatter nach jedem Write

• Linter oder Typchecker

• Sicherheits-PreChecks für Bash

Claude darf Fehler nicht behalten.

Wenn schlechter Code durchkommt, liegt das nicht an Claude –

sondern an fehlenden Hooks.

---

3. Autonome Loops für echte Arbeit

Ralph-Wiggum läuft für:

• Features

• Bugfixes

• Refactorings

Kein:

„Hier ist der Code, hoffe er funktioniert.“

Sondern:

„Arbeite, bis Tests und Lint grün sind.“

---

4. Subagents für große Aufgaben

Du nutzt Subagents, wenn:

• die Codebase groß ist

• Legacy existiert

• viele Bereiche betroffen sind

Der Hauptagent denkt.

Die Subagents lesen.

So vermeidest du Halluzinationen.

---

5. MCP nur dort, wo es gebraucht wird

Du hast:

• GitHub

• DB

• Sentry

• Browser

Aber nicht alles gleichzeitig.

Context ist ein Budget.

MCP-Server sind teure, aber mächtige Module.

---

6. Context wird aktiv gemanagt

Du nutzt:

• /context

• /compact

• /clear

• /catchup

• Checkpoint-Dateien

Claude vergisst nie unkontrolliert.

Er vergisst nur, wenn du es willst.

---

7. Plan Mode für Architektur

Große Änderungen beginnen mit:

• Plan Mode

• think hard / ultrathink

• plan.md

Erst danach wird implementiert.

---

8. GitHub ist angebunden

Claude:

• reviewed PRs

• reagiert auf @claude

• arbeitet in Actions

Er ist kein lokaler Helfer mehr.

Er ist Teil deines Teams.

---

Das eigentliche Geheimnis

Claude Code ist kein Tool.

Es ist ein System, das du konfigurierst.

Die meisten Menschen prompten.

Profis bauen Umgebungen.

Und in diesen Umgebungen ist Claude nicht magisch –

sondern zuverlässig.

Unter der Haube – Wie Claude Code wirklich denkt

Die meisten Nutzer sehen nur das Terminal.

Aber darunter läuft ein komplexes Prompt-System, das Claude steuert.

Wenn du verstehst, wie es funktioniert, kannst du Claude gezielter lenken.

Das ist der Unterschied zwischen:

„Claude, mach das irgendwie“

und:

„Claude, nutze den Explore-Agent mit Sonnet für diese Suche“

---

Was ein System-Prompt ist

Der System-Prompt ist:

Die unsichtbare Anleitung, die Claude bei jeder Session bekommt.

Du siehst ihn nie direkt.

Aber er bestimmt:

• welche Tools Claude kennt
• wie Claude sich verhalten soll
• welche Agenten verfügbar sind
• welche Regeln gelten

Deine CLAUDE.md wird in diesen System-Prompt injiziert.

Deshalb ist sie so wichtig.

---

Das Task Tool – Wie Subagents entstehen

Claude spawnt Subagents nicht magisch.

Er nutzt dafür das Task Tool.

Das Task Tool ist eine Funktion mit klaren Parametern:

{
  "description": "Kurze Beschreibung (3-5 Wörter)",
  "prompt": "Die eigentliche Aufgabe",
  "subagent_type": "explore | plan | general-purpose",
  "model": "sonnet | opus | haiku",
  "run_in_background": true | false
}

Wenn du sagst:

„Durchsuche die Codebase nach allen API-Endpoints“

… entscheidet Claude intern:

„Ich rufe das Task Tool mit subagent_type: explore auf“

---

Die verfügbaren Agenten-Typen

Claude Code bringt diese Agenten mit:

general-purpose

• Voller Tool-Zugriff
• Erbt den Kontext des Hauptagenten
• Für komplexe, mehrstufige Aufgaben

Explore

• Read-only
• Eigenes Kontextfenster (erbt nicht)
• Extrem schnell
• Für Codebase-Durchsuchung

Plan

• Architektur-Modus
• Analysiert vor Änderungen
• Für Implementierungsplanung

claude-code-guide

• Dokumentations-Lookup
• Für Fragen über Claude Code selbst

---

Der Explore-Agent im Detail

Der Explore-Agent hat einen eigenen System-Prompt.

Die wichtigsten Regeln:

=== CRITICAL: READ-ONLY MODE ===
- Keine Dateien erstellen
- Keine Dateien ändern
- Keine Befehle mit Seiteneffekten
- Nur: Glob, Grep, Read, limitiertes Bash

Das ist absichtlich so.

Warum?

Explore soll schnell und sicher sein.

Er darf nichts kaputt machen.

Er liefert nur Informationen zurück.

---

Warum das Wissen über Agenten-Typen hilft

Wenn du weißt, wie die Agenten funktionieren, kannst du sie gezielt steuern.

Beispiel:

Statt:

„Finde alle Stellen, wo wir Redis benutzen“

Besser:

„Starte einen Explore-Agent mit Sonnet und suche nach allen Redis-Verbindungen“

Claude wird dann:

• explizit Sonnet statt Haiku nutzen (gründlicher)
• den Explore-Typ wählen (schneller, read-only)
• parallel mehrere Suchen starten

Du steuerst die Maschine, nicht nur den Chat.

---

System-Reminders – Wie Claude sich selbst erinnert

Ein Problem von LLMs:

Sie vergessen Ziele mitten in langen Aufgaben.

Claude Code löst das mit System-Reminders.

Das sind Tags, die automatisch in den Kontext injiziert werden:

<system-reminder>
Deine CLAUDE.md enthält folgende Regeln:
- Keine Änderungen an src/legacy/**
- Tests müssen grün sein
</system-reminder>

Diese Reminders erscheinen:

• in User-Nachrichten
• in Tool-Ergebnissen
• an strategischen Punkten im Kontext

Sie sorgen dafür, dass Claude nicht abdriftet.

---

Todo-Listen sind keine Spielerei

Du hast vielleicht bemerkt:

Claude erstellt oft eine todo.md.

Das ist kein Zufall.

Es ist eine Aufmerksamkeits-Manipulation.

Indem Claude die Todo-Liste immer wieder neu schreibt:

• rezitiert er seine Ziele
• schiebt er sie ans Ende des Kontexts
• verhindert er „Lost in the Middle“-Probleme

Das ist Context Engineering in Aktion.

---

Die Tool-Schemas verstehen

Jedes Tool hat ein Schema.

Das Schema definiert:

• Name
• Beschreibung
• Parameter
• Erlaubte Werte

Claude sieht diese Schemas im System-Prompt.

Er entscheidet dann:

„Welches Tool passt zu dieser Aufgabe?“

Je besser du die Schemas verstehst, desto besser kannst du Claude instruieren.

---

Wie du Claude nach seinen Prompts fragen kannst

Ein Trick:

Du kannst Claude direkt fragen.

Probier mal:

1. „Zeig mir die Task Tool Beschreibung“
2. „Gib mir das vollständige Schema“
3. „Welche Subagent-Typen gibt es?“

Claude wird antworten.

Die Entwickler erlauben das mittlerweile.

Das ist kein Hack – das ist Transparenz.

---

Warum das alles wichtig ist

Die meisten Nutzer prompten blind.

Sie hoffen, dass Claude das Richtige tut.

Profis verstehen die Mechanik:

• Welche Tools existieren
• Wie Agenten gespawnt werden
• Wo Reminders injiziert werden
• Wie der Kontext aufgebaut ist

Damit wird aus:

„Claude, hilf mir“

ein:

„Claude, nutze diese Mechanik für dieses Ziel“

---

Mentales Modell

Der System-Prompt ist:

Das Betriebssystem, auf dem deine CLAUDE.md läuft.

Die Tools sind:

Die APIs, die Claude aufrufen kann.

Die Agenten sind:

Spezialisierte Worker mit eigenen Regeln.

Je besser du das System verstehst, desto präziser kannst du es steuern.

Skills – Wie Claude Wissen on-demand lädt

Normalerweise musst du alles in die CLAUDE.md packen.

Das Problem:

Je mehr drin steht, desto mehr Kontext wird verbraucht.

Skills lösen das elegant:

Claude lädt Expertise nur wenn er sie braucht.

Das ist wie Neo in Matrix:

„Ich kenne Kung Fu“ – aber erst, wenn es relevant wird.

---

Was ein Skill wirklich ist

Ein Skill ist ein Ordner mit:

.claude/skills/mein-skill/
├── SKILL.md          → Die Anleitung
├── scripts/          → Optionale Skripte
└── andere-dateien/   → Referenzmaterial

Die SKILL.md enthält:

• Metadaten (Name, Beschreibung)
• Anweisungen für Claude
• Best Practices
• Beispiele

Claude sieht nur die Metadaten im System-Prompt.

Der Rest wird erst geladen, wenn Claude den Skill aktiviert.

---

Der entscheidende Unterschied zu CLAUDE.md

CLAUDE.md:

Immer im Kontext. Immer aktiv. Immer Tokens verbrauchend.

Skills:

Nur Metadaten im Kontext. Inhalt wird bei Bedarf geladen.

Das ist massives Context-Sparen.

Stell dir vor:

• 10 Skills à 500 Zeilen
• Alle in CLAUDE.md = 5000 Zeilen permanent

Mit Skills:

• 10 kurze Beschreibungen = ~100 Zeilen
• Rest wird nur bei Bedarf geladen

---

Wie Claude entscheidet, welchen Skill er braucht

Claude sieht die Skill-Beschreibungen.

Wenn du sagst:

„Erstelle eine PowerPoint-Präsentation“

… denkt Claude:

„Da gibt es einen Skill für PPTX-Erstellung“

Dann ruft er die SKILL.md ab und lädt die Anweisungen.

Das passiert automatisch.

Du musst nichts tun.

---

Die Anatomie einer SKILL.md

Eine gute SKILL.md hat diese Struktur:

---
name: mein-skill
description: Kurze Beschreibung, wann dieser Skill genutzt wird
---

## Wann dieser Skill angewendet wird
- Trigger-Situationen

## Kernregeln
- Was Claude tun soll
- Was Claude nicht tun soll

## Beispiele
- Konkrete Anwendungsfälle

## Referenzen
- Verweise auf weitere Dateien im Skill-Ordner

Die Beschreibung in den Metadaten ist entscheidend.

Sie bestimmt, ob Claude den Skill überhaupt findet.

---

Eingebaute Skills

Claude Code kommt mit Standard-Skills:

• docx – Word-Dokumente erstellen
• xlsx – Excel-Tabellen erstellen
• pptx – PowerPoint-Präsentationen
• pdf – PDF-Verarbeitung
• frontend-design – UI-Entwicklung ohne „AI-Slop“

Diese werden automatisch aktiviert, wenn du entsprechende Aufgaben stellst.

---

Eigene Skills erstellen

Für wiederkehrende Domänen-Expertise:

1. Ordner anlegen: .claude/skills/dein-skill/
2. SKILL.md schreiben
3. Optional: Skripte hinzufügen

Beispiel für einen API-Skill:

---
name: unsere-api
description: Nutze diesen Skill bei Arbeit mit unserer REST-API
---

## API-Konventionen
- Alle Endpoints unter /api/v2/
- Auth via Bearer Token
- Pagination mit cursor-Parameter

## Fehlerbehandlung
- Immer try/catch
- Retry bei 429

## Verbotene Endpoints
- /api/admin/** (nur manuell)

Claude lädt das, sobald du etwas mit der API machst.

---

Skills vs. CLAUDE.md – Wann was?

In CLAUDE.md gehört:

• Projekt-Identität
• Grundlegende Architektur
• Universelle Verbote
• Wichtige Befehle

In Skills gehört:

• Domänen-spezifisches Wissen
• Detaillierte Anleitungen
• Best Practices für bestimmte Bereiche
• Umfangreiche Referenzen

Faustregel:

Wenn es immer gilt → CLAUDE.md

Wenn es manchmal gilt → Skill

---

Plugins – Skills auf Steroiden

Ein Plugin ist ein Paket, das mehrere Dinge bündelt:

• Skills
• Slash-Commands
• Subagent-Definitionen
• Hooks
• MCP-Server

Plugins sind für:

• Wiederverwendung über Projekte
• Teilen mit Teams
• Community-Distribution

Installation:

/plugins install <plugin-name>

---

Der Namespace-Trick

Plugins sind namespaced.

Das heißt:

• Dein Command: /deploy
• Plugin-Command: /mein-plugin:deploy

Keine Konflikte.

Du kannst mehrere Plugins mit ähnlichen Commands haben.

---

Hooks + Skills kombinieren

Der Profi-Move:

Nutze Hooks, um Claude an Skills zu erinnern.

Beispiel:

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Write",
      "command": "echo 'Denk an den code-quality Skill'"
    }]
  }
}

Jedes Mal, wenn Claude schreiben will:

Reminder an den Skill.

Das ist aktives Context-Management.

---

Warum Skills die CLAUDE.md entlasten

Viele Nutzer packen alles in CLAUDE.md.

Das Ergebnis:

• 2000+ Zeilen
• Claude ignoriert Teile
• Kontext wird verschwendet

Mit Skills:

• CLAUDE.md bleibt schlank (~200 Zeilen)
• Detailwissen liegt in Skills
• Claude lädt nur, was er braucht

Das ist Progressive Disclosure auf System-Ebene.

---

Die 500-Zeilen-Regel

Anthropic empfiehlt:

SKILL.md sollte unter 500 Zeilen bleiben.

Wenn mehr nötig ist:

• Aufteilen in mehrere Dateien
• SKILL.md verweist auf Referenzen
• Claude liest die Referenzen bei Bedarf

## Detaillierte Dokumentation
Siehe: ./api-reference.md
Siehe: ./error-codes.md

Claude kann lesen.

Lass ihn lesen.

---

Mentales Modell

Skills sind:

Bibliotheken, die Claude bei Bedarf importiert.

Plugins sind:

Vollständige Erweiterungspakete mit allem drum und dran.

CLAUDE.md ist:

Die Grundkonfiguration, die immer läuft.

Zusammen bilden sie ein schichtiges Wissenssystem:

• Kern (CLAUDE.md) → immer aktiv
• Erweiterungen (Skills) → on-demand
• Pakete (Plugins) → portable und teilbar

OpenCode – Claude Code ohne Anthropic-Lock-in

OpenCode ist das, was passiert, wenn die Community sagt:

„Wir wollen Claude Code – aber Open Source und provider-agnostic.“

Es ist kein billiger Klon.

Es ist ein vollwertiger Coding-Agent mit über 60.000 GitHub-Stars und 650.000+ monatlichen Nutzern.

---

Was OpenCode wirklich ist

OpenCode ist:

• Open Source (MIT-Lizenz)
• Provider-agnostic (Claude, GPT, Gemini, lokale Modelle)
• Terminal-first (wie Claude Code)
• Aber auch: Desktop-App + IDE-Extension

Der Kern-Unterschied:

Claude Code bindet dich an Anthropic.

OpenCode bindet dich an niemanden.

---

Die wichtigsten Gemeinsamkeiten

OpenCode hat fast alle Features, die du von Claude Code kennst:

Feature	Claude Code	OpenCode
Terminal UI	✅	✅
Custom Commands	✅	✅
Subagents	✅	✅
MCP-Server	✅	✅
Plan Mode	✅	✅
GitHub Integration	✅	✅
Hooks	✅	✅ (über Config)
Skills	✅	✅
Undo/Redo	✅	✅

Die Konzepte übertragen sich fast 1:1.

Wenn du Claude Code verstehst, verstehst du OpenCode.

---

Die wichtigsten Unterschiede

1. AGENTS.md statt CLAUDE.md

In OpenCode heißt die Projektdatei AGENTS.md.

Funktion ist identisch:

• Projektregeln
• Architektur
• Verbote

Wird mit /init automatisch erstellt.

2. Provider-Freiheit

Du kannst wählen:

• Claude (Anthropic)
• GPT-5.x (OpenAI)
• Gemini (Google)
• Lokale Modelle (Ollama, LM Studio)
• OpenCode Zen (kuratierte Modelle)

Konfiguration:

/connect

Dann Provider auswählen und API-Key eingeben.

3. Desktop-App existiert

OpenCode hat eine echte Desktop-Anwendung.

Nicht nur CLI.

Verfügbar für:

• macOS
• Windows
• Linux

Das ist relevant für Teams, die keine Terminal-Power-User sind.

4. IDE-Extensions

OpenCode integriert sich in:

• VS Code
• Neovim
• Andere IDEs

Claude Code hat das (noch) nicht nativ.

5. Conversations teilen

/share

Erstellt einen Link zur aktuellen Konversation.

Perfekt für:

• Team-Kollaboration
• Bug-Reports
• Dokumentation

Claude Code kann das nicht.

---

Die Build- und Plan-Agenten

OpenCode kommt mit zwei eingebauten Primär-Agenten:

Build

Standard-Modus.

Claude darf alles:

• Dateien lesen
• Dateien schreiben
• Befehle ausführen

Plan

Analyse-Modus.

Claude darf nur denken:

• Keine Änderungen
• Nur Vorschläge
• Nur Planung

Wechsel mit Tab.

Das ist exakt wie Plan Mode in Claude Code.

---

Subagents in OpenCode

OpenCode hat das gleiche Konzept:

• Task – Allzweck-Agent
• Explore – Read-only Codebase-Suche

Eigene Subagents werden als Markdown definiert:

~/.config/opencode/agents/review.md

Inhalt:

---
description: Code-Review ohne Änderungen
model: anthropic/claude-sonnet-4-5
tools:
  read: true
  edit: false
---

Du bist im Code-Review-Modus.
Fokus auf:
- Bugs finden
- Performance-Probleme
- Security-Issues

Keine direkten Änderungen machen.

Fast identisch zu Claude Code.

---

Custom Commands

Gleiche Struktur:

~/.config/opencode/commands/deploy.md

OpenCode unterstützt sogar Argumente:

# Deploy für $ENVIRONMENT

RUN npm run build
RUN npm run deploy:$ENVIRONMENT

Aufruf:

/user:deploy

OpenCode fragt dann nach $ENVIRONMENT.

---

LSP-Support

Ein Bereich, wo OpenCode voraus ist:

LSP (Language Server Protocol) ist eingebaut.

Das bedeutet:

• Echtzeit-Diagnostics
• Schnellere Refactorings
• Bessere Code-Navigation

Claude Code holt gerade auf, aber OpenCode hat es nativ.

---

Installation

So einfach wie Claude Code:

curl -fsSL https://opencode.ai/install | bash

Oder via Package Manager:

# macOS/Linux
brew install anomalyco/tap/opencode

# Windows
choco install opencode

# npm
npm install -g opencode-ai

---

Wann OpenCode statt Claude Code?

OpenCode ist besser, wenn:

• Du nicht an Anthropic gebunden sein willst
• Du verschiedene Modelle testen willst
• Dein Team Desktop-Apps bevorzugt
• Du Konversationen teilen musst
• Du lokale Modelle nutzen willst

Claude Code ist besser, wenn:

• Du das beste Claude-Erlebnis willst
• Du Anthropic Max hast (unlimitiert)
• Du die neuesten Claude-Features sofort brauchst
• Du auf GitHub Actions mit Claude setzt

---

Der hybride Ansatz

Viele Profis nutzen beides:

• Claude Code für komplexe Aufgaben (Opus 4.5)
• OpenCode für schnelle Tasks (GPT-5-codex, Haiku)

Die Konfigurationen sind ähnlich genug, dass du Wissen transferieren kannst.

---

Mentales Modell

OpenCode ist:

Claude Code als Open-Source-Projekt mit Provider-Freiheit.

Die Konzepte sind identisch:

• Projektregeln (AGENTS.md ≈ CLAUDE.md)
• Subagents (Task, Explore)
• Plan Mode
• Custom Commands
• MCP-Server

Wenn du eines verstehst, verstehst du beide.

Claude Code + OpenCode – Das Beste aus beiden Welten

Du musst dich nicht entscheiden.

Beide Tools können nebeneinander existieren.

Und das ist oft die smarteste Lösung.

---

Warum Parallelbetrieb sinnvoll ist

Verschiedene Modelle haben verschiedene Stärken:

Aufgabe	Bestes Tool
Komplexe Architektur	Claude Code (Opus 4.5)
Schnelle Bugfixes	OpenCode (GPT-5-codex)
Code-Review	OpenCode (o3)
Kreative Lösungen	Claude Code (Opus 4.5)
Lokale/Offline-Arbeit	OpenCode (Ollama)
Budget-Tasks	OpenCode (Haiku, GPT-4o)

Ein Tool für alles ist selten optimal.

---

Die Konfigurationen synchron halten

Das Problem:

• Claude Code hat CLAUDE.md
• OpenCode hat AGENTS.md

Die Lösung:

Symlink.

# In deinem Projekt
ln -s CLAUDE.md AGENTS.md

Jetzt lesen beide Tools dieselbe Datei.

Eine Wahrheitsquelle.

Keine Duplikation.

---

Custom Commands migrieren

Claude Code:

.claude/commands/deploy.md

OpenCode:

~/.config/opencode/commands/deploy.md

Die Syntax ist fast identisch.

Migration:

cp .claude/commands/*.md ~/.config/opencode/commands/

Bei Projekt-spezifischen Commands:

cp .claude/commands/*.md .opencode/commands/

---

Subagents migrieren

Claude Code:

.claude/agents/security-review.md

OpenCode:

.opencode/agents/security-review.md

Einziger Unterschied:

OpenCode braucht explizite tools-Konfiguration im Frontmatter:

---
description: Security-Review Agent
tools:
  read: true
  edit: false
  bash: false
---

[Rest des Prompts]

Claude Code macht das implizit über den Agenten-Typ.

---

MCP-Server teilen

Gute Nachricht:

MCP ist ein Standard.

Beide Tools können dieselben MCP-Server nutzen.

Du konfigurierst sie nur an verschiedenen Stellen:

Claude Code:

~/.claude/settings.json

OpenCode:

~/.config/opencode/config.json

Die Server-Definitionen sind kompatibel.

---

Workflow: Wann welches Tool?

Ein bewährter Workflow:

Morgens: Planung mit Claude Code

claude

• Plan Mode aktivieren
• Opus 4.5 mit ultrathink
• Architektur-Entscheidungen treffen
• Plan in plan.md speichern

Tagsüber: Execution mit OpenCode

opencode

• GPT-5-codex für schnelle Implementierung
• Haiku für einfache Tasks
• Wechsel zwischen Modellen je nach Bedarf

Abends: Review mit OpenCode

opencode --model openai/o3

• Reasoning-Modell für tiefe Analyse
• Bugs finden
• Security-Check

Vor Commit: Finaler Check mit Claude Code

claude

• Opus 4.5 für Gesamtbild
• Architektur-Konsistenz prüfen
• Finale Freigabe

---

Kosten optimieren

Der hybride Ansatz spart Geld:

Modell	Kosten	Nutzen für
Opus 4.5	$$$	Komplexe Entscheidungen
Sonnet 4.5	$$	Standard-Entwicklung
GPT-5-codex	$$	Schnelle Implementierung
Haiku	$	Einfache Tasks
Lokale Modelle	Strom	Offline, Privacy

Die Faustregel:

Teure Modelle für Denken.

Günstige Modelle für Tippen.

---

Tastenkürzel harmonisieren

Beide Tools haben ähnliche Defaults:

Aktion	Claude Code	OpenCode
Plan Mode	Tab	Tab
Context	/context	/context
Clear	/clear	/clear
Undo	Esc Esc	/undo

OpenCode erlaubt Custom Keybinds:

{
  "keybinds": {
    "switch_agent": "tab",
    "clear": "ctrl+l"
  }
}

Tipp: Mach sie identisch, um Muskelgedächtnis zu nutzen.

---

Projekt-spezifische Tool-Wahl

Manche Projekte sind besser für ein Tool:

Claude Code bevorzugen bei:

• Anthropic-Stack (Claude API Integration)
• Sehr komplexen Systemen
• Projekten, die Opus 4.5 brauchen

OpenCode bevorzugen bei:

• Multi-Provider-Projekten
• Teams mit verschiedenen Präferenzen
• Budget-sensitiven Projekten
• Offline-Entwicklung

---

Das Wrapper-Pattern

Für echte Profis:

Ein Alias, der das richtige Tool wählt:

# ~/.bashrc oder ~/.zshrc

ai() {
  if [[ -f ".prefer-claude" ]]; then
    claude "$@"
  elif [[ -f ".prefer-opencode" ]]; then
    opencode "$@"
  else
    # Default
    opencode "$@"
  fi
}

Jetzt:

# Projekt mit .prefer-claude
ai  # → startet Claude Code

# Projekt mit .prefer-opencode
ai  # → startet OpenCode

---

Gemeinsame Scratchpads

Beide Tools können dasselbe Scratchpad nutzen:

./scratchpad.md

Inhalt:

# Aktueller Stand

## Was gebaut wurde
- Feature X implementiert
- Bug Y gefixt

## Nächste Schritte
- Tests schreiben
- Dokumentation

## Offene Fragen
- Wie handlen wir Edge Case Z?

Egal welches Tool du öffnest:

Der Kontext ist da.

---

Wann komplett migrieren?

Vollständige Migration zu OpenCode macht Sinn, wenn:

• Du Anthropic-Kosten eliminieren willst
• Dein Team verschiedene Modelle braucht
• Du auf lokale Modelle umsteigen willst – EMPFOHLEN
• Du Open Source bevorzugst

Vollständige Migration zu Claude Code macht Sinn, wenn:

• Du Anthropic Max hast (Flatrate)
• Du nur Claude-Modelle nutzt
• Du die tiefste Integration willst

Für die meisten:

Parallelbetrieb ist optimal.

---

Mentales Modell

Claude Code und OpenCode sind:

Zwei Frontends für dasselbe Konzept.

Die Unterschiede sind:

• Provider (Anthropic vs. alle)
• Lizenz (proprietär vs. Open Source)
• Extras (Desktop-App, Share-Links)

Die Gemeinsamkeiten überwiegen:

• Projektregeln
• Subagents
• Commands
• MCP
• Plan Mode

Lerne eines gut.

Das andere folgt automatisch.