Wie der Erfinder von Claude Code es täglich nutzt

Wie der Erfinder von Claude Code es täglich nutzt

Boris Cherny hat seit November 2025 nicht mehr eine einzige Zeile Code von Hand geschrieben.

Lass das einen Moment sacken. Die Person, die Claude Code gebaut hat — die das Werkzeug entworfen hat, das Hunderttausende von Entwicklern heute täglich nutzen — hat vor über vier Monaten aufgehört, Code per Hand zu tippen. Und sein Output ist nicht gesunken. Er hat sich beschleunigt. Er liefert täglich zwischen 10 und 30 Pull Requests, betreibt bis zu 15 Claude Code-Sessions gleichzeitig in seinem Terminal und Browser, und startet gelegentlich Coding-Sessions von seinem Handy vor dem Schlafengehen, um die fertigen Ergebnisse am nächsten Morgen beim Kaffee zu reviewen.

Als ich das zum ersten Mal in seinem Auftritt bei Lenny's Podcast hörte, war meine Reaktion Skepsis. Dreißig PRs am Tag? Von jemandem, der keinen Code schreibt? Das klingt wie LinkedIn-Angeberei, verkleidet als Produktivitätsguru.

Dann studierte ich seinen tatsächlichen Workflow. Und was mich überraschte, war nicht das Volumen — es war die Einfachheit. Boris' System ist geradezu aggressiv minimal. Keine komplexen Prompt-Bibliotheken. Kein aufwendiges Scaffolding. Keine zwanzigseitigen Instruktionsdateien. Seine gesamte CLAUDE.md-Konfiguration umfasst etwa 100 Zeilen. Ungefähr 2.500 Tokens. Das war's.

Die Lücke zwischen meiner Claude Code-Produktivität und seiner lag nicht an irgendeiner Geheimtechnik, die ich noch nicht entdeckt hatte. Es lag an sechs Prinzipien, die ich ignoriert, überkompliziert oder rückwärts angewandt hatte. Nachdem ich in den letzten zwei Wochen meinen eigenen Workflow nach seinem Ansatz umstrukturiert habe, kann ich sagen — die Ergebnisse sind real. Meine Debugging-Zeit sank um etwa die Hälfte. Meine Sessions produzieren beim ersten Anlauf etwa 3x häufiger verwendbaren Output. Und ich habe endlich diesen frustrierenden Kreislauf durchbrochen, in dem Claude selbstbewusst das Falsche baut, während ich zusehe, zu tief in Sunk-Cost verstrickt, um einzugreifen.

Hier ist die vollständige Aufschlüsselung dessen, was Boris Cherny tatsächlich tut — und wichtiger noch, warum jedes Element mehr bedeutet, als es auf den ersten Blick scheint.

„Langsam vorgehen, um schnell zu sein" — Warum 80 % der Sessions im Plan Mode starten

Dies war das Erste, was meine Arbeitsweise veränderte, und ehrlich gesagt das Prinzip, dem ich am längsten widerstand.

Früher öffnete ich Claude Code und begann sofort zu prompten. Das Feature beschreiben. Dem Code beim Erscheinen zusehen. Mich produktiv fühlen. Nur war ich nicht produktiv — ich war beschäftigt. Es gibt einen entscheidenden Unterschied, und Boris bringt ihn in einer einzigen Beobachtung auf den Punkt: KI löst Probleme schnell, aber nicht unbedingt die richtigen Probleme. Ohne klare Planung wird Claude selbstbewusst in die falsche Richtung sprinten und etwas technisch Beeindruckendes bauen, das das eigentliche Ziel komplett verfehlt.

Boris startet etwa 80 % seiner Sessions im Plan Mode. Falls du damit nicht vertraut bist: Plan Mode (aktiviert durch zweimaliges Drücken von Shift+Tab in Claude Code) weist die KI an, zu denken und zu analysieren, ohne Code zu schreiben oder Befehle auszuführen. Es liest Dateien, stellt Fragen, schlägt Ansätze vor — aber ändert nichts, bis du den Plan explizit genehmigst.

Die spezifische Technik, die Boris verwendet, nennt er den „Interview-Prompt". Bevor überhaupt Code generiert wird, fragt er Claude etwas wie:

Interview me about this. What core problems does this solve?
Who is this for? What does success look like? What should this
NOT do? Summarize it back to me before writing any code.

Dieser Prompt hat meinen gesamten Workflow verändert. Hier ist, warum er mächtiger ist, als er aussieht.

Als ich ihn zum ersten Mal ausprobierte, stellte mir Claude fünf klärende Fragen zu einem Feature, das ich für klar beschrieben hielt. Zwei dieser Fragen deckten Annahmen auf, die ich getroffen hatte und die schlichtweg falsch waren. Eine davon — „Soll dies den bestehenden Benutzerdatensatz ändern oder einen neuen Aktivitätslog-Eintrag erstellen?" — hätte zu einem Datenbankarchitekturfehler geführt, der möglicherweise Stunden gekostet hätte, wenn Claude einfach losgebaut hätte.

Boris teilte ein konkretes Beispiel, das mir im Gedächtnis blieb: ein Bugfix für einen Kunden, bei dem Claude ohne Planung direkt Datenbankwerte modifizierte, statt die UI-Anzeigelogik zu reparieren. Der „Fix" löste technisch das gemeldete Symptom, zerstörte aber drei andere Features, die von diesen Datenbankwerten abhingen. Die Art von Bug, die einen schnellen manuellen Test besteht und dann zwei Tage später in der Produktion explodiert.

Plan Mode hätte es in sechzig Sekunden erkannt. Das Interview hätte zutage gefördert, dass das Problem nur die Anzeige betraf. Claude hätte einen UI-Layer-Fix vorgeschlagen. Keine Datenbankänderungen. Keine Kaskade von Ausfällen.

Ich verwende diesen Interview-First-Ansatz jetzt seit zwei Wochen, und das Muster ist konsistent: etwa 4-5 Minuten Planung sparen 20-40 Minuten Nacharbeit. Die Rechnung ist eindeutig.

Ein Detail, das leicht zu übersehen ist — Plan Mode ist auch deutlich schneller und günstiger pro Interaktion. Da Claude während der Planung keine Tools ausführt, keine Dateien schreibt und keine Befehle startet, kommen die Antworten blitzschnell und verbrauchen weniger Tokens. Du bekommst im Wesentlichen das beste Denken der KI zum Rabattpreis, bevor du dich auf die teure Ausführungsphase einlässt.

Nachdem Claude seinen Plan präsentiert hat, reviewt Boris ihn, bearbeitet ihn manchmal direkt mit Ctrl+G (was den Plan in deinem Texteditor öffnet) und schaltet erst dann in den Auto-Accept-Modus um, damit Claude ausführen kann. In den meisten Fällen, sagt er, macht Claude die Implementierung nach einer guten Planungssession beim ersten Mal richtig. Ein Versuch. Keine Iterationen. Keine „das ist nah dran, aber eigentlich meinte ich..." Korrekturen.

Das allein macht den Planungsaufwand wett. Aber das nächste Prinzip ist es, das die Planung über Sessions hinweg wirksam macht.

Die 100-Zeilen-CLAUDE.md — Warum weniger Kontext mehr bringt

Hier widersprach Boris' Ansatz direkt dem, was ich monatelang getan hatte.

Ich hatte eine CLAUDE.md-Datei, die sich den 500 Zeilen näherte. Detaillierte Architekturdokumentation. Coding Standards mit Beispielen. Historischer Kontext darüber, warum bestimmte Entscheidungen getroffen wurden. Pattern Libraries. Es fühlte sich gründlich an. Professionell. Wie ein ordentliches Engineering-Dokument.

Es fraß auch stillschweigend 30 % meines verfügbaren Kontextfensters bei jeder einzelnen Anfrage. Jedes Mal, wenn ich Claude eine Frage stellte — selbst eine einfache — wurden diese 500 Zeilen zuerst geladen. Tokens verbraucht, bevor die eigentliche Arbeit überhaupt begann.

Boris' CLAUDE.md umfasst etwa 100 Zeilen. Rund 2.500 Tokens. Und sie übertrifft jede aufgeblähte Instruktionsdatei, die ich jemals erstellt habe.

Seine Philosophie ist geradezu zen-artig in ihrer Zurückhaltung: Die Datei sollte nur Regeln enthalten, die wiederkehrende Fehler beheben. Keine Dokumentation. Keine Architekturerklärungen. Keine Coding Standards, die Claude bereits aus seinen Trainingsdaten kennt. Nur Korrekturen. Leitplanken. Die spezifischen Dinge, die Claude in deinem Projekt falsch macht und die es ohne explizite Anweisung nicht wissen würde.

Der Prozess ist reaktiv, nicht proaktiv. Boris und sein Team bei Anthropic folgen einer einfachen Regel: „Jedes Mal, wenn wir sehen, dass Claude etwas falsch macht, fügen wir es zur CLAUDE.md hinzu, damit es sich beim nächsten Mal nicht wiederholt." Die Datei ist in Git eingecheckt, wird im gesamten Team geteilt und mehrmals pro Woche aktualisiert. Aber es wird auch entfernt. Mit verbesserten Modellen werden Regeln, die vor sechs Monaten nötig waren, überflüssig. Claude hat sie selbst gelernt.

Das deckt sich mit etwas, das ich in meinem Leitfaden mit 50 Claude Code-Tipps behandelt habe — deine CLAUDE.md ist entweder deine Superkraft oder dein Flaschenhals, und die Trennlinie ist die Länge. Aber Boris geht weiter als ich. Er empfiehlt nicht nur, sie kurz zu halten. Er empfiehlt, sie zu löschen und von Grund auf neu zu erstellen, wenn sie aufgebläht oder widersprüchlich wird, anstatt zu versuchen, sie chirurgisch aufzuräumen.

Die Begründung: Angesammelte Anweisungen entwickeln im Laufe der Zeit interne Widersprüche. Regel 7 sagt „verwende immer async/await", aber Regel 43 sagt „verwende Callbacks für Datenbankoperationen." Ein Mensch, der die Datei liest, würde den Konflikt vielleicht bemerken. Claude vielleicht nicht — oder schlimmer, es versucht vielleicht, beide gleichzeitig zu erfüllen, und produziert bizarren Hybrid-Code.

Neu anfangen eliminiert die Widersprüche, die doppelten Anweisungen und die Regeln, die für Modellfähigkeiten geschrieben wurden, die nicht mehr zutreffen. Es ist der Marie-Kondo-Ansatz der KI-Konfiguration: Wenn eine Regel kein aktuell aktives Problem behebt, gehört sie nicht in die Datei.

Ich habe das letzte Woche ausprobiert. Meine 500-Zeilen-CLAUDE.md gelöscht und nur mit den Regeln von Grund auf neu aufgebaut, die ich aus den letzten zwei Wochen Nutzung rechtfertigen konnte. Ergebnis: 87 Zeilen. Mein Token-Verbrauch sank merklich, und — hier ist der Teil, den ich nicht erwartet hatte — Claudes Code-Qualität verbesserte sich tatsächlich. Weniger widersprüchlicher Kontext bedeutete kohärenteren Output.

Es gibt ein strukturelles Detail, das erwähnenswert ist. Boris nutzt die CLAUDE.md-Hierarchie: eine Datei auf Root-Ebene für projektweite Regeln und Dateien auf Verzeichnisebene für subsystemspezifischen Kontext. Dein /api-Verzeichnis bekommt seine eigenen fokussierten Regeln, ohne die Root-Datei aufzublähen. Das ist etwas, das ich selbst intensiv nutze, und es skaliert hervorragend bei Monorepos.

Wenn du dort sitzt mit einer CLAUDE.md, die über 200 Zeilen hinausgewachsen ist, empfehle ich nachdrücklich Boris' Nuklear-Option. Lösche sie. Baue sie nur aus aktuellen Schmerzpunkten neu auf. Die Datei, die dabei herauskommt, wird kleiner und besser sein.

Verifizierungsschleifen — Der 2-3x Qualitätsmultiplikator, den niemand nutzt

Dies ist das Prinzip, bei dem ich mich, ehrlich gesagt, ein wenig albern fühlte, es nicht früher implementiert zu haben.

Boris' Behauptung ist konkret: Claude die Möglichkeit zu geben, seine eigene Arbeit zu verifizieren, verbessert die Outputqualität um das 2-3-Fache. Nicht „etwas besser." Nicht „etwas zuverlässiger." Zwei- bis dreimal besser. Und nach der Implementierung seines Ansatzes glaube ich, dass die Zahl stimmt.

Das Konzept ist simpel. Die meisten verwenden Claude Code in einem Generieren-und-Reviewen-Zyklus: Claude schreibt Code, du liest ihn, du entdeckst Probleme, du bittest um Korrekturen. Das funktioniert, aber es legt die gesamte Qualitätslast auf dich. Du bist die Verifizierungsschicht. Und du bist ein Mensch, was bedeutet, dass du Dinge übersiehst — besonders in langen Sessions, wenn die Aufmerksamkeit nachlässt.

Boris' Ansatz dreht das um. Er gibt Claude die Tools und Anweisungen, seinen eigenen Output zu prüfen, bevor er als fertig präsentiert wird. Zwei Schritte:

1. Gib Claude eine Methode, seine Arbeit zu verifizieren (eine Testsuite, eine Browser-Vorschau, einen Linting-Befehl, einen Type-Checker)
2. Teile Claude explizit diese Methode mit (in CLAUDE.md oder im Prompt)

Die praktische Implementierung unterscheidet sich je nachdem, was du baust. Für eine Webanwendung könnte es bedeuten, Claude zu sagen: „Führe nach Änderungen die Testsuite aus und öffne den Browser, um visuell zu bestätigen, dass die UI der Anforderung entspricht." Für einen API-Endpoint: „Führe nach der Implementierung den Integrationstest aus und bestätige, dass die Response-Struktur dem Schema entspricht." Für Content-Generierung: „Prüfe nach dem Schreiben gegen das Markenrichtlinien-Dokument unter /docs/style-guide.md."

Boris geht noch einen Schritt weiter — er fügt Verifizierungsprompts direkt in seine CLAUDE.md-Datei ein. Etwa so:

Before marking any task as complete, propose a verification plan.
Describe what you'll check and how you'll confirm correctness.
Then execute that plan.

Diese eine Regel, zu deiner Instruktionsdatei hinzugefügt, zwingt Claude, über Verifizierung nachzudenken, bevor es mit dem Bauen beginnt. Und sie verändert den Output dramatisch. Claude beginnt, Testfälle vorzuschlagen, an die du nicht gedacht hattest. Es fängt Edge Cases während der Implementierung statt danach. Es führt Type-Checks und Linter proaktiv aus, anstatt darauf zu warten, dass du danach fragst.

Ich habe diese Regel vor acht Tagen in meine eigene CLAUDE.md aufgenommen. In dieser Zeit hatte ich genau zwei Fälle, in denen Claude Code mit einem Bug einreichte, den ich beim Review nicht bemerkte. In den acht Tagen vor dem Hinzufügen der Regel lag die Zahl eher bei neun oder zehn. Kleine Stichprobe, sicher. Aber der Richtungswechsel ist unverkennbar.

Die zentrale Erkenntnis: Claude fehlt nicht die Fähigkeit zu verifizieren — es fehlt die Anweisung zu verifizieren. Sich selbst überlassen, optimiert Claude auf Geschwindigkeit und Abschluss. Es will dir eine Antwort geben. Verifizierung verlangsamt das, also überspringt es sie, sofern du sie nicht explizit in den Workflow einbaust. Boris' geniale Einsicht ist zu erkennen, dass eine Zeile in CLAUDE.md eine Fähigkeit freischaltet, die immer da war, aber schlummerte.

Das verbindet sich mit etwas Breiterem darüber, wie ich über Claude Code Agent Skills denke — die besten Konfigurationen fügen der KI keine neuen Fähigkeiten hinzu. Sie aktivieren Fähigkeiten, die die KI bereits hat, aber standardmäßig nicht nutzt. Verifizierung ist das wirkungsvollste Beispiel dieses Musters.

Multipliziere dich selbst — Parallele Sessions, die tatsächlich funktionieren

Boris betreibt 5 Claude Code-Instanzen lokal in seinem Terminal und weitere 5-10 auf der Website von Anthropic. Gleichzeitig. An verschiedenen Aufgaben.

Als ich das zum ersten Mal hörte, war meine Reaktion: „Das klingt chaotisch." Mehrere KI-Sessions, die auf derselben Codebase arbeiten? Das ist ein Rezept für Merge-Konflikte, widersprüchliche Änderungen und Code, der sich nicht integrieren lässt.

Nur dass Boris sie nicht an derselben Aufgabe arbeiten lässt. Jede Session bekommt ein eigenständiges, unabhängiges Stück Arbeit. Eine baut vielleicht einen neuen API-Endpoint. Eine andere schreibt Tests für ein bestehendes Feature. Eine dritte refactored ein Utility-Modul. Eine vierte untersucht einen Bug-Report. Sie überlappen nie. Sie berühren nie dieselben Dateien. Sie laufen parallel, weil sie es können — die Arbeit ist natürlich aufgeteilt.

Der Trick, der das auf praktischer Ebene funktionieren lässt: Jede lokale Session verwendet ihren eigenen Git-Checkout statt Branches oder Worktrees innerhalb desselben Repositorys. Das eliminiert Dateisystem-Konflikte vollständig. Jede Claude-Instanz denkt, sie arbeitet an einem eigenständigen Projekt. Keine Lock-Dateien, die gegeneinander kämpfen. Keine halbfertigen Änderungen in gemeinsam genutzten Verzeichnissen.

Für Remote-Sessions startet Boris sie mit & über die CLI und verwendet manchmal --teleport, um Sessions zwischen seinem Terminal und der Browser-Oberfläche hin und her zu verschieben. Er startet eine Session vor dem Schlafengehen, und sie wartet mit einem fertigen Pull Request, wenn er am Morgen nachschaut.

Ich bin auf drei parallele Sessions hochskaliert — meine Hardware und Aufmerksamkeitsspanne sind noch nicht ganz auf Boris-Level — und selbst in diesem bescheidenen Umfang ist der Produktivitätsunterschied signifikant. Drei unabhängige Aufgaben, die mich jeweils 45 Minuten in Serie kosten würden, sind in insgesamt etwa 50-55 Minuten erledigt. Keine perfekte Parallelisierung, aber nah genug dran, dass es grundlegend verändert, wie ich meinen Arbeitstag plane.

Es gibt einen subtileren Vorteil, den Boris erwähnt und den ich aus Erfahrung bestätigen kann: Frische Sessions bringen frische Perspektiven. Wenn du tief in einer Session steckst, die seit 30 Minuten an einem Problem arbeitet, ist das Kontextfenster voll mit den Annahmen und gescheiterten Ansätzen dieses Problems. Eine zweite Session zum selben Issue zu starten — aber von Null — produziert manchmal in unter fünf Minuten eine bessere Lösung, weil sie nicht den Ballast vorheriger Versuche mit sich trägt.

Ich mache das jetzt routinemäßig bei hartnäckigen Bugs. Wenn meine erste Session es in 15 Minuten nicht gelöst hat, öffne ich eine frische Session mit einer sauberen Problembeschreibung. Die frische Session löst es etwa in der Hälfte der Fälle. Nicht weil sie schlauer ist — weil sie unbelastet ist.

Für alle, die sich für den Git-Worktree-Ansatz bei parallelen Claude-Sessions interessieren, habe ich darüber ausführlicher in meinem Claude Code Git Worktrees Parallele Agents Guide geschrieben. Die Kurzversion: Worktrees geben dir isolierte Arbeitsverzeichnisse aus einem einzelnen Repository, was etwas effizienter ist als vollständige Klone, aber dasselbe Ziel erreicht, das Boris beschreibt.

Innere Schleifen systematisieren — Slash Commands als Muskelgedächtnis

Hier verschiebt sich Boris' Workflow von „produktives Individuum" zu „Produktionssystem."

Jeder Entwickler hat innere Schleifen — die Aufgaben, die man mehrmals täglich wiederholt. Tests ausführen. Boilerplate generieren. Pull Requests erstellen. Code Reviews formatieren. Commit-Nachrichten schreiben. Dokumentation aktualisieren. Diese Aufgaben sind einzeln nicht komplex, aber sie summieren sich. Wenn du 3 Minuten für jede brauchst und zwanzig davon am Tag machst, ist das eine Stunde repetitiver Arbeit.

Boris automatisiert diese mit Claude Code Slash Commands und Skills. Nicht gelegentlich. Obsessiv. Jeder Workflow, den er mehr als zweimal ausführt, wird zu einem Command.

Die Analogie, die er verwendet, ist perfekt: Reguläre Prompts sind wie einem Basketballspieler zu sagen „dribble den Ball über das Feld, such einen freien Mitspieler und pass, wenn du einen siehst." Slash Commands sind bestimmte Spielzüge — präzise Abläufe, die jedes Mal gleich ausgeführt werden. „Pick and Roll von der linken Seite." Keine Mehrdeutigkeit. Keine Variation. Nur Ausführung.

In Claude Code leben Slash Commands in .claude/commands/ als Markdown-Dateien. Jede Datei beschreibt einen bestimmten Workflow. Wenn du /mein-command tippst, liest Claude die Datei und führt den Workflow aus. Kein Neuerklären. Kein „hier ist, was ich brauche, dass du tust..."-Vorspiel. Nur der Auslöser und das Ergebnis.

Boris' eigentlicher Power Move ist, Claude selbst fragen zu lassen, welche Commands er erstellen sollte:

Based on this project, what Claude skills should I create?
Look at my recent git history, my CLAUDE.md, and the types
of changes I make most frequently. Suggest 5-7 slash commands
that would automate my most common workflows.

Ich führte diesen Prompt bei einem meiner Projekte aus und Claude schlug sieben Commands vor. Fünf davon waren Workflows, die ich jeden Tag manuell ausführte. Zwei waren Workflows, an deren Automatisierung ich nicht einmal gedacht hatte, weil sie mehrere Schritte über verschiedene Tools umfassten. Ich baute alle sieben, und die Zeitersparnis summiert sich täglich.

Der entscheidende Unterschied zwischen einem Slash Command und einem gespeicherten Prompt ist Beständigkeit. Prompts leben in deiner Zwischenablage oder einer Notizdatei. Sie gehen verloren, werden inkonsistent bearbeitet und vergessen. Slash Commands leben in deinem Repository. Sie sind versioniert. Sie werden mit deinem Team über Git geteilt. Wenn du einen Workflow verbesserst, bekommt jeder die Verbesserung beim nächsten git pull.

Skills gehen noch einen Schritt weiter — sie sind nicht nur Commands, die du auslöst, sondern Fähigkeiten, die Claude autonom während des Denkprozesses aufrufen kann. Ein Skill mit dem richtigen YAML-Frontmatter aktiviert sich automatisch, wenn Claude auf eine relevante Situation stößt. „Wenn der Benutzer nach einem Statusbericht fragt, verwende diesen Workflow." „Wenn du einen API-Endpoint generierst, folge dieser Vorlage." Es ist der Unterschied zwischen einem Kochbuch und einem Koch, der alle Rezepte bereits kennt.

Für einen tieferen Einblick in das Erstellen effektiver Claude Skills behandelt mein Claude Skills Guide die YAML-Struktur, die fünf Muster, die wirklich wichtig sind, und die Fehler, die ich in meiner ersten Woche des Bauens gemacht habe. Boris' Ansatz bestätigt, was ich unabhängig festgestellt habe: Beginne mit den Workflows, die du am häufigsten wiederholst, automatisiere diese zuerst und lass die Komplexität organisch wachsen.

Für die Zukunft bauen — Die bittere Lektion, angewandt auf deinen Workflow

Dies ist das Prinzip, das alles zusammenbindet, und es ist das philosophischste von Boris' sechs Strategien. Aber überspringe es nicht — es ist dasjenige, das dich vor einer Falle bewahrt, in die ich Dutzende von Entwicklern habe tappen sehen.

Boris verweist auf Rich Suttons berühmten Essay von 2019, „The Bitter Lesson", der argumentiert, dass in der Geschichte der KI-Forschung allgemeine Methoden, die Rechenleistung nutzen, stets Ansätze übertroffen haben, die auf menschlich entwickeltem, domänenspezifischem Wissen basieren. Jedes Mal, wenn Forscher versuchten, Intelligenz von Hand zu codieren — Schacheröffnungsbücher, Spracherkennungsregeln, Übersetzungsgrammatiken — wurden sie schließlich von Systemen geschlagen, die einfach aus riesigen Datenmengen lernten.

Boris wendet dies auf Claude Code-Workflows an: Überengineere deine Prompts oder dein Scaffolding nicht. Das Modell wird schnell besser. Die aufwändige Prompt-Kette, an der du drei Tage gearbeitet hast? In sechs Monaten wird eine einfache Einzeiler-Anweisung bessere Ergebnisse liefern, weil das Modell sich so stark verbessert hat.

Ich habe das selbst erlebt. Techniken, die ich Anfang 2025 dokumentierte, um Claude sauberes TypeScript produzieren zu lassen — spezifische Formatierungsanweisungen, Beispielmuster, explizite Typ-Annotationen im Prompt — sind jetzt überflüssig. Claude generiert standardmäßig sauberes TypeScript. Die Stunden, die ich für diese Prompts aufgewendet habe, waren verschwendete Mühe, investiert in Infrastruktur, die Modellverbesserungen überflüssig machten.

Boris' praktischer Rat: Konzentriere dich darauf, dem Modell hochwertige Daten und Kontext zu liefern, anstatt Prompt Engineering zu optimieren. Deine Zeit ist besser in eine gut strukturierte Codebase mit klaren Namenskonventionen, umfassenden Tests und guter Dokumentation investiert als in die Perfektionierung des siebzehnstufigen Mega-Prompts, der Claude zwingt, Code so zu schreiben, wie du es willst. Denn Claude wird lernen, Code so zu schreiben, wie du es willst. Deine Aufgabe ist es, sicherzustellen, dass es den richtigen Kontext hat — nicht die richtigen Einschränkungen.

Das verbindet sich zurück mit der minimalen CLAUDE.md-Philosophie. Eine 500-Zeilen-Instruktionsdatei ist Overengineering für die Limitierungen des aktuellen Modells. Eine 100-Zeilen-Datei, die auf projektspezifische Korrekturen fokussiert ist, bleibt relevant, selbst wenn das Modell besser wird, weil sie Claude Dinge beibringt, die es genuinerweise nicht wissen kann, ohne dass man es ihm sagt — die Konventionen deines Teams, die Eigenheiten deines Projekts, die spezifischen Anforderungen deiner Geschäftsdomäne.

Boris formuliert es als Frage, wo man seine marginale Stunde investiert. Du könntest sie verwenden für:

• Option A: Einen Prompt verfeinern, bis Claude im Moment etwas besseren Code generiert
• Option B: Deine Codebase, deine Testabdeckung oder deine CLAUDE.md mit einer Korrektur verbessern, die sich über Monate auszahlt

Option B gewinnt jedes Mal. Und sie gewinnt mit einem größeren Vorsprung bei jedem Modell-Update, denn je besser das Modell wird, desto weniger zählt Prompt Engineering und desto mehr zählt Kontextqualität.

Ich habe meinen eigenen Ansatz entsprechend umstrukturiert. Wenn ich mich dabei ertappe, zum dritten Mal an einem Prompt zu feilen, stoppe ich und frage: „Ist das ein Prompt-Problem oder ein Kontext-Problem?" Fast immer ist es Kontext. Die Codebase ist mehrdeutig. Die Testsuite deckt den Edge Case nicht ab. Der CLAUDE.md fehlt eine wichtige Projektkonvention. Behebe den Kontext, und der Prompt kann einfach bleiben.

Was sich in meinem eigenen Workflow verändert hat

Nach zwei Wochen der Implementierung von Boris' sechs Prinzipien hat sich Folgendes verschoben.

Meine Sessions sind kürzer. Nicht weil ich weniger mache — weil die Planungsphase die Fehlstarts eliminiert, die vorher 30-40 % meiner Sessionzeit verschlangen. Ich verbrachte früher 90 Minuten an einem Feature, wovon 30 Minuten aus „nein, das meinte ich nicht, lass mich es neu erklären" bestanden. Jetzt fängt der Interview-Prompt die Fehlanpassung in den ersten fünf Minuten.

Meine CLAUDE.md hat 87 Zeilen. Runter von fast 500. Und meine Outputqualität ist gestiegen, nicht gesunken. Weniger Anweisungen, weniger Verwirrung, kohärenterer Code. Ich überprüfe sie wöchentlich und stelle mir zwei Fragen: „Hat Claude diesen Fehler kürzlich gemacht?" und „Würde Claude diesen Fehler ohne diese Regel machen?" Wenn die Antwort auf eine der beiden Fragen nein ist, wird die Regel gelöscht.

Ich betreibe täglich drei parallele Sessions. Eine für das Hauptfeature, das ich baue. Eine für Tests und Dokumentation. Eine für Bug-Untersuchung oder Refactoring. Sie stören sich nicht gegenseitig. Sie teilen keinen Kontext. Und der kombinierte Durchsatz liegt bei etwa dem 2,5-Fachen dessen, was ich seriell schaffte.

Jeder Workflow, den ich dreimal wiederholt habe, ist jetzt ein Slash Command. Ich habe vierzehn davon über meine Hauptprojekte. Die Zeitersparnis fühlt sich einzeln klein an — vielleicht 2-3 Minuten pro Stück — aber bei zwanzig Aufrufen pro Tag ist das fast eine Stunde zurückgewonnen. Eine Stunde, die ich für Arbeit verwende, die tatsächlich Urteilsvermögen erfordert, nicht Ausführung.

Und ich habe aufgehört, Prompts zu optimieren. Wenn Claude schlechten Output produziert, verbessere ich den Kontext: CLAUDE.md aktualisieren, Codebase verbessern, einen fehlenden Test hinzufügen. Ich habe seit zehn Tagen keinen „besseren Prompt" geschrieben. Ich habe besseren Code geschrieben. Und der KI-Output hat sich als Ergebnis verbessert.

Die unbequeme Implikation

Es gibt etwas in Boris' Ansatz, bei dem es sich lohnt, innezuhalten — etwas, um das die meisten Claude Code-Content-Creator (ich eingeschlossen) herumtanzen.

Die sechs Prinzipien oben sind nicht komplex. Plane, bevor du baust. Halte Anweisungen minimal. Lass die KI ihre eigene Arbeit verifizieren. Führe Aufgaben parallel aus. Automatisiere repetitive Workflows. Rechne damit, dass das Modell besser wird.

Nichts davon erfordert technische Raffinesse. Ein Junior-Entwickler kann alle sechs am ersten Tag implementieren. Die Barriere ist nicht Wissen — es ist Ego. Planen fühlt sich langsam an, wenn man bauen will. Die sorgfältig erstellte 500-Zeilen-CLAUDE.md zu löschen, fühlt sich an, als würde man Arbeit wegwerfen. Claude zu vertrauen, seinen eigenen Output zu verifizieren, fühlt sich an wie Kontrollverlust. Parallele Sessions zu betreiben, fühlt sich an, als würde man den Faden verlieren.

Boris' Ergebnisse legen nahe, dass die Entwickler, die mit KI-gestützter Programmierung erfolgreich sein werden, nicht diejenigen mit den cleversten Prompts sind. Es sind diejenigen, die bereit sind zu verändern, wie sie über die Arbeit selbst denken. KI nicht als schnellere Schreibmaschine zu behandeln, sondern als Kollaborateur, der klare Richtung, sauberen Kontext und die Autonomie braucht, seine eigene Arbeit zu überprüfen.

Die Person, die das Tool gebaut hat, sagt uns genau, wie wir es nutzen sollen. Und sein Rat ist nicht „nutze mehr Features" oder „schreibe bessere Prompts." Sein Rat ist: Plane mehr, konfiguriere weniger, verifiziere alles, und vertraue darauf, dass das Tool immer besser wird.

Ich bin seit zwei Wochen mit diesem Ansatz unterwegs. Mein Output ist gestiegen. Meine Frustration ist gesunken. Und zum ersten Mal, seit ich Claude Code nutze, habe ich das Gefühl, mit dem Tool zu arbeiten, statt es in die Unterwerfung zu ringen.

Wenn du heute eine Sache aus diesem Artikel ausprobierst, mach es den Interview-Prompt. Öffne deine nächste Claude Code-Session im Plan Mode und füge dies ein, bevor du irgendetwas anderes tust:

Interview me about this. What core problems does this solve?
Who is this for? What does success look like? What should this
NOT do? Summarize it back to me before writing any code.

Beantworte Claudes Fragen ehrlich. Schau zu, wie es deine Absicht zurückspiegelt. Fang die Fehlanpassung bevor eine einzige Codezeile existiert. Und dann sag mir, dass sich die fünf Minuten nicht gelohnt haben.

Häufig gestellte Fragen

Wer ist Boris Cherny und welche Rolle hat er bei Anthropic?

Boris Cherny ist der Schöpfer und Leiter von Claude Code bei Anthropic. Er hat den ursprünglichen terminalbasierten Prototyp gebaut und leitet nun das Team, das es weiterentwickelt. Er liefert täglich 10-30 Pull Requests, ohne manuell Code zu schreiben, und nutzt sein eigenes Tool für die gesamte Entwicklungsarbeit. Für Kontext zum Tool selbst, siehe mein Claude Code Tutorial für Einsteiger.

Wie aktiviere ich Plan Mode in Claude Code?

Drücke zweimal Shift+Tab im Claude Code-Terminal, um den Plan Mode zu aktivieren. Claude wird dann Dateien analysieren und Ansätze vorschlagen, ohne Code zu schreiben oder Befehle auszuführen. Du kannst auch den /plan-Befehl in Claude Code v2.1.0 oder höher verwenden. Siehe „Langsam vorgehen, um schnell zu sein" oben für den vollständigen Workflow.

Wie lang sollte meine CLAUDE.md-Datei sein?

Boris Cherny hält sie bei etwa 100 Zeilen (ca. 2.500 Tokens). Die Datei sollte nur Regeln enthalten, die wiederkehrende Fehler beheben — keine Dokumentation, Architekturerklärungen oder Coding Standards, die Claude bereits kennt. Lösche Regeln, die in den letzten zwei Wochen nicht relevant waren. Für eine vollständige Aufschlüsselung, siehe meinen Leitfaden mit 50 Claude Code-Tipps.

Kann ich mehrere Claude Code-Sessions gleichzeitig betreiben?

Ja. Boris betreibt 5 Sessions lokal und 5-10 im Browser gleichzeitig. Der Schlüssel ist, jeder Session unabhängige Arbeit auf separaten Git-Checkouts zuzuweisen, um Dateikonflikte zu vermeiden. Starte Remote-Sessions mit & über die CLI und nutze --teleport, um Sessions zwischen Terminal und Browser zu verschieben.

Was sind Claude Code Slash Commands und wie erstelle ich sie?

Slash Commands sind wiederverwendbare Workflow-Vorlagen, gespeichert als Markdown-Dateien in .claude/commands/. Tippe /command-name, um sie auszulösen. Erstelle eines, indem du eine Markdown-Datei schreibst, die die Workflow-Schritte beschreibt, und speichere sie im Commands-Verzeichnis. Frage Claude: „Welche Slash Commands sollte ich für dieses Projekt erstellen?" um loszulegen.

Lassen Sie uns zusammenarbeiten

Sie möchten KI-Systeme aufbauen, Workflows automatisieren oder Ihre technische Infrastruktur skalieren? Ich helfe gerne.

• Fiverr (individuelle Entwicklung & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienstleistungen): xcybersecurity.io