Sechs Stufen der Claude Code Meisterschaft, die ich gerne früher gekannt hätte
Vor drei Monaten sah ich zu, wie eine meiner Claude Code-Sitzungen Output produzierte, der so generisch war, dass er von jedem beliebigen kostenlosen Chatbot im Internet hätte stammen können. Ich nutzte das Tool zu diesem Zeitpunkt täglich, seit fast einem Jahr. Ich hatte Kundenprojekte damit gebaut, Produktionscode damit ausgeliefert, sogar darüber auf diesem Blog geschrieben. Und trotzdem saß ich da und starrte auf Standardcode, für den sich ein Informatik-Erstsemester geschämt hätte.
Dieser Moment zwang mich, etwas Unangenehmes einzugestehen: Ich hatte Claude Code falsch benutzt. Nicht kaputt-falsch. Nicht Terminal-Absturz-falsch. Falsch auf die Art, wie jemand, der einen Ferrari im ersten Gang fährt, falsch liegt -- technisch gesehen bedient man die Maschine, aber man verpasst alles, was sie außergewöhnlich macht.
Was folgte, war ein dreimonatiger Deep Dive in das Verständnis der tatsächlichen Lernkurve bei der Beherrschung von Claude Code. Nicht die Marketing-Version, bei der alles am ersten Tag klickt. Die echte Version, bei der jede Stufe verlangt, dass man Gewohnheiten der vorherigen Stufe verlernt, und bei der die Fallen auf jeder Stufe gefährlicher sind als die eigentlichen Herausforderungen.
Ich habe sechs klar unterscheidbare Stufen identifiziert. Ich habe mich persönlich durch jede einzelne durchgekämpft, manchmal wochenlang auf einem Plateau feststeckend, bevor ich herausfand, was mich zurückhielt. Der Abstand zwischen Stufe 1 und Stufe 6 ist nicht nur ein Produktivitätsunterschied -- es ist eine grundlegend andere Beziehung zu KI als Entwicklungspartner.
Was mir niemand gesagt hat, als ich anfing: Der schwierigste Übergang ist nicht das Erlernen neuer Befehle. Es ist das Aufgeben der Denkweise, die einen zur aktuellen Stufe gebracht hat.
Stufe 1: Der Prompt Engineer (Wo alle anfangen und die meisten bleiben)
Ich erinnere mich lebhaft an meine erste Woche mit Claude Code. Ich behandelte es wie jedes andere Command-Line-Tool: Anweisung eintippen, Output erhalten, wiederholen. "Baue mir eine REST API für Benutzerauthentifizierung." "Schreibe Tests für diese Komponente." "Refactore diese Funktion auf async/await."
Und es funktionierte. Irgendwie. Claude generierte Code, ich fügte ihn in mein Projekt ein, reparierte ein paar Dinge und machte weiter. Der Workflow fühlte sich produktiv an, weil ich ihn mit dem manuellen Schreiben verglich. Jede Beschleunigung fühlte sich wie ein Gewinn an.
Das Problem war anfangs unsichtbar. Jeder Output hatte die gleiche Qualität -- angemessen, aber unspektakulär. Die Authentifizierungs-API funktionierte, aber sie verwendete Muster, die nicht zum Rest meiner Codebase passten. Die Tests deckten die Happy Paths ab, verpassten aber Edge Cases, die ich manuell gefunden hätte. Die refactorte Funktion war sauberer, ja, aber sie führte eine subtile Änderung in der Fehlerbehandlung ein, die ich erst in der Produktion bemerkte.
Das ist Stufe 1: der Prompt Engineer. Man schreibt Befehle und erhält Antworten. Einbahnkommunikation. Du redest, die KI hört zu, die KI produziert. Kein Dialog, keine Iteration innerhalb der Sitzung, keine Zusammenarbeit.
Die Falle auf dieser Stufe hat einen Namen, der sie perfekt beschreibt: AI slop. Generischer, technisch-korrekter-aber-charakterloser Output, der sich liest, als wäre er aus Dokumentationsfragmenten zusammengesetzt. Man erkennt ihn sofort -- er verwendet Variablennamen wie data und result, strukturiert Code auf die konventionellste Art und Weise und fügt Kommentare hinzu, die erklären, was der Code tut, statt warum.
Ich verbrachte etwa sechs Wochen auf Stufe 1. Mein Output war schneller als händisches Programmieren, erforderte aber so viel Nachbearbeitung, dass die Zeitersparnis marginal war. Der Durchbruch kam, als ich erkannte, dass ich Claude Code wie eine Schreibmaschine behandelte, obwohl es als Gesprächspartner gebaut war.
Was mich schließlich über diese Stufe hinausbrachte, war ein frustrierender Dienstagnachmittag. Ich hatte Claude Code gebeten, einen Webhook Handler zu bauen, und es produzierte etwas Funktionales, aber völlig losgelöst von den Mustern in meiner bestehenden Codebase. Statt den Prompt mit mehr Details umzuschreiben, versuchte ich etwas anderes. Ich begann, Fragen zurückzustellen.
Diese eine Verschiebung -- vom Befehlen zum Konversieren -- veränderte alles.
Stufe 2: Der Planer (Wo Dialog Diktat ersetzt)
Plan Mode war das Feature, das Stufe 2 für mich freischaltete. Falls du es noch nicht benutzt hast: Das Konzept ist einfach. Statt dass Claude Code deine Anfrage sofort ausführt, schlägt es zunächst einen Plan vor, stellt klärende Fragen und wartet auf deinen Input, bevor es eine einzige Zeile Code schreibt.
Als ich Plan Mode zum ersten Mal für eine komplexe Aufgabe aktivierte, war der Unterschied verblüffend. Ich bat Claude, ein Benachrichtigungssystem für ein Kundenprojekt zu bauen. Statt sofort Code zu generieren, kam es mit Fragen zurück, an die ich nicht gedacht hatte: "Sollen Benachrichtigungen in einer Datenbank gespeichert oder als flüchtige Events behandelt werden? Was ist die Zustellungspriorität -- soll das System die Zustellung garantieren oder ist Best-Effort akzeptabel? Planst du, neben E-Mail weitere Benachrichtigungskanäle zu unterstützen?"
Das waren keine generischen Fragen. Es waren genau die architektonischen Entscheidungen, die ich ohnehin hätte treffen müssen -- die ich aber wahrscheinlich implizit getroffen hätte, ohne sie richtig zu durchdenken, was später zu Nacharbeit geführt hätte.
Plan Mode verändert die Beziehung zu Claude Code grundlegend. Man hört auf zu befehlen und beginnt zusammenzuarbeiten. Die KI gibt Kontra, schlägt Alternativen vor, identifiziert Lücken in der Spezifikation. Es ist der Unterschied zwischen jemandem einen Bauplan zu geben und sich mit einem Architekten zusammenzusetzen, um gemeinsam zu entwerfen.
So sieht mein tatsächlicher Workflow auf Stufe 2 aus. Ich beginne jede nicht-triviale Aufgabe mit aktiviertem Plan Mode. Ich beschreibe auf hoher Ebene, was ich will. Claude schlägt einen Ansatz vor und stellt Fragen. Ich beantworte die Fragen und füge Einschränkungen hinzu. Claude verfeinert den Plan. Ich genehmige oder passe an. Erst dann beginnt die Codegenerierung. Die gesamte Planungsphase dauert fünf bis zehn Minuten, spart aber Stunden an Nacharbeit.
Die Falle auf Stufe 2 ist subtiler als die auf Stufe 1. Auf Stufe 1 ist die Falle offensichtlich -- schlechter Output. Auf Stufe 2 ist die Falle Passivität. Man gewöhnt sich daran, dass Claude gute Fragen stellt, und hört auf, die eigene Expertise einzubringen. Man wird zum Fragenbeantworter statt zum Mitdenker.
Ich ertappte mich dabei während eines Datenbankmigrationsparojekts. Claudes Plan war technisch solide, aber er schlug eine Migrationsstrategie vor, die während des Deployments Ausfallzeit verursacht hätte. Ich hätte ihn beinahe genehmigt, weil der Plan "gut aussah." Die Fragen, die Claude stellte, waren klug, aber es stellte nicht die eine Frage, die am wichtigsten war -- weil es nichts von unserer Zero-Downtime-Deployment-Anforderung wusste. Das war Wissen, das ich aktiv einbringen musste.
Die Lektion: Plan Mode macht Claude zu einem besseren Kollaborationspartner, aber es macht Claude nicht allwissend. Man muss weiterhin Kontext einbringen, den die KI nicht ableiten kann. Und zu wissen, welchen Kontext man einbringen muss -- das ist die Fähigkeit, die Stufe 3 definiert.
Stufe 3: Der Context Engineer (Wo sich die echte Kompetenzlücke auftut)
Dies ist die Stufe, an der sich Gelegenheits-Claude-Code-Nutzer und ernsthaft Praktizierende trennen. Context Engineering klingt akademisch, aber es ist die praktischste Fähigkeit in der gesamten Progression. Es ist die Kunst, Claude genau die richtige Information zum genau richtigen Zeitpunkt zu geben -- nicht mehr, nicht weniger.
Ich lernte das auf die harte Tour während eines großen Refactoring-Projekts. Ich hatte eine monolithische Express-Anwendung, die in Microservices aufgeteilt werden musste. Mein Ansatz war, die gesamte Codebase in Claudes Kontext zu laden, das Ziel zu erklären und es arbeiten zu lassen. Schien logisch. Maximale Information geben, maximale Qualität bekommen.
Die Ergebnisse waren furchtbar. Nicht sofort -- die ersten Dateien, die Claude refactorte, waren ausgezeichnet. Aber gegen die dritte Stunde wurden die Vorschläge merkwürdig. Funktionssignaturen, die nicht zu bestehenden Mustern passten. Importpfade, die auf Dateien in der alten Struktur zeigten. Variablennamen, die mitten in der Sitzung von camelCase zu snake_case wechselten. Es war, als würde man jemandem dabei zusehen, wie er in einem Marathon-Meeting langsam den Fokus verliert.
Das war meine erste Begegnung mit Context Rot, und das Verständnis davon veränderte alles an meiner Nutzung von Claude Code.
Context Rot: Der stille Leistungskiller
Hier ist die technische Realität, über die die meisten Tutorials hinweggehen. Claude Codes Context Window hat eine Kapazität, und bei dieser Kapazität geht es nicht nur darum, Information hineinzubekommen -- es geht darum, die Aufmerksamkeitsqualität über diese Information hinweg aufrechtzuerhalten. Sobald das Context Window über etwa 50-60% gefüllt ist, beginnt die Outputqualität auf frustrierend subtile Weise zu sinken.
Ich habe das systematisch über mehrere Projekte getestet. Gleiche Aufgaben, gleiche Prompts, unterschiedliche Kontextbelastung. Bei 20-30% Kontextauslastung war Claudes Output präzise, konventionsbewusst und strukturell konsistent. Bei 50% schlichen sich kleine Inkonsistenzen ein -- nichts, was den Build brechen würde, aber genug, um manuelle Nacharbeit zu erfordern. Bei 70%+ wurde der Output zu etwas, das ich nur als "selbstbewusst falsch" beschreiben kann. Syntaktisch korrekter Code, der architektonisch fragwürdige Entscheidungen traf.
Das /compact-Kommando wurde in dieser Phase mein bester Freund. /compact komprimiert den Gesprächskontext, entfernt abgeschlossene Austausche und bewahrt dabei die wesentlichen Informationen, die Claude für Kontinuität braucht. Ich führe es jetzt proaktiv aus, nicht reaktiv. Jedes Mal, wenn ich eine Teilaufgabe abschließe, komprimiere ich, bevor ich zur nächsten übergehe.
Und /clear? Das ist die nukleare Option, aber manchmal ist sie die richtige Wahl. Einen komplett frischen Kontext für eine neue Aufgabe zu starten, produziert besseren Output als eine aufgeblähte Sitzung fortzuführen, auch wenn es sich anfühlt, als würde man das Verständnis "verschwenden", das Claude aufgebaut hat. Das Verständnis jenseits von 60% Kapazität ist mehr Belastung als Vorteil.
Was man dem Kontext zuführen sollte (und was nicht)
Die andere Hälfte des Context Engineering ist Kuratierung. Nicht jede Datei ist relevant. Nicht jedes Stück Kontext hilft. Die gesamte package.json, alle Konfigurationsdateien und die komplette Testsuite "für alle Fälle" zu laden, ist das Kontext-Äquivalent davon, die gesamte Garderobe für einen Wochenendtrip einzupacken.
Mein Ansatz ist jetzt chirurgisch. Für jede Aufgabe identifiziere ich drei Kategorien von Kontext:
Essentieller Kontext -- Dateien, die direkt geändert werden oder die Interfaces definieren, denen der geänderte Code entsprechen muss. Diese kommen zuerst rein.
Referenzkontext -- Beispiele ähnlicher Muster in der Codebase, denen Claude folgen soll. Ich lade typischerweise ein oder zwei repräsentative Dateien, nicht jede Instanz.
Peripherer Kontext -- Dinge, die relevant sein könnten. Diese bleiben aus dem anfänglichen Kontext draußen. Wenn Claude sie braucht, fragt es danach -- und diese Frage selbst ist ein Signal, dass ich evaluieren sollte, ob der Kontext wirklich benötigt wird.
Ich begann auch, Screenshots von UI-Komponenten bereitzustellen, wenn ich an Frontend-Code arbeitete. Klingt offensichtlich, aber ich wehrte mich wochenlang dagegen, weil es sich ineffizient anfühlte. Wie sich herausstellte, gibt ein Screenshot des aktuellen Komponentenzustands Claude mehr nützlichen Kontext als drei Absätze Beschreibung. Visueller Kontext wird unterschätzt.
Die CLAUDE.md-Datei im Projektstammverzeichnis ist ein weiteres Stufe-3-Werkzeug, das die meisten Leute zu wenig nutzen. Meine enthält Programmierkonventionen, architektonische Entscheidungen und explizite Regeln wie "verwende immer Early Returns" und "Fehlerantworten müssen sowohl einen maschinenlesbaren Code als auch eine menschenlesbare Nachricht enthalten." Das automatische Laden dieser Konventionen bedeutet, dass Claude jede Sitzung bereits auf meine Muster abgestimmt startet, ohne Kontext für Erklärungen zu verbrennen.
Die Falle auf Stufe 3 ist, das Kontextmanagement so zu überdenken, dass man mehr Zeit mit dem Kuratieren von Eingaben verbringt als mit dem Generieren von Ausgaben. Ich steckte hier etwa zwei Wochen fest, obsessiv Kontextauslastungsprozentsätze messend und bei jeder Datei zweifelnd, die ich lud. Der Gleichgewichtspunkt liegt näher bei "gute Kuratierung, schnell" als bei "perfekte Kuratierung, langsam."
Was mich schließlich weiterbrachte, war die Erkenntnis, dass Kontextqualität wichtiger war als Kontextmenge -- und dass bestimmte Tools Kontextentscheidungen automatisch für mich treffen konnten. Diese Erkenntnis öffnete die Tür zu Stufe 4.
Stufe 4: Der Tool-Integrator (Wo Claude Code Superkräfte bekommt)
Stufe 4 ist der Punkt, an dem Claude Code aufhört, nur ein Code-Assistent zu sein, und beginnt, eine erweiterbare Entwicklungsplattform zu werden. Dies ist die Stufe der MCP-Server -- Model Context Protocol-Server und Frameworks, die Claude Fähigkeiten jenseits der Textgenerierung verleihen.
MCP-Server sind in der Praxis Plugins, die Claude mit externen Systemen interagieren lassen. Datenbankabfragen. API-Aufrufe. Dateisystemoperationen. Browser-Automatisierung. Design-Tool-Integration. Jeder MCP-Server erweitert, was Claude kann, ohne dass man manuell Daten zwischen Tools kopieren muss.
Ich integrierte meinen ersten MCP-Server -- einen PostgreSQL-Connector -- nachdem ich einen ganzen Nachmittag damit verbracht hatte, Abfrageergebnisse manuell aus pgAdmin in Claudes Kontext zu kopieren, damit es mir bei der Optimierung langsamer Queries helfen konnte. Die Absurdität dieses Workflows traf mich mitten beim Einfügen. Ich war die langsamste Komponente in meiner eigenen Pipeline -- ein menschliches Klemmbrett zwischen zwei digitalen Tools.
Nach dem Verbinden des Postgres MCP-Servers konnte ich einfach sagen "analysiere die langsamen Queries in der Orders-Tabelle und schlage Indexverbesserungen vor." Claude würde die Datenbank direkt abfragen, die Ausführungspläne untersuchen und optimierte Indizes vorschlagen -- mit dem tatsächlichen SQL, um sie zu erstellen. Was einen Nachmittag Copy-Paste kostete, wurde zu einem Fünf-Minuten-Gespräch.
Aber hier wird Stufe 4 gefährlich.
Die Tool-Overload-Falle
Meine MCP-Server-Sammlung wuchs nach dieser ersten Integration schnell. Postgres-Connector. GitHub-Integration. Slack für Benachrichtigungen. Notion für Dokumentation. Browser-Automatisierung für Tests. Linear für Projektmanagement. Figma für Designspezifikationen.
Innerhalb von zwei Wochen hatte ich elf MCP-Server konfiguriert. Und Claudes Leistung brach ein.
Nicht weil die Server fehlerhaft waren -- sie funktionierten einzeln einwandfrei. Das Problem war der kognitive Overhead auf Claudes Seite. Mit elf verschiedenen verfügbaren Tools griff Claude manchmal zum falschen, oder verbrachte Tokens damit zu evaluieren, welches Tool zu verwenden sei, bevor es die eigentliche Arbeit erledigte. Schlimmer noch: Zu viele Möglichkeiten machten Claudes Antworten langsamer und gelegentlich verwirrt darüber, welches Tool welche Aufgabe bewältigen konnte.
Ich lernte diese Lektion während einer Code-Review-Sitzung. Ich bat Claude, einen Pull Request auf Sicherheitsprobleme zu überprüfen. Statt den Code direkt zu analysieren, versuchte es den GitHub MCP-Server zu nutzen, um PR-Metadaten abzurufen, dann die Browser-Automatisierung, um den Diff zu rendern, dann den Postgres-Connector, um auf SQL-Injection-Muster zu prüfen -- eine Rube-Goldberg-Maschine aus Tool-Aufrufen, die schlechtere Analyse produzierte als einfaches Lesen des Codes.
Die Lösung war chirurgische Auswahl. Ich reduzierte meine MCP-Konfiguration auf fünf Server, die ich tatsächlich täglich nutzte: GitHub, Postgres, einen File System Watcher, Notion und ein selbst gebautes API-Test-Tool. Alles andere wurde entfernt.
Das Prinzip, dem ich jetzt folge: Füge ein Tool erst hinzu, wenn du mindestens dreimal auf die gleiche manuelle Workflow-Reibung gestoßen bist. Wenn dich die Abwesenheit einer Fähigkeit nicht aktiv nervt, brauchst du das Plugin nicht. Fähigkeit und Leistung sind nicht dasselbe -- mehr Tools bedeutet nicht besseren Output.
Die Framework-Auswahl ist ebenfalls wichtig. Ich habe versucht, Claude Code mit verschiedenen Automatisierungs-Frameworks zu integrieren, und das Muster ist konsistent: Die, die am besten funktionieren, tun eine Sache gut und haben saubere, vorhersagbare Interfaces. Die, die alles sein wollen -- umfassende KI-Entwicklungsplattformen mit siebzehn Features -- verursachen tendenziell mehr Verwirrung als sie lösen.
Ehrliches Geständnis: Ich ertappe mich immer noch gelegentlich dabei, einen glänzenden neuen MCP-Server zu installieren, weil er nützlich klingt, nur um ihn eine Woche später wieder zu entfernen, wenn ich merke, dass er Latenz hinzufügt, ohne Mehrwert zu liefern. Der Tool-Integrationsdrang ist schwer zu kontrollieren, sobald er einmal aktiviert ist.
Der echte Gewinn von Stufe 4 ist nicht ein einzelnes Tool. Es ist der mentale Wandel von "Claude verarbeitet Text" zu "Claude orchestriert Workflows." Sobald man Claude als Workflow-Hub statt als Textgenerator sieht, beginnt man anders über Automatisierung nachzudenken. Und dieses Denken führt direkt zu Stufe 5.
Stufe 5: Der Skills-Entwickler (Wo Wiederholung stirbt)
Ich will ehrlich sein: Stufe 5 ist die Stufe, mit der ich am längsten gekämpft habe, und es ist auch die, bei der ich die größten nachhaltigen Produktivitätsgewinne erlebt habe. Skills Development in Claude Code ist die Praxis, repetitive Prompt-Workflows in wiederverwendbare Ein-Befehl-Automatisierungen umzuwandeln.
Ein Skill ist in Claude Code-Begriffen im Wesentlichen ein textbasierter Prompt-Workflow. Man kann es sich als Makro vorstellen, nur intelligenter -- es ist ein strukturierter Anweisungssatz, dem Claude bei Aktivierung folgt, einschließlich welcher Kontext gesammelt, welche Schritte ausgeführt und welches Ausgabeformat produziert werden soll.
Hier ein konkretes Beispiel. Bevor ich Skills erstellte, sah mein Code-Review-Workflow so aus: geänderte Dateien laden, meine Review-Kriterien erklären, Claude bitten, auf Sicherheitsprobleme zu prüfen, dann nach Performance-Bedenken fragen, dann nach Muster-Compliance, dann nach Testabdeckungslücken. Sechs separate Prompts, jedes einzelne Mal. Manchmal vergaß ich einen Schritt. Manchmal formulierte ich die Kriterien anders und bekam inkonsistente Ergebnisse.
Mein Code-Review-Skill komprimierte das zu einem einzigen Trigger. Er lädt automatisch den Diff, wendet meine Review-Kriterien in konsistenter Reihenfolge an, prüft gegen meine CLAUDE.md-Konventionen und produziert einen strukturierten Bericht mit Schweregrad-Bewertungen. Gleiche Qualität jedes Mal. Null vergessene Prompts.
Skills bauen, die tatsächlich funktionieren
Das Skill Creator-Tool in Claude Code hilft beim Bootstrappen neuer Skills, aber ich habe festgestellt, dass die besten Skills aus organischer Evolution entstehen statt aus Vorabplanung. Mein Prozess:
Erstens führe ich einen Workflow drei- bis viermal manuell durch und notiere, welche Prompts ich in welcher Reihenfolge verwende. Zweitens identifiziere ich, welche Teile über alle Durchläufe konsistent sind und welche variieren. Drittens baue ich einen Skill, der die konsistenten Teile automatisch abwickelt und die variablen Teile als Parameter akzeptiert.
Meine meistgenutzten Skills derzeit:
Project Bootstrap -- nimmt eine Projektbeschreibung und generiert die Dateistruktur, Konfigurationsdateien, CLAUDE.md-Konventionen und initiale Boilerplate. Spart etwa 45 Minuten pro neuem Projekt.
API Endpoint Builder -- nimmt eine Endpunkt-Spezifikation (Route, Methode, Request/Response-Formate) und generiert den Handler, die Validierung, Fehlerbehandlung, Tests und Dokumentation. Folgt meinen etablierten Mustern präzise, weil der Skill auf meine Architekturkonventionen referenziert.
Deployment Preflight -- durchläuft eine Checkliste von Umgebungsvariablen, Datenbankmigrationen, Dependency-Audits und Security-Scans, bevor ich in die Produktion pushe. Dieser hat drei Probleme gefangen, die zu Produktionsvorfällen geworden wären.
Bug Investigation -- nimmt eine Fehlermeldung oder einen Bug-Report, sammelt relevante Logs und Code-Kontext und produziert eine strukturierte Analyse mit wahrscheinlichen Ursachen, nach Wahrscheinlichkeit geordnet.
Jeder dieser Skills hat etwa eine Stunde zum Bauen und Verfeinern gebraucht. Sie verdienen diese Stunde innerhalb der ersten Nutzungswoche zurück.
Die Skill-Sprawl-Falle
Hier ist die Falle auf Stufe 5, und ich bin direkt hineingetappt: zu viele Skills erstellen.
Auf meinem Höhepunkt hatte ich dreiundzwanzig benutzerdefinierte Skills konfiguriert. Dreiundzwanzig. Einige überlappten in der Funktionalität. Einige waren so spezifisch, dass sie auf genau ein Projekt zutrafen. Ein paar widersprachen sich auf subtile Weise -- mein "schneller API-Endpoint"-Skill verwendete andere Fehlerbehandlungskonventionen als mein "Produktions-API-Endpoint"-Skill, und ich konnte mich nicht erinnern, welcher welcher war.
Claude selbst wurde verwirrt. Wenn ich eine Aufgabe auslöste, die zu mehreren Skills passen konnte, sank die Outputqualität, weil das System versuchte, widersprüchliche Anweisungen in Einklang zu bringen. Es ist das gleiche Prinzip wie die MCP-Überladung in Stufe 4 -- mehr ist nicht besser. Präzise ist besser.
Ich reduzierte auf acht Skills. Acht gut getestete, häufig genutzte, nicht-überlappende Workflows, die etwa 80% meiner repetitiven Aufgaben abdecken. Die restlichen 20% erledige ich mit Ad-hoc-Prompts, und das ist in Ordnung. Nicht alles muss automatisiert werden.
Die Reduktionskriterien, die ich verwende: Wenn ich einen Skill zwei Wochen nicht ausgelöst habe, wird er archiviert. Wenn zwei Skills mehr als 50% ihrer Schritte teilen, werden sie zusammengelegt. Wenn ein Skill Output produziert, den ich regelmäßig bearbeiten muss, wird er umgeschrieben oder gelöscht.
Skills sind der Punkt, an dem Claude Code den Übergang macht von "Tool, das ich benutze" zu "System, das ich gebaut habe." Sie sind personalisiert, meinungsstark und geformt von meinen spezifischen Entwicklungsmustern. Die Skills von jemand anderem würden nicht perfekt für mich funktionieren, und meine würden nicht perfekt für jemand anderen funktionieren. Diese Personalisierung ist der springende Punkt.
Aber selbst mit großartigen Skills ist man immer noch auf eine Claude Code-Instanz beschränkt, die eine Sache gleichzeitig macht. Diese Beschränkung zu durchbrechen, darum geht es bei Stufe 6 -- und ehrlich gesagt ist es die Stufe, an der ich immer noch aktiv arbeite.
Stufe 6: Der Claude Code Orchestrator (Wo es richtig wild wird)
Ich muss vorab ehrlich sein: Stufe 6 ist der Punkt, an dem mein Vertrauen sinkt und meine Begeisterung in gleichem Maße steigt. Das Orchestrieren mehrerer Claude Code-Instanzen gleichzeitig ist die Grenze des Möglichen, und es ist wirklich mächtig -- aber auch wirklich chaotisch. Ich hatte Sitzungen, in denen alles klickte und ich das Gefühl hatte, ein Entwicklungsteam von einem einzigen Terminal aus zu leiten. Ich hatte auch Sitzungen, in denen drei Agents widersprüchliche Änderungen produzierten und ich mehr Zeit mit Mergen verbrachte, als ich alleine zum Programmieren gebraucht hätte.
Das Konzept funktioniert so: Statt einer Claude Code-Instanz, die eine Aufgabe nach der anderen bearbeitet, geht es bei Stufe 6 darum, mehrere Instanzen parallel laufen zu lassen, die jeweils an einem anderen Teil des Projekts arbeiten. Ein Agent kümmert sich um die Backend-API. Ein anderer baut die Frontend-Komponenten. Ein dritter schreibt Tests. Sie arbeiten gleichzeitig, in isolierten Umgebungen, und du koordinierst die Ergebnisse.
Der wichtigste technische Enabler sind Git Worktrees. Falls du damit nicht vertraut bist: Ein Git Worktree ermöglicht es, mehrere Branches desselben Repositorys gleichzeitig in separaten Verzeichnissen auszuchecken. Jedes Verzeichnis ist eine vollständig unabhängige Arbeitskopie. Änderungen in einem Worktree beeinflussen den anderen nicht, bis man sie explizit mergt.
Das passt perfekt zu Multi-Agent-Workflows. Ich erstelle einen Worktree für jeden Agent, weise jedem Agent einen spezifischen Arbeitsbereich zu und lasse sie parallel laufen. Agent A arbeitet an der API in worktree-api/. Agent B arbeitet an der UI in worktree-ui/. Agent C arbeitet an Tests in worktree-tests/. Keine Konflikte während der Entwicklung, weil sie in separaten Verzeichnissen sind. Mergen, wenn fertig.
Mein Orchestrierungs-Workflow (mit allen Ecken und Kanten)
So läuft eine Multi-Agent-Sitzung bei mir tatsächlich ab. Ich verwende ein aktuelles Projekt als Beispiel -- den Bau eines Echtzeit-Dashboards mit WebSocket-Updates.
Schritt 1: Ich erstelle drei Git Worktrees vom main Branch.
git worktree add ../dashboard-api feature/api
git worktree add ../dashboard-ui feature/ui
git worktree add ../dashboard-tests feature/tests
Schritt 2: Ich öffne drei Terminal-Sitzungen, jede auf einen anderen Worktree gerichtet, jede mit einer eigenen Claude Code-Instanz.
Schritt 3: Ich gebe jeder Instanz ein fokussiertes Briefing. Der API-Agent bekommt die WebSocket-Server-Spezifikation, die Datenmodelle und das Event-Schema. Der UI-Agent bekommt die Komponenten-Designs, die WebSocket-Client-Anforderungen und den State-Management-Ansatz. Der Test-Agent bekommt den API-Vertrag und das erwartete Verhalten.
Schritt 4: Ich lasse sie laufen und schaue periodisch vorbei. Das ist der Teil, der sich anfühlt wie Teammanagement. Man schreibt keinen Code -- man reviewt Pläne, beantwortet Fragen und trifft architektonische Entscheidungen über drei parallele Ströme.
Schritt 5: Wenn alle drei fertig sind, merge ich. Hier wird die Realität chaotisch.
Das Merge-Problem (Und warum ich ehrlich darüber bin)
Das Mergen paralleler Agentarbeit ist die größte Herausforderung auf Stufe 6. Selbst bei klarer Scope-Trennung machen Agents Annahmen. Der API-Agent könnte eine Response-Payload anders strukturieren als das, was der UI-Agent erwartet. Der Test-Agent könnte Assertions gegen ein Interface schreiben, das sich während der Entwicklung verschoben hat.
Meine Merge-Erfolgsrate -- also Merges, die null manuelle Konfliktlösung erforderten -- liegt bei etwa 60%. Vier von zehn Mal verbringe ich dreißig Minuten bis eine Stunde damit, Integrationsprobleme zu beheben, die nicht existiert hätten, wenn ein Agent alles sequenziell gemacht hätte.
Lohnt sich die parallele Geschwindigkeit? Für große Features, ja. Das Dashboard-Projekt, das ich oben beschrieben habe, hätte mit einem einzelnen Agent etwa zwölf Stunden gedauert. Der Drei-Agenten-Ansatz war in etwa fünf Stunden Wandzeit fertig, einschließlich einer Stunde Merge-Auflösung. Nettoersparnis von sechs Stunden. Für dieses Projekt ging die Rechnung auf.
Für kleinere Features? Ehrlich gesagt, nein. Der Overhead für das Einrichten von Worktrees, das Schreiben separater Briefings und das Handling von Merges frisst die Zeitersparnis auf. Meine Faustregel: Wenn die Aufgabe mit einem einzelnen Agent weniger als drei Stunden dauern würde, lohnt sich Multi-Agent-Orchestrierung den Koordinationsaufwand nicht.
Sub-Agents und Agent-Teams
Claude Code unterstützt auch Sub-Agents -- das Spawnen eines sekundären Agents aus einer primären Agent-Sitzung heraus für eine Teilaufgabe. Das verursacht weniger Overhead als die volle Worktree-Orchestrierung, ist aber im Umfang begrenzter. Ich nutze Sub-Agents für Aufgaben wie "recherchiere die API dieser Library und komm mit einer Zusammenfassung zurück" oder "generiere die TypeScript Types für dieses JSON-Schema, während ich am Handler weiterarbeite."
Agent-Teams sind der experimentellste Teil von Stufe 6. Das Konzept: mehrere Agents mit definierten Rollen -- ein Planer, ein Coder, ein Reviewer -- die in einer koordinierten Pipeline arbeiten. Ich habe dieses Setup dreimal getestet. Zweimal produzierte es wirklich beeindruckende Ergebnisse, wobei der Reviewer-Agent Probleme fand, die der Coder-Agent übersehen hatte. Einmal produzierte es eine endlose Feedback-Schleife, in der der Reviewer ständig Änderungen forderte und der Coder sie ständig umsetzte -- Tokens verbrennend, ohne zu konvergieren.
Ich erwähne das, weil ich finde, dass Ehrlichkeit wichtig ist: Agent-Teams sind mächtig in der Theorie und unberechenbar in der Praxis. Das Tooling verbessert sich schnell. Aber Stand Anfang 2026 behandle ich Agent-Teams als experimentell. Ich würde sie nicht für Kundenarbeit einsetzen, bei der Vorhersagbarkeit zählt. Für persönliche Projekte, bei denen ich es mir leisten kann zu experimentieren und gelegentlich einen Nachmittag an eine Feedback-Schleife zu verlieren? Auf jeden Fall.
Die Token-Realität
Multi-Agent-Orchestrierung verbrennt Tokens. Schnell. Drei parallel laufende Agents verbrauchen dreimal so viele Tokens wie ein einzelner Agent, offensichtlich, aber die tatsächlichen Kosten sind weniger offensichtlich. Jeder Agent braucht sein eigenes Kontext-Setup, sein eigenes CLAUDE.md-Laden, seine eigene Orientierung im Projekt. Diese duplizierte Kontext-Initialisierung summiert sich.
Ich tracke meinen Token-Verbrauch pro Projekt, und Multi-Agent-Sitzungen kosten typischerweise das 2,5- bis 3-Fache einer Single-Agent-Sitzung für dasselbe Feature. Nicht 1x (der Traum) und nicht 3x (die naive Annahme). Die Einsparungen kommen von geteilten CLAUDE.md-Dateien und fokussierten, kleineren Kontexten pro Agent.
Ob dieses Kosten-Leistungs-Verhältnis aufgeht, hängt vollständig von deiner Zeitökonomie ab. Für Kundenarbeit auf Stundenbasis rechtfertigt die Geschwindigkeitsverbesserung die Tokenkosten problemlos. Für persönliche Projekte mit begrenztem Budget bin ich wählerischer, wann ich mehrere Agents hochfahre.
Die Denkweise, die alle sechs Stufen verbindet
Wenn ich auf meine Progression zurückblicke, sind die technischen Fähigkeiten auf jeder Stufe weniger wichtig als der Denkwandel, der sie ermöglicht. Und es gibt einen einzigen roten Faden durch alle sechs Übergänge: die Verschiebung vom Befehlen zum Zusammenarbeiten.
Auf Stufe 1 befiehlst du Claude, Output zu produzieren. Auf Stufe 2 planst du gemeinsam. Auf Stufe 3 kuratierst du Kontext gemeinsam. Auf Stufe 4 baust du Toolchains gemeinsam. Auf Stufe 5 kodifizierst du Workflows gemeinsam. Auf Stufe 6 orchestrierst du Teams gemeinsam.
Jede Stufe erfordert, dass man ein bisschen mehr Kontrolle abgibt und dem System ein bisschen mehr vertraut -- während man gleichzeitig raffinierter wird in der Art, wie man es steuert. Das ist das Paradoxon. Man leistet gleichzeitig weniger manuelle Arbeit und wendet mehr strategisches Denken an.
Die Entwickler, die ich auf Stufe 1 oder 2 feststecken sehe, stecken fast immer wegen eines Kontrollproblems fest, nicht wegen eines Kompetenzproblems. Sie wollen nicht in Context Engineering investieren, weil es sich wie Overhead anfühlt. Sie wollen keine Tools integrieren, weil sie jeden Schritt verstehen wollen. Sie wollen nicht mehrere Agents laufen lassen, weil sie nicht persönlich jede Zeile Output überprüfen können.
Diese Instinkte sind nicht falsch -- es ist professionelle Disziplin, die einem gut dient, wenn man Code von Hand schreibt. Aber sie werden zu Einschränkungen, wenn sich die Rolle verschiebt von "Person, die Code schreibt" zu "Person, die KI-Systeme orchestriert, die Code schreiben." Die Fähigkeiten sind andere, und die Denkweise muss sich anpassen.
Was sich tatsächlich in meinem Alltag verändert hat
Die praktische Auswirkung des Übergangs von Stufe 1 zu Stufe 6 ist kaum zu überschätzen. Meine Projektlieferzeiten haben sich um etwa 40% verkürzt. Nicht weil jede einzelne Aufgabe 40% schneller geht -- manche sind schneller, manche brauchen gleich lang -- sondern weil die Totzeit zwischen Aufgaben fast verschwunden ist. Kontextwechselkosten sanken, als ich Worktrees einsetzte. Nacharbeit sank, als ich begann, Kontext richtig zu engineeren. Repetitive Aufgaben verschwanden, als ich Skills baute.
Meine CLAUDE.md-Dateien sind zu einigen der wertvollsten Dateien in meinen Projekten geworden. Sie repräsentieren kristallisiertes Architekturwissen -- Entscheidungen, die früher in meinem Kopf lebten, leben jetzt in einer Datei, die jede Claude Code-Sitzung automatisch absorbiert. Neue Teammitglieder (menschlich oder KI) können die CLAUDE.md lesen und sofort die Konventionen des Projekts verstehen.
Die /compact- und /clear-Kommandos sind jetzt reflexartig. Ich führe /compact so aus, wie ich früher Cmd+S gedrückt habe -- häufig, fast unbewusst, als Hygiene-Gewohnheit. Context Rot erlebe ich nicht mehr, weil ich es proaktiv verhindere, statt darauf zu reagieren, nachdem die Qualität abnimmt.
Und meine Beziehung zu Claude Code selbst hat sich verändert. Ich denke nicht mehr daran als Tool. Tools sind Dinge, die man aufnimmt und wieder hinlegt. Claude Code ist eher wie eine Entwicklungsumgebung -- etwas, das man konfiguriert, anpasst und in dem man arbeitet. Die Investition in Anpassung verzinst sich über die Zeit. Jeder Skill, den ich baue, jede CLAUDE.md-Konvention, die ich dokumentiere, jeder MCP-Server, den ich integriere, macht jede zukünftige Sitzung produktiver als die vorherige.
Dieser Zinseszins-Effekt ist der wahre Gewinn des Durchlaufens aller sechs Stufen. Stufe-1-Produktivität ist linear -- man bekommt heraus, was man hineinsteckt, jedes Mal. Stufe-6-Produktivität ist exponentiell -- vergangene Arbeit verstärkt zukünftige Arbeit.
Du bist dran
Ich werde nicht so tun, als sei diese Progression schnell oder einfach. Es hat mich ungefähr vier Monate gekostet, von Stufe 1 zu Stufe 6 zu gelangen, und ich verfeinere meine Orchestrierungsfähigkeiten immer noch wöchentlich. Manche Stufen waren in Tagen geschafft. Stufe 3 dauerte drei Wochen. Stufe 6 ist wohl ein fortlaufender Prozess -- ich glaube nicht, dass irgendjemand Multi-Agent-Orchestrierung bereits vollständig gemeistert hat, weil sich das Tooling schneller weiterentwickelt, als irgendjemand Expertise aufbauen kann.
Aber du musst nicht Stufe 6 erreichen, um massive Verbesserungen zu sehen. Der Übergang von Stufe 1 zu Stufe 3 -- von basalem Prompting zu Context Engineering -- wird dein Claude Code-Erlebnis mehr transformieren als jeder andere Übergang. Wenn du nach dem Lesen dieses Artikels nur eines tust, dann diese drei Dinge in deiner nächsten Sitzung:
Schalte Plan Mode für deine nächste nicht-triviale Aufgabe ein. Beobachte, wie sich das Gespräch verändert, wenn Claude mit dir plant, statt nur auszuführen.
Erstelle eine CLAUDE.md-Datei in deinem Projektstammverzeichnis mit zehn spezifischen Programmierkonventionen. Beobachte, wie Claudes Output sich sofort an deine Muster anpasst.
Führe /compact nach jeder abgeschlossenen Teilaufgabe aus. Achte darauf, ob die nächste Antwort schärfer wirkt als die Antworten am Ende einer langen, nicht komprimierten Sitzung.
Diese drei Änderungen brauchen fünfzehn Minuten zur Umsetzung. Sie werden dir innerhalb der ersten Woche Stunden sparen.
Die Frage ist nicht, ob Claude Code auf Stufe 6 operieren kann. Das kann es -- die Fähigkeit ist bereits vorhanden. Die Frage ist, ob du bereit bist, deinen Workflow mitzuentwickeln. Und von jemandem, der diesen Aufstieg gemacht hat: Die Aussicht von hier oben ist jeden unbequemen Übergang wert.
Lass uns zusammenarbeiten
Du möchtest KI-Systeme aufbauen, Workflows automatisieren oder deine Tech-Infrastruktur skalieren? Ich helfe dir gerne.
- Fiverr (maßgeschneiderte Builds & Integrationen): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (Enterprise-Lösungen): ramlit.com
- ColorPark (Design & Branding): colorpark.io
- xCyberSecurity (Sicherheitsdienste): xcybersecurity.io
