Claude Code ist eine Fertigkeit: Anmerkungen zu Leo Godins These

In seinem Beitrag Claude Code is Great formuliert Leo Godin einen Gedanken, den ich mir und Kolleginnen mindestens einmal pro Woche wiederhole: using LLMs effectively is a skill we all need in 2026. Dem stimme ich rundum zu — und ich glaube, die meisten Online-Debatten über LLMs gehen genau deshalb in die Sackgasse, weil die Leute über die Modelle streiten und nicht über die eigene Fertigkeit, sie zu nutzen. Ich verbringe das letzte anderthalb Jahre als DevOps-Ingenieur mit Claude Code, also möchte ich seine Thesen durchgehen: Wo ich zustimme, wo ich aus meiner Erfahrung ergänze und wo ich vorsichtig widerspreche.

Kontext ist die einzige Fertigkeit, die zählt

Godin nennt es die Goldilocks-Zone: nicht zu viel, nicht zu wenig, genau richtig. Meine Erfahrung deckt sich. In der Praxis habe ich eine Trennung etabliert: Globale Regeln liegen in CLAUDE.md und werden in jeder Sitzung geladen, abrufbares Wissen wohnt in einem getrennten Memory-System mit einem Index, der relevanzbasiert zugezogen wird. Eine harte Grenze dazwischen: universelle Regel — CLAUDE.md; projekt- oder themenspezifisch — Memory. Duplikate sind verboten, weil sie auseinanderdriften.

Warum das funktioniert: Das Modell erinnert sich nicht an das, was nicht im Kontext steht. Jeder Versuch, vorsichtshalber alles reinzukippen, endet damit, dass Claude bei Schritt fünf oder sechs den Faden verliert. Godin hat dafür eine schöne Metapher: dreißig Minuten Kaffee und Käse, bevor du nach Krokus fragst — und der Gesprächspartner wird sich offensichtlich nicht erinnern, welches Cover du meintest. Mit LLMs ist es genauso.

Context management is the difference between success and failure.

Unterschrieben. Ich würde nur präzisieren: Kontextdisziplin ist keine einmalige Anstrengung, sondern laufende Hygiene. Einmal die Woche gehe ich meine CLAUDE.md und den Memory-Index durch und werfe alles raus, was veraltet ist. Ohne diese Routine wird jedes vernünftige System binnen eines Monats zu einem Friedhof von Regeln — die das Modell pflichtschuldig liest und ebenso pflichtschuldig anwendet, am falschen Ort.

Der Orchestrator muss blind sein

Der praktischste Abschnitt ist der, in dem Godin sagt: your job is orchestration, not comprehension. Er baut es in seinen Skill implement-sprint ein; ich baue es in meine Agenten-Teams: Der führende Agent kennt nur den aktuellen Schritt und darf keine Architekturdokumente lesen. Das machen Sub-Agenten, jeweils mit eigenem Kontextfenster.

Aus menschlicher Sicht ist diese Anordnung widersinnig. Ein guter Tech-Lead behält gerade das große Bild im Kopf. Aber ein LLM-Orchestrator ist kein Mensch: Je breiter sein Horizont, desto schneller degradiert er. Ich bin selbst gegen diese Wand gelaufen, noch bevor ich Godin gelesen habe — meine Skills power-plan und self-improve wanderten endlos durch das Projekt, bis ich „lies nur diese zwei Dateien" zur expliziten Regel machte. Der Effekt deckt sich mit seinem: autonomer Abschluss der Aufgabe statt ständiger Themenverlust.

„Beschuldige Prozesse, nicht Menschen oder LLMs"

Godin bietet einen Kniff an: Wenn Claude nach einem Fehlschlag in Selbstvorwürfe abrutscht, lenkt er ihn mit I believe in blaming processes not people or LLMs um. Ich habe es ausprobiert. Es funktioniert. Die Magie liegt nicht im genauen Wortlaut. Die Magie liegt darin, dass du die Aufmerksamkeit des Modells von was ich falsch gemacht habe auf was am Prozess das zugelassen hat verschiebst. Zwei verschiedene Modi des Denkens, und der zweite ist deutlich produktiver.

Ich ergänze einen verwandten Kniff: Wenn eine Sitzung entgleist, bitte Claude, das eigene Log zu analysieren — was geschah, welche Entscheidungen führten in die Sackgasse. Aus der Analyse entsteht dann eine Prozessänderung: eine neue Regel in CLAUDE.md, ein neuer Skill-Zweig, eine neue Checkliste. Ohne diese Schleife sammeln sich keine Verbesserungen an. Ohne sie ist „die LLMs werden dümmer" keine Diagnose des Modells — sondern Diagnose einer Engineering-Praxis, die fehlt.

Framework oder eigenes Gerüst

Godin gibt zu: Er hat Spec Kitty, BMAD, Open Spec probiert — und bleibt bei seinem eigenen Starter. Ich auch. Interessant ist nicht das Ergebnis, sondern die Begründung: Ein externes Framework decreases your learning. Das ist eine seltene und ehrliche Haltung. Eine fertige Hülle beschleunigt deine ersten fünf Aufgaben und bremst dein Wachstum bei den nächsten fünfzig — du verstehst nicht, warum sie funktioniert, und wenn sie kaputtgeht (neues Modell, neues Claude-Code-Release, Backend-Änderung), hast du kein Werkzeug, sie zu reparieren.

Eine Einschränkung allerdings: Eigene Skripte zu schreiben lohnt sich nur, wenn du das Werkzeug täglich benutzt. Für ein einmaliges Skript oder ein Wochenend-Projekt nimm das Fertige. Für stetige Arbeit baue ein leichtes Gerüst und lass es sich entwickeln. Meine /power-plan, /self-improve, /publish-note sind genau das — ein Gerüst, das aus konkreten wiederkehrenden Schmerzen entstanden ist.

Wo ich widerspreche

Godin schreibt: /clear is your friend. /compact is not. Vom Sinn her richtig, aber mit Nuance. /compact ist nicht böse — es ist ein Werkzeug mit schmalem Anwendungsfenster. Wenn du die Sitzung vor der Degradation einfängst (nicht erst, wenn das Modell schon verwirrt ist), funktioniert die Kompaktion: Sie bewahrt den Faden und lässt dich weitermachen. Das Problem ist nicht der Befehl, sondern dass Leute ihn zu spät aufrufen. Das ist ein klassischer Wahrnehmungsfehler: Wir merken erst, dass der Kontext voll ist, wenn das Modell bereits entgleist — und dann gibt es nichts mehr Verdichtenswertes.

Das Fazit

Guter Artikel. Nicht über das Werkzeug — über die Fertigkeit. Genau das ist sein Wert: Er heilt Frustration durch Verantwortung. Wenn es heute nicht funktioniert, ist heute dein Prozess falsch. Schlechte Nachricht und großartige Nachricht zugleich: Ein Prozess ist reparierbar, eine Fertigkeit ist trainierbar, Kontext ist beschneidbar. Darauf zu warten, dass Anthropic „den guten Claude zurückbringt", ist sinnlos — er ist nie verschwunden.

Das Original ist kürzer als meine Besprechung und liest sich leicht: Claude Code is Great. Empfehlenswert.