Der Claude-Code-Workflow, der mein Team überflüssig machte

Der Claude-Code-Workflow, der mein Team überflüssig machte

Vor sechs Wochen beobachtete ich, wie eine Senior Engineerin an einem einzigen Nachmittag ein komplettes Authentifizierungssystem, eine Zahlungsintegration und ein Dashboard-Redesign auslieferte. Keine Prototypen. Keine Wegwerf-Demos. Produktiv-Code mit Tests, Typsicherheit und sauberer Git-Historie. Sie hatte drei Claude-Code-Sitzungen gleichzeitig laufen, jede in ihrem eigenen Worktree, jede zuständig für ein anderes Feature, während sie Pull Requests aus dem vorherigen Batch überprüfte.

Ich fragte sie, wie lange es gedauert habe, diesen Workflow aufzubauen. „Etwa eine Woche gezieltes Üben“, sagte sie. „Aber die eigentliche Antwort ist: Ich habe aufgehört, Claude wie einen Chatbot zu behandeln, und angefangen, ihn wie einen Junior Engineer zu sehen, der Struktur braucht, um seine beste Arbeit zu leisten.“

Diese Sichtweise blieb bei mir hängen. Ich hatte Claude Code zu diesem Zeitpunkt schon seit Monaten genutzt – Projekte ausgeliefert, Agentensysteme gebaut, ständig darüber geschrieben. Aber mein Workflow war immer noch überwiegend reaktiv. Prompt, generieren, prüfen, korrigieren, erneut prompten. Der Zyklus funktionierte, aber er ließ enorme Produktivität ungenutzt.

Dann stieß ich auf Maddys Analyse. Maddy ist Senior Software Engineer und hat bei Google, Amazon, IBM und Microsoft gearbeitet – keine Person, die zu Hype neigt. Ihr Ansatz für Claude Code dreht sich nicht um clevere Prompts oder versteckte Features. Es ist eine vollständige Methodik: neun ineinandergreifende Praktiken, die Claude von einem Code-generierenden Chatbot in etwas verwandeln, das wie ein autonomes Engineering-Team funktioniert. Ich habe den letzten Monat damit verbracht, jedes einzelne Element davon umzusetzen, und die Ergebnisse haben mich gezwungen, meine gesamte Projektstruktur zu überdenken.

Hier ist das System, Stück für Stück, mit allem, was ich gelernt habe, als ich versucht habe, es in der Praxis zum Laufen zu bringen.

Warum die meisten Entwickler mit Claude Code an ihre Grenzen stoßen

In Entwickler-Communities beobachte ich ein Muster, das so konstant ist, dass es fast schon ein Naturgesetz sein könnte. Jemand entdeckt Claude Code. Sie generieren ein paar Komponenten, erleben den Rausch der KI-gestützten Entwicklung und erzählen jedem, dass dies die Zukunft sei. Zwei Wochen später sind sie frustriert. Die Bugs häufen sich. Die KI schlägt Funktionen vor, die es gar nicht gibt. Kontextfenster laufen über und Claude widerspricht seinen eigenen früheren Vorschlägen.

Die Standardreaktion ist, dem Modell die Schuld zu geben. „Es ist nicht schlau genug für echte Projekte“ oder „es funktioniert bei Spielzeugbeispielen, aber nicht bei produktivem Code.“ Beides habe ich selbst schon gesagt.

Das eigentliche Problem ist fast nie das Modell. Es fehlt die Struktur rund um das Modell.

Stellen Sie sich das so vor: Wenn Sie den talentiertesten Junior-Entwickler der Welt einstellen und ihm keinerlei Einarbeitung, keine Coding-Standards, keinen Review-Prozess und keine Test-Suite geben – entsteht Chaos. Nicht, weil es an Können mangelt, sondern weil Können ohne Struktur zu inkonsistenten Ergebnissen führt. Bei Claude Code ist es genauso. Die rohe Intelligenz ist außergewöhnlich. Aber Intelligenz ohne Workflow führt genau zu den Symptomen, über die Entwickler klagen: nicht abgestimmte Implementierungen, wachsende Bug-Zahlen und das schleichende Gefühl, dass man mehr Zeit mit dem Beheben von KI-Ausgaben verbringt, als man für das Schreiben des Codes selbst gebraucht hätte.

Maddys Methodik löst dieses Problem, indem sie Claude Code in genau die Art von Engineering-Disziplin einbettet, die man auch bei einem menschlichen Team anwenden würde. Jeder Schritt existiert, um einen bestimmten Fehlermodus zu verhindern, den ich persönlich erlebt habe. Und der kumulative Effekt – alle neun Praktiken zusammen – sorgt für die „das kann nicht echt sein“-Produktivitätsgewinne, die wie Marketing klingen, bis man sie selbst erlebt.

Der Haken? Sie müssen sie bewusst umsetzen. Schritte zu überspringen mindert nicht nur den Nutzen – es untergräbt das gesamte System. Das habe ich auf die harte Tour gelernt, als ich den Plan-Modus bei „einfachen“ Aufgaben überspringen wollte und am Ende drei Stunden mit dem Debuggen einer Funktion verbrachte, die eigentlich in fünfzehn Minuten fertig sein sollte.

Schritt 1: Erstelle eine CLAUDE.md, die wirklich funktioniert

Jeder strukturierte Claude-Code-Workflow beginnt mit der CLAUDE.md, und Maddys Herangehensweise an diese Datei ist deutlich disziplinierter als das, was ich normalerweise sehe.

Wenn du /init in einem neuen Code-Repository ausführst, analysiert Claude die Struktur und generiert diese Datei automatisch. Sie enthält die Projektbeschreibung, die Dateistruktur, wichtige Pfade, Entwicklungsbefehle, Coding-Konventionen und den Tech-Stack. Die automatisch generierte Version ist ein solides Fundament – deutlich besser, als alles von Grund auf selbst zu schreiben, was ich früher gemacht habe, bevor ich akzeptierte, dass Claudes Selbstanalyse Details erfasst, die mir entgehen würden.

Doch hier weicht Maddy von der üblichen Empfehlung ab: Sie hält die CLAUDE.md zwischen 100 und 200 Zeilen. Nicht 300. Nicht 500. Hundert bis zweihundert.

Diese Einschränkung erschien mir anfangs radikal. Meine eigenen CLAUDE.md-Dateien waren in manchen Projekten auf über 400 Zeilen angewachsen – Architekturentscheidungen, Coding-Patterns, Beispiel-Snippets, historische Kontexte. Es fühlte sich gründlich an. Tatsächlich war es Verschwendung. Jede Zeile in der CLAUDE.md wird bei jedem einzelnen Gespräch geladen. Eine 500-zeilige Datei frisst still und leise einen erheblichen Teil deines Kontextfensters, noch bevor du deinen ersten Prompt geschrieben hast. Ich habe das ausführlich in meinem 50 Claude Code Tipps Guide behandelt, aber kurz gesagt: Aufgeblähte Kontextdateien sind einer der Hauptgründe, warum die Output-Qualität von Claude mitten in der Session nachlässt.

Was in die Datei gehört: Projektbeschreibung und Kernfunktionalität, Dateistruktur und wichtige Pfade, Build-/Test-/Lint-Befehle (damit Claude seine Arbeit selbst validieren kann), Coding-Konventionen und Tech-Stack sowie harte Regeln, die Claude niemals verletzen darf. Was nicht hineingehört: Codebeispiele (Claude kann deinen tatsächlichen Code lesen), ausführliche Erklärungen vergangener Entscheidungen, alles, was dein README dupliziert, und alles, was in den letzten zwei Wochen nicht relevant war.

Die 100-200-Zeilen-Grenze zwingt dich zur Priorisierung. Jede Zeile muss ihren Platz verdienen. Und genau diese kompromisslose Priorisierung macht das Kontextfenster effizient genug, damit der Rest dieses Workflows funktioniert.

Noch etwas, das Maddy betont und das ich mittlerweile konsequent umsetze: Behandle die CLAUDE.md als lebendiges Dokument. Wenn Claude einen Fehler macht und du ihn korrigierst, füge eine Regel hinzu, die diesen Fehler künftig verhindert. Mit der Zeit wird die Datei zu einer destillierten Sammlung aller Lektionen, die dein Projekt der KI beigebracht hat. Boris Cherny, der Schöpfer von Claude Code, macht genau das mit einer lessons.md-Datei – jede Korrektur wird zur dauerhaften Regel. Die Datei bringt sich buchstäblich selbst bei, besser für deine spezifische Codebasis zu werden.

Schritt 2: Planmodus vor jeder Änderung

Dies ist die wirkungsvollste Praxis in Maddys gesamtem Workflow – und zugleich diejenige, die die meisten Entwickler überspringen, weil sie das Gefühl haben, sie würde sie ausbremsen.

Der Planmodus (umschaltbar mit Shift+Tab im CLI) weist Claude an, deinen Codebestand zu analysieren und einen Implementierungsplan zu entwerfen, bevor überhaupt Code geschrieben wird. Claude prüft, welche Dateien geändert werden müssen, welche Logikpfade betroffen sind, wo Risiken bestehen und wie die Änderung in die bestehende Architektur passt. Du erhältst eine klare Aufschlüsselung dessen, was Claude vorhat – und entscheidend ist: Du kannst diesen Plan genehmigen, anpassen oder ablehnen, bevor auch nur eine einzige Codezeile verändert wird.

Die praktische Faustregel, auf die ich mich festgelegt habe: Nutze den Planmodus für jede Aufgabe, die mehr als eine Datei betrifft. Bei Änderungen an nur einer Datei – etwa das Umbenennen einer Variablen, das Korrigieren eines Tippfehlers oder das Hinzufügen eines Kommentars – lasse Claude direkt ausführen. Bei allem Strukturellen gilt: Erst planen.

Warum das in der Praxis so entscheidend ist: Ohne Planmodus schreibt Claude manchmal vollkommen funktionierenden Code – allerdings an völlig falscher Stelle. Ich habe Claude einmal gebeten, eine Ratenbegrenzung für eine API einzubauen, und es hat eine neue Middleware-Datei erstellt, anstatt die bestehende zu erweitern, die bereits die Authentifizierung handhabte. Der Code war korrekt. Die Architektur war falsch. Mir ist das erst drei Features später aufgefallen, als ich bemerkte, dass zwei Middleware-Chains unabhängig voneinander liefen.

Mit Planmodus hätte ich im Plan sofort gesehen: „Neue Datei erstellen: middleware/rateLimiter.js“ – und hätte das direkt zu „Bestehende Datei ändern: middleware/auth.js – Ratenbegrenzungslogik hinzufügen“ korrigiert. Zehn Sekunden Überprüfung haben mir drei Stunden Refactoring erspart.

Der von Maddy empfohlene und für mich inzwischen unverzichtbare Plan-Review-Execute-Zyklus sieht so aus:

1. Aufgabe detailliert beschreiben (je spezifischer, desto besser)
2. Planmodus aktivieren und Claude den Code analysieren lassen
3. Plan überprüfen: Dateipfade korrigieren, Architekturentscheidungen hinterfragen, Einschränkungen ergänzen
4. Plan genehmigen und Claude ausführen lassen
5. Ergebnis mit dem ursprünglichen Plan abgleichen

Manche Entwickler gehen noch einen Schritt weiter. Ich habe Workflows gesehen, in denen eine Claude-Sitzung den Plan entwirft und eine zweite Sitzung ihn „als Senior Engineer“ überprüft, bevor die Ausführung startet. Ich habe das bei einer komplexen Datenbankmigration ausprobiert – und die Review-Sitzung hat zwei Edge Cases entdeckt, die die Planungssitzung übersehen hatte. Für die meisten Aufgaben ist das übertrieben. Für alles, was Produktionsdaten betrifft, ist es unbezahlbar.

Schritt 3: Kontext nach jeder Aufgabe löschen

Das klingt fast zu einfach, um wichtig zu sein. Ist es aber nicht. Es ist vielleicht die am meisten unterschätzte Praxis im gesamten Workflow.

Nach Abschluss jeder einzelnen Aufgabe solltest du /clear ausführen, um das Kontextfenster von Claude zurückzusetzen. Jede Datei, die Claude liest, jede Befehlsausgabe, die er verarbeitet, jede Nachricht im Gespräch – all das sammelt sich in einem gemeinsamen Kontextbudget an. Wenn dieses Budget voll ist, verliert Claude den Überblick über frühere Anweisungen. Die Symptome sind anfangs subtil: etwas weniger präziser Code, gelegentliche Inkonsistenzen mit deinen Coding-Standards, Vorschläge, die nicht ganz zu dem passen, was du angefordert hast. Dann summieren sich die Probleme, bis du plötzlich KI-Ausgaben debuggen musst, die ihren eigenen Vorschlägen von vor zwanzig Minuten widersprechen.

Früher habe ich /clear nur dann verwendet, wenn etwas schiefgelaufen ist. Maddy sieht es als Hygiene – etwas, das man nach jeder erfolgreich erledigten Aufgabe macht, bevor etwas schiefgeht. Der Unterschied liegt zwischen Prävention und Reaktion, und der präventive Ansatz ist deutlich effizienter.

Der Workflow sieht also so aus: Aufgabe abschließen, überprüfen, ob sie funktioniert, committen und dann /clear ausführen, bevor du mit der nächsten Aufgabe beginnst. Reiner Tisch. Das gesamte Kontextbudget steht für das nächste Problem zur Verfügung. Kein angesammeltes Rauschen aus dem vorherigen Gespräch.

Ein praktischer Hinweis: Wenn deine nächste Aufgabe stark vom Kontext der aktuellen abhängt, kannst du die wesentlichen Details in deinem nächsten Prompt mitgeben, anstatt dich darauf zu verlassen, dass Claude sie sich merkt. „Ich habe gerade Rate Limiting zum Auth-Middleware hinzugefügt. Jetzt muss ich entsprechende Tests für das Rate-Limiting-Verhalten schreiben“ gibt Claude genau den Kontext, den er braucht – ohne das Ballast aus der vorherigen Session.

Allein diese Praxis hat etwa 40 % der „Claude verhält sich seltsam“-Momente, die ich früher erlebt habe, eliminiert. Und sie passt perfekt zu Plan-Modus – du startest jede Aufgabe immer mit klarem Kontext und einem durchdachten Plan, statt auf angesammeltem Rauschen aufzubauen.

Schritt 4: Slash-Befehle für wiederkehrende Prompts

Jeder Entwickler hat Prompts, die er immer wieder eintippt. „Überprüfe diesen Code auf Sicherheitslücken.“ „Schreibe Unit-Tests für diese Funktion.“ „Refaktoriere dies nach dem Repository-Pattern.“ Diese immer wieder einzutippen ist nicht nur mühsam – es führt auch zu Variationen. Dein Code-Review-Prompt am Donnerstag wird nicht exakt gleich formuliert sein wie am Montag, und diese Unterschiede führen zu unterschiedlichen (oft schlechteren) Ergebnissen.

Slash-Befehle lösen dieses Problem, indem sie deine besten Prompts in wiederverwendbare Trigger verwandeln. Sie sind Markdown-Dateien, die im Verzeichnis .claude/commands/ (oder .claude/skills/ – seit Anfang 2026 sind diese praktisch vereinheitlicht) gespeichert werden und von Claude ausgeführt werden, sobald du den entsprechenden Slash-Befehl eintippst.

Hier ein praktisches Beispiel. Ich habe einen Befehl namens /security-review, der einen detaillierten Prompt enthält, den ich über Dutzende Iterationen hinweg verfeinert habe:

# Security Review

Überprüfe die aktuellen Änderungen auf Sicherheitslücken. Prüfe auf:

1. SQL-Injection-Vektoren in allen Datenbankabfragen
2. XSS-Schwachstellen in gerenderten Ausgaben
3. Möglichkeiten zur Umgehung von Authentifizierung/Autorisierung
4. Offenlegung sensibler Daten in Logs oder Fehlermeldungen
5. CSRF-Schutz bei zustandsverändernden Endpunkten
6. Lücken bei der Validierung von Benutzereingaben

Für jedes gefundene Problem:
- Schweregrad klassifizieren (Kritisch / Hoch / Mittel / Niedrig)
- Den verwundbaren Code zeigen
- Die behobene Version bereitstellen
- Den Angriffsvektor erklären

Wenn keine Probleme gefunden werden, bestätige, dass der Code die Überprüfung mit einer kurzen Zusammenfassung besteht.

Anstatt mir jedes Mal alle sechs Prüfkategorien merken zu müssen, tippe ich jetzt einfach /security-review ein und erhalte konsistente, gründliche Ergebnisse. Der Prompt ist praxiserprobt. Die Ausgabe ist zuverlässig. Und ich spare die drei Minuten, die ich sonst für das Formulieren der Anweisung aus dem Gedächtnis gebraucht hätte.

Maddy empfiehlt, für jeden Prompt, den du mehr als dreimal getippt hast, einen Slash-Befehl zu erstellen. Ich würde noch weiter gehen – erstelle sie für jeden Prompt, bei dem Konsistenz wichtiger ist als Kreativität. Code-Review, Testgenerierung, Dokumentations-Updates, API-Endpoint-Scaffolding, Planung von Datenbankmigrationen. Das sind Workflows, bei denen du jedes Mal vorhersehbare, hochwertige Ergebnisse willst.

Die Befehle sind einfach Markdown-Dateien und damit versionskontrolliert. Du kannst sie mit deinem Team teilen. Du kannst sie im Laufe der Zeit weiterentwickeln – und jede Verbesserung kommt jedem zukünftigen Aufruf zugute. Ich pflege etwa fünfzehn aktive Slash-Befehle über meine Projekte hinweg. Die drei, die ich am häufigsten nutze, sparen mir wahrscheinlich dreißig Minuten pro Tag.

Schritt 5: Validierungshooks, die Claude zur Selbstkorrektur befähigen

Hier verschiebt sich der Workflow von „strukturiertem Prompting“ zu etwas, das sich tatsächlich wie die Zusammenarbeit mit einem autonomen Entwickler anfühlt.

Validierungshooks sind automatisierte Prüfungen, die nach jeder Änderung, die Claude vornimmt, ausgeführt werden. Das Projekt wird gebaut. Die Testsuite läuft. Der Typechecker wird ausgeführt. Falls etwas fehlschlägt, sieht Claude die Fehlermeldung und versucht automatisch, das Problem zu beheben – ganz ohne dein Eingreifen. Die KI tritt in eine Selbstkorrekturschleife ein: editieren, validieren, Fehler erkennen, beheben, erneut validieren, wiederholen, bis alles erfolgreich ist.

Das ist das Feature, dem Maddy die größte einzelne Qualitätssteigerung in ihrem Workflow zuschreibt. Und Boris Cherny, der Schöpfer von Claude Code, argumentiert, dass ein Feedback-Loop für Claude die finale Output-Qualität um das Zwei- bis Dreifache gegenüber „generate-and-pray“ verbessert.

Das Einrichten von Hooks in deiner Claude-Code-Konfiguration sieht so aus:

{
  "hooks": {
    "postEdit": [
      "npm run build",
      "npm run test",
      "npm run typecheck"
    ]
  }
}

Jedes Mal, wenn Claude eine Datei ändert, werden diese drei Befehle automatisch ausgeführt. Wenn der Build fehlschlägt, sieht Claude den Fehler. Wenn ein Test scheitert, erkennt Claude, welche Assertion nicht bestanden wurde und warum. Wenn der Typechecker einen inkompatiblen Typ findet, sieht Claude die exakte Datei und Zeile.

Die zentrale Erkenntnis: Ohne Hooks überprüft Claude seine Arbeit anhand seines eigenen Urteilsvermögens. Das klingt vernünftig – bis man bedenkt, dass Claudes Urteil nachlässt, je voller der Kontext wird. Tests und Build-Prüfungen sind eine externe Quelle der Wahrheit, die unabhängig vom Kontextdruck zuverlässig bleibt. Jeder Rot-zu-Grün-Zyklus liefert Claude eindeutiges, maschinengeprüftes Feedback, auf das er reagieren kann, ohne auf dich zu warten.

Ich möchte ehrlich über die Grenzen sprechen. Hooks verlängern jeden Editierzyklus. Wenn deine Testsuite 90 Sekunden benötigt, wartest du nach jeder Änderung eben 90 Sekunden. Für schnelle Iterationen an UI-Komponenten, bei denen das Feedback visuell ist, deaktiviere ich Hooks manchmal vorübergehend. Aber bei allem, was Geschäftslogik, API-Endpunkte oder Datenmodelle betrifft – bleiben die Hooks aktiv. Die zusätzliche Zeit ist ein Bruchteil dessen, was sie an Debugging-Zeit einsparen.

Noch eine Nuance, die Maddy betont und die ich in der Praxis bestätigen kann: Hooks sind deterministisch. CLAUDE.md ist eine Empfehlung – Claude hält sich etwa zu 80 % daran. Hooks werden zu 100 % ausgeführt. Wenn etwas nach jeder Änderung ohne Ausnahme passieren muss – Formatierung, Linting, Sicherheitschecks – dann als Hook, nicht als CLAUDE.md-Regel.

Schritt 6: Parallele Sessions und Git Worktrees

Hier wird der Produktivitätsmultiplikator geradezu absurd.

Die meisten Entwickler führen nur eine Claude-Code-Session gleichzeitig aus. Eine Aufgabe, ein Branch, eine sequentielle Pipeline. Maddy hingegen betreibt mehrere Sessions parallel – einige in Terminal-Tabs, andere in IDE-Panels – jede übernimmt eine völlig unabhängige Aufgabe. Das Geheimnis, das dieses Vorgehen ohne Git-Konflikt-Chaos ermöglicht: Jede Session läuft in ihrem eigenen Git Worktree.

Ein Worktree ist ein separates Arbeitsverzeichnis, das mit demselben Repository verknüpft ist. Jeder Worktree hat seinen eigenen ausgecheckten Branch. Änderungen in einem Worktree beeinflussen die anderen nicht. Claude Code unterstützt Worktrees nativ – du kannst mit nur einem Befehl eine Session in einem isolierten Workspace starten.

Der praktische Workflow:

1. Für jedes Feature einen Worktree anlegen: git worktree add ../auth-feature feature/auth
2. In jedem Worktree eine Claude-Code-Session öffnen
3. Jeder Session ihre Aufgabe zuweisen und sie unabhängig arbeiten lassen
4. Nach Abschluss jedes Features reviewen und mergen

Ich betreibe in der Regel drei parallele Sessions. Mehr als das, und der Review-Aufwand frisst den Zeitgewinn schnell wieder auf. Drei ist der Sweet Spot: Jede Session bekommt genug Aufmerksamkeit, ohne dass der Kontextwechsel für mich zum Albtraum wird.

Der mentale Wandel hier ist enorm. Du hörst auf, dich als Entwickler zu sehen, der mit KI-Unterstützung programmiert. Stattdessen denkst du wie ein Engineering Manager, der ein Team aus KI-Entwicklern steuert. Deine Aufgabe ist nicht mehr das Coden – sondern die Planung der Arbeit, die Zuweisung an die richtigen Sessions, das Review der Ergebnisse und das Treffen architektonischer Entscheidungen. Die eigentliche Codegenerierung läuft parallel in mehreren unabhängigen Workstreams.

Wenn du einen vollständigen Deep Dive zum Einrichten von Worktrees mit Claude Code willst – inklusive des subtilen Stolpersteins, dass Commits manchmal auf main landen, obwohl du denkst, sie gehen in einen Feature-Branch – habe ich eine komplette Anleitung geschrieben, die jeden Edge Case abdeckt, auf den ich gestoßen bin.

Falls du lieber möchtest, dass jemand diese Art von Multi-Agent-Entwicklungsumgebung für dein Team aufsetzt, übernehme ich auch Workflow-Automatisierungsprojekte. Was ich bereits gebaut habe, findest du unter fiverr.com/s/EgxYmWD.

Schritt 7: Subagenten für isolierte Teilaufgaben

Parallele Sitzungen kümmern sich um separate Features. Subagenten übernehmen eigenständige Aufgaben innerhalb eines einzelnen Features.

Ein Subagent ist ein leichtgewichtiger, isolierter KI-Agent, der von deiner Haupt-Claude-Sitzung für eine spezifische Teilaufgabe gestartet wird. Das entscheidende Wort ist „isoliert“ – jeder Subagent erhält seinen eigenen System-Prompt, eigene Tool-Berechtigungen und ein eigenes Kontextfenster. Er erledigt seine Aufgabe und berichtet zurück, ohne den Kontext der übergeordneten Sitzung zu verunreinigen.

Claude Code wird mit drei integrierten Subagent-Typen ausgeliefert: Explore (nur Lesezugriff, optimiert für Geschwindigkeit und Kosten), Plan (sammelt Kontext, bevor eine Strategie präsentiert wird) und ein Allzweck-Agent, der Aufgaben übernimmt, die sowohl Exploration als auch Modifikation erfordern.

Die eigentliche Stärke liegt jedoch in benutzerdefinierten Subagenten. Das Beispiel von Maddy, das bei mir Klick gemacht hat: Einen sicherheitsfokussierten Subagenten zu starten, der Code-Änderungen aus einer Security-Perspektive überprüft, während die Hauptsitzung weiter Features entwickelt. Der Security-Agent erhält einen eigenen System-Prompt, der mit OWASP Top 10-Checks und den Sicherheitsrichtlinien deiner Organisation geladen ist. Er arbeitet unabhängig, meldet Probleme und seine Ergebnisse belasten nicht den Kontext der Hauptsitzung.

So setze ich Subagenten in der Praxis ein:

• Security-Review-Agent: Läuft parallel zur Feature-Entwicklung und prüft jede Änderung auf Schwachstellen
• Dokumentations-Agent: Erstellt und aktualisiert Dokumentation, während sich der Code weiterentwickelt – isoliert vom Implementierungskontext
• Test-Generierungs-Agent: Schreibt Testfälle für abgeschlossene Features, während ich mit der Hauptsitzung bereits an der nächsten Aufgabe arbeite

Die Isolierung ist das, was Subagenten grundsätzlich von der bloßen Aufforderung an Claude unterscheidet, im Haupt-Prompt „auch auf Sicherheitsprobleme zu achten“. Dieser Ansatz verbraucht Kontext. Er teilt Claudes Aufmerksamkeit. Und er führt zu oberflächlicher Sicherheitsanalyse, weil das Modell gleichzeitig implementiert und überprüft. Ein dedizierter Subagent konzentriert sich vollständig auf sein zugewiesenes Thema, mit einem System-Prompt, der für genau diese Aufgabe optimiert ist.

Eine Erkenntnis aus meinen Experimenten: Subagenten funktionieren am besten für Aufgaben, die klar vom Haupt-Workflow abtrennbar sind. Wenn die Teilaufgabe viel Hin und Her mit der Hauptsitzung erfordert – „warte, prüfe erst diese Datei, bevor ich weitermache“ – ist sie besser in der Hauptsitzung aufgehoben. Subagenten spielen ihre Stärken aus, wenn man sie einfach losschicken und vergessen kann.

Schritt 8: Skills — Das Wissen deines Teams kodieren

Slash-Commands lösen einzelne Aktionen aus. Skills steuern mehrstufige Workflows.

Der Unterschied ist entscheidend. Ein Slash-Command bedeutet: „Führe diese eine Sache aus.“ Ein Skill hingegen sagt: „Hier ist ein vollständiges Verfahren zur Lösung dieser Problemkategorie, inklusive Entscheidungsbäumen, Sonderfällen und Qualitätskriterien.“ Ich habe diese Architektur ausführlich in meinem Leitfaden zu Agenten-Skills beschrieben, aber kurz gesagt: Skills sind die Methode, um institutionelles Wissen in wiederverwendbare, von KI ausführbare Playbooks zu gießen.

Maddy beschreibt es als den Unterschied zwischen einer Abkürzung und einer Schulung. Beides ist nützlich. Schulung ist das, was sich mit der Zeit auszahlt.

Ein Skill ist eine Markdown-Datei (gespeichert in .claude/skills/), die einen mehrstufigen Workflow enthält. Hier ein gekürztes Beispiel für einen Code-Review-Skill:

# Umfassendes Code Review
---

## Schritt 1: Architektur-Bewertung
- Prüfen, ob die Änderungen mit den bestehenden Mustern im Codebase übereinstimmen
- Überprüfen, ob neue Dateien gemäß den Projektkonventionen in den richtigen Verzeichnissen liegen
- Alle Architekturentscheidungen kennzeichnen, die dokumentiert werden sollten

## Schritt 2: Logiküberprüfung
- Verfolge den Happy Path durch den neuen Code
- Identifiziere nicht abgedeckte Randfälle
- Überprüfe die Vollständigkeit der Fehlerbehandlung

## Schritt 3: Performance-Check
- N+1-Abfrage-Muster identifizieren
- Auf unnötige Re-Renders in React-Komponenten prüfen
- Sicherstellen, dass für neue Abfrage-Muster Datenbankindizes vorhanden sind

## Schritt 4: Sicherheitsscan
- Überprüfung der Eingabevalidierung bei allen vom Benutzer bereitgestellten Daten
- Überprüfung von Authentifizierungs-/Autorisierungsprüfungen
- Überprüfung auf Injektions-Schwachstellen

## Schritt 5: Bewertung der Testabdeckung
- Überprüfen, ob kritische Pfade durch Tests abgedeckt sind
- Sicherstellen, dass für die in Schritt 2 identifizierten Randfälle entsprechende Tests existieren
- Alle nicht getesteten Fehlerbehandlungswege kennzeichnen

## Ausgabeformat
Für jeden Befund:
- **Datei:** [Pfad]
- **Zeile:** [Nummer]
- **Schweregrad:** Kritisch | Hoch | Mittel | Niedrig | Info
- **Befund:** [Beschreibung]
- **Empfehlung:** [konkrete Maßnahme]

Wenn du diese Skill aufrufst, führt Claude nicht einfach nur einen schnellen Scan durch. Es wird ein strukturierter, fünfstufiger Prüfprozess ausgeführt, der Kategorien von Problemen aufdeckt, die einer oberflächlichen Kontrolle entgehen würden. Und da der Skill als versioniertes Markdown vorliegt, profitiert dein gesamtes Team von jeder Verbesserung.

Der von Maddy beschriebene — und von mir selbst erlebte — kumulative Effekt besteht darin, dass Skills das mühsam erworbene Wissen deines Teams im Laufe der Zeit ansammeln. Jeder erkannte Edge Case wird dem entsprechenden Skill hinzugefügt. Jeder Fehler wird zu einer neuen Prüfroutine. Nach sechs Monaten dieser Praxis enthalten deine Skills die destillierte Expertise aus jedem Projekt, an dem du gearbeitet hast. Neue Teammitglieder übernehmen dieses Wissen sofort.

Aktuell pflege ich rund zwanzig Skills über meine Projekte hinweg. Diejenigen, die den größten Mehrwert liefern: Code-Review (fünfstufiger Prozess), API-Endpoint-Scaffolding (generiert Route, Controller, Validierung, Tests und Dokumentation in einem Durchgang), Datenbank-Migrationsplanung (analysiert bestehendes Schema, schlägt Migrationsschritte vor, kennzeichnet Risiken für Datenintegrität) und Deployment-Checkliste (prüft vor jedem Produktions-Release Umgebungsvariablen, Secrets, DNS, SSL und Monitoring).

## Schritt 9: MCP-Server — Claude über deinen Code hinaus erweitern

Das letzte Element in Maddys Workflow verbindet Claude mit dem Rest deiner Entwicklungsumgebung.

MCP (Model Context Protocol) Server sind eigenständige Programme, die Tools und Ressourcen über ein standardisiertes Protokoll für Claude Code bereitstellen. Das Konzept ist einfach: Claude liest bereits Dateien und führt Befehle aus. Mit MCP-Servern kann es außerdem mit GitHub, Slack, Datenbanken, APIs und allen anderen externen Diensten interagieren, auf die dein Workflow angewiesen ist.

[Die praktische Einrichtung ist einfacher als sie klingt](https://alexop.dev/posts/understanding-claude-code-full-stack/). Du fügst MCP-Server mit Scope-Konfiguration hinzu — `user`-Scope für Server, die in allen Projekten verfügbar sind, `local`-Scope für projektspezifische Tools und `project`-Scope (gespeichert in `.mcp.json`) für Tools, die du über Git mit deinem Team teilst.

Eine Sache hat mich überrascht, als ich zum ersten Mal MCP-Server verbunden habe: Claude Code lädt nicht jedes Tool von jedem Server gleichzeitig in den Kontext. Es nutzt eine Tool-Suche, um Tools bei Bedarf zu entdecken, und zieht Schemas nur dann heran, wenn sie wirklich benötigt werden. Dadurch wird der Kontextverbrauch um etwa 95 % reduziert im Vergleich zu Clients, die alle Tool-Definitionen im Voraus laden. Eine clevere Designentscheidung, die den Betrieb mehrerer MCP-Server praktikabel macht, statt durch Kontextgrenzen ausgebremst zu werden.

Die MCP-Server, die ich täglich nutze:

- **GitHub MCP:** Claude kann PR-Kommentare lesen, Issues erstellen, Diffs reviewen und Feedback posten — alles, ohne die Terminal-Session zu verlassen
- **Filesystem MCP:** Erweiterte Dateioperationen über das hinaus, was Claude Code nativ unterstützt
- **Slack MCP:** Benachrichtigungen bei abgeschlossenen Tasks, Fehlermeldungen und Status-Updates direkt in die Projektkanäle

Maddys Punkt zu MCP-Servern hat bei mir einen Nerv getroffen: Sie machen aus Claude mehr als nur einen Coding-Assistenten — sie verwandeln es in etwas, das einem halbautonomen Engineer näherkommt, der in deiner gesamten Entwicklungsumgebung agiert. Wenn Claude ein GitHub-Issue lesen, die Umsetzung planen, den Code schreiben, die Tests ausführen, den PR erstellen und eine Zusammenfassung in Slack posten kann, verschiebt sich der menschliche Engpass vom Coden hin zu den Entscheidungen.

Das ist der richtige Engpass.

## Der Zinseszinseffekt: Warum alle neun Schritte zusammen zählen

Ich will es direkt sagen: Die Umsetzung eines einzelnen Schritts aus diesem Workflow wird dein Claude-Code-Erlebnis verbessern. Allein der Planmodus ist das Lesen wert. Allein Validierungshooks reduzieren deine Debugging-Zeit. Allein Slash-Commands machen deinen täglichen Workflow konsistenter.

Die wirkliche Transformation passiert jedoch, wenn alle neun Schritte als System zusammenarbeiten.

So entsteht der Zinseszinseffekt: `CLAUDE.md` verschafft Claude Projektverständnis. Der Planmodus gibt ihm architektonisches Bewusstsein. `/clear` verhindert Kontextverfall. Slash-Commands sorgen für gleichbleibende Eingabequalität. Validierungshooks bieten automatisierte Feedbackschleifen. Parallele Sessions vervielfachen den Durchsatz. Subagenten liefern spezialisierte, isolierte Analysen. Skills kodifizieren institutionelles Wissen. MCP-Server erweitern die Reichweite über den Code hinaus.

Nimmst du ein Element heraus, funktioniert das System immer noch. Aber es funktioniert wie ein Auto mit plattem Reifen – technisch einsatzfähig, aber deutlich beeinträchtigt. Die Bausteine sind darauf ausgelegt, die Schwächen der jeweils anderen auszugleichen. Der Planmodus fängt architektonische Fehler ab, die `CLAUDE.md` allein nicht verhindern kann. Validierungshooks entdecken Implementierungsfehler, die der Planmodus nicht vorhersehen kann. Kontextbereinigung verhindert die Art von schleichendem Qualitätsverlust, die alles andere mit der Zeit weniger zuverlässig macht.

Mein Workflow nach einem Monat Praxis sieht so aus:

1. Jedes Projekt beginnt mit einer schlanken `CLAUDE.md` (unter 150 Zeilen)
2. Jede Aufgabe startet im Planmodus – Entwurf prüfen und freigeben, bevor ausgeführt wird
3. Validierungshooks fangen Fehler automatisch während der Ausführung ab
4. Kontext nach jeder abgeschlossenen Aufgabe löschen
5. Für jeden wiederkehrenden Workflow Slash-Commands verwenden
6. 2–3 parallele Sessions für unabhängige Features via Worktrees laufen lassen
7. Subagenten für Security-Reviews und Testgenerierung starten
8. Skills für mehrstufige Workflows pflegen, die das Team gemeinsam nutzt
9. MCP-Server für GitHub, Slack und projektspezifische Integrationen anbinden

Die Lernkurve ist real. Die erste Woche bewusster Praxis fühlte sich langsamer an als mein alter Workflow. Ich habe ständig den Planmodus umgeschaltet, Slash-Commands geschrieben, Hooks eingerichtet – Overhead, der zunächst keine sichtbaren Ergebnisse brachte. In der zweiten Woche lief der Overhead automatisch ab. In der dritten Woche habe ich vormittags mehr ausgeliefert als früher an einem ganzen Tag.

## Was ich falsch gemacht habe – und was ich heute anders machen würde

Ich bin ehrlich über die Fehler, die ich bei der Implementierung dieses Workflows gemacht habe, denn sie werden dir Zeit sparen, wenn du neu startest.

**Fehler 1: Alles auf einmal umsetzen.** Ich habe Maddys vollständige Methodik gelesen und versucht, alle neun Praktiken am ersten Tag zu übernehmen. Die kognitive Belastung war enorm. Ich war so sehr auf den Prozess fokussiert, dass ich kaum noch Code geschrieben habe. Besserer Ansatz: Starte mit `CLAUDE.md` + Plan-Modus + `/clear`. Füge Validierungshooks in Woche zwei hinzu. Ergänze Slash-Commands und parallele Sessions in Woche drei. Spare dir Subagenten, Skills und MCP für Woche vier auf.

**Fehler 2: Slash-Commands überkomplizieren.** Meine ersten Slash-Commands waren im Grunde Essays. Dreihundert Wörter Anweisung pro Command. Sie funktionierten, verbrauchten aber enorm viel Kontext. Inzwischen habe ich sie so prägnant wie mein `CLAUDE.md` gehalten – jedes Wort muss seinen Platz verdienen. Ein fokussierter 50-Wörter-Command schlägt fast immer einen ausschweifenden mit 300 Wörtern.

**Fehler 3: Zu viele parallele Sessions laufen lassen.** Ich war begeistert und habe versucht, fünf Sessions gleichzeitig zu betreiben. Der Review-Aufwand hat die Produktivitätsgewinne zunichtegemacht. Drei ist mein Sweet Spot. Zwei, wenn die Aufgaben komplex sind. Fünf war reines Chaos.

**Fehler 4: Kontext nicht löschen.** Alte Gewohnheiten sterben schwer. Ich kam in den Flow, erledigte drei Aufgaben ohne zu löschen, und wunderte mich, warum Claudes Vorschläge immer schlechter wurden. Schließlich habe ich einen physischen Klebezettel an meinen Monitor geheftet: „Hast du /clear gemacht?“ Unelegant. Effektiv.

**Fehler 5: Subagenten für Aufgaben nutzen, die Haupt-Session-Kontext brauchen.** Ich habe versucht, einen Subagenten zu starten, um eine Funktion zu refaktorisieren, die stark von der Unterhaltung in der Hauptsession über Architekturentscheidungen abhing. Der Subagent hatte keinen dieser Kontexte und produzierte ein Refactoring, das allem widersprach, was wir besprochen hatten. Subagenten funktionieren für unabhängige Aufgaben. Für kontextlastige Arbeiten bleib in der Hauptsession.

Keiner dieser Fehler war katastrophal. Aber jeder hat mich Zeit gekostet, die ich nicht hätte verlieren müssen. Der Workflow ist wirklich mächtig – und am mächtigsten, wenn man seine Grenzen respektiert, statt sie zu umgehen.

## Der Wandel in der Wahrnehmung deiner Rolle

Unter allen neun Schritten liegt eine größere Idee, für deren Formulierung ich eine Weile gebraucht habe.

Wenn du diesen Workflow vollständig umsetzt, verändert sich deine Rolle. Du verbringst weniger Zeit mit dem Schreiben von Code und mehr Zeit mit dem Treffen von Entscheidungen. Du planst Architekturen, anstatt sie zu implementieren. Du überprüfst Ergebnisse, anstatt sie selbst zu generieren. Du entwirfst Systeme, anstatt sie einzutippen.

Manche Entwickler empfinden das als unangenehm. Für viele von uns ist das Programmieren ein Teil der Identität. Das Gefühl, etwas Zeile für Zeile aufzubauen — dieser Flow-Zustand, in dem Finger und Gehirn perfekt synchronisiert sind — ist wirklich befriedigend. Das zumindest teilweise aufzugeben, fühlt sich wie ein Verlust an.

So ging es mir in den ersten zwei Wochen auch. Dann wurde mir klar, dass die Entscheidungen, die ich traf — die architektonischen Weichenstellungen, die Priorisierung, die Qualitätsbeurteilungen — schwieriger und wertvoller waren als der Code, den ich früher geschrieben habe. Der Code war Ausführung. Die Entscheidungen waren Strategie. Und Strategie entscheidet letztlich darüber, ob Software erfolgreich ist.

Maddys Framework ersetzt keine Ingenieurskompetenz. Es lenkt sie um. Dein Verständnis von Algorithmen, Datenstrukturen, Design Patterns und Systemarchitektur wird wichtiger, nicht weniger wichtig — denn du bist derjenige, der eine KI steuert, die zwar mit übermenschlicher Geschwindigkeit ausführen kann, aber ohne dich keine strategischen Entscheidungen trifft.

Die Entwickler, die mit diesem Workflow kämpfen, sind diejenigen, die die Tastatur nicht loslassen können. Diejenigen, die aufblühen, sind die, die sich immer mehr Zeit für Architektur und weniger Zeit für Boilerplate gewünscht haben. Genau diesen Tausch bietet dir dieser Workflow.

## Wohin das führt

Ich glaube nicht, dass wir am Ende sind. Die Lücke zwischen dem, was Claude Code heute kann, und dem, was es in zwölf Monaten können wird, ist wahrscheinlich größer, als die meisten Entwickler erwarten.

Das Muster, das ich beobachte: Jede dieser neun Praktiken existiert wegen einer aktuellen Einschränkung. Der Planmodus existiert, weil Claude manchmal korrekten Code an der falschen Stelle schreibt. Validierungshooks gibt es, weil Claude seine eigene Arbeit nicht immer intern überprüfen kann. Kontextbereinigung ist nötig, weil Kontextfenster eine begrenzte Kapazität haben. Subagenten braucht es, weil ein einzelner Kontext nicht alle Anliegen gleichzeitig aufnehmen kann.

Wenn Kontextfenster größer werden, Modelle sich bei der Selbstüberprüfung verbessern und der Werkzeugeinsatz ausgefeilter wird, werden einige dieser Praktiken weniger entscheidend. Der Planmodus könnte überflüssig werden, wenn das architektonische Denken des Modells zuverlässig genug ist, um den expliziten Schritt zu überspringen. Validierungshooks könnten entbehrlich werden, wenn die interne Verifikation des Modells mit der Genauigkeit externer Tests übereinstimmt.

Aber die Meta-Praxis – Strukturen um KI-Fähigkeiten herum aufzubauen – wird nur noch wichtiger. Die Modelle werden besser. Die Ingenieure, die wissen, wie man Workflows um diese Modelle herum gestaltet, werden den größten Nutzen ziehen. Das ist die eigentliche Fähigkeit, die diese Methodik vermittelt: nicht, wie man Claude Code im Speziellen nutzt, sondern wie man KI-gestützte Entwicklung als Disziplin begreift.

Maddys neun Schritte sind der beste Ausgangspunkt, den ich gefunden habe, um diese Disziplin aufzubauen. Beginne mit `CLAUDE.md` und dem Planmodus. Füge jede Woche eine weitere Praxis hinzu. Nach einem Monat hast du einen Workflow, der deinen bisherigen Ansatz wie Fahren mit angezogener Handbremse wirken lässt.

Die Frage, über die es sich heute Abend nachzudenken lohnt, ist nicht, ob sich dieser Workflow lohnt – die Beweise dafür sind überwältigend. Die Frage ist, welche deiner aktuellen Gewohnheiten so bequem sind, dass sie dich davon abhalten, den Wechsel zu vollziehen.

## Häufig gestellte Fragen

### Wie richte ich den Planmodus in Claude Code ein?

Schalte den Planmodus mit `Shift+Tab` in der Claude Code CLI ein, bevor du deine Aufgabe beschreibst. Claude analysiert dann deinen Codebestand und erstellt einen Implementierungsplan zur Überprüfung, bevor irgendein Code geschrieben wird. Nutze den Planmodus für alle Änderungen, die mehr als eine Datei betreffen.

### Was ist der Unterschied zwischen Slash-Befehlen und Skills in Claude Code?

Slash-Befehle sind Einzelaktionen, die als Markdown-Dateien im Verzeichnis `.claude/commands/` gespeichert werden. Skills sind mehrstufige Workflows, die im Verzeichnis `.claude/skills/` abgelegt sind und komplexe Abläufe mit Entscheidungsbäumen und Qualitätskriterien abbilden. Seit 2026 nutzen beide denselben Slash-Command-Mechanismus.

### Wie viele parallele Claude Code-Sitzungen sollte ich ausführen?

Starte mit zwei parallelen Sitzungen und verwende Git Worktrees zur Isolierung. Drei Sitzungen sind für die meisten Entwickler der optimale Wert. Mehr als drei Sitzungen führen in der Regel zu einem Mehraufwand bei der Überprüfung, der die Produktivitätsgewinne durch Parallelisierung wieder aufhebt.

### Verlangsamen Claude Code-Validierungshooks die Entwicklung?

Hooks fügen nach jeder Änderung eine Ausführungszeit hinzu, die deiner Build- und Testdauer entspricht. Bei Projekten mit Test-Suites unter 30 Sekunden ist der Overhead im Vergleich zur eingesparten Debugging-Zeit vernachlässigbar. Bei längeren Test-Suites empfiehlt es sich, nur einen relevanten Teil der Tests als Hooks auszuführen und die vollständige Suite vor Commits laufen zu lassen.

### Welche MCP-Server sollte ich für Claude Code installieren?

Die meisten Entwickler benötigen zwei bis drei MCP-Server: GitHub (für PR- und Issue-Management), eine Filesystem-Erweiterung und einen domänenspezifischen Server. Füge sie über die Scope-Konfiguration hinzu — `user` für globale Verfügbarkeit, `project` für teamübergreifende Tools via `.mcp.json` in deinem Repository.

## Lassen Sie uns zusammenarbeiten

Möchten Sie KI-Systeme entwickeln, Workflows automatisieren oder Ihre technische Infrastruktur skalieren? Ich unterstütze Sie gerne dabei.

* **Fiverr** (individuelle Lösungen & Integrationen): [fiverr.com/s/EgxYmWD](https://www.fiverr.com/s/EgxYmWD)
* **Portfolio**: [mejba.me](https://www.mejba.me)
* **Ramlit Limited** (Enterprise-Lösungen): [ramlit.com](https://www.ramlit.com)
* **ColorPark** (Design & Branding): [colorpark.io](https://www.colorpark.io)
* **xCyberSecurity** (Sicherheitsdienste): [xcybersecurity.io](https://www.xcybersecurity.io)
---