Boris Cherny gibt Claude keine Prompts mehr.
Das ist keine virale Paraphrase. Es ist seine eigene, öffentlich dokumentierte Aussage: „Ich gebe Claude keine Prompts mehr. Ich habe Loops laufen, die Claude prompten und herausfinden, was zu tun ist. Meine Aufgabe ist es, Loops zu schreiben." Das sagte er bei mehreren öffentlichen Auftritten, einem Sequoia-Talk, einem Acquired-Interview, bei Y Combinators Startup School – und das Muster darunter ist das eigentliche Thema dieses Artikels. Keine Tipps. Keine Feature-Liste. Die spezifische Art und Weise, wie die Person, die Claude Code gebaut hat, es tatsächlich tagtäglich nutzt, verifiziert anhand seiner eigenen öffentlichen Aussagen und nicht durch Paraphrasen aus zweiter Hand.
Dies ist die vollständige Analyse, basierend auf dem, was Cherny tatsächlich gesagt hat, plus Anthropics eigenen dokumentierten Best Practices für das Tool, das er gebaut hat.
Claude Code sollte nie ein Produkt sein
Um zu verstehen, wie Cherny das Tool nutzt, muss man verstehen, woher es kommt. Denn der Ursprung erklärt die Philosophie, und es ist eine interessantere Geschichte, als den meisten Nutzern des Tools heute bewusst ist.
Claude Code begann 2021 als Forschungsprojekt zur KI-Sicherheitsausrichtung (AI Safety Alignment) und nicht als Produkt. Zuerst eine grobe VS-Code-Erweiterung, dann ein internes CLI-Tool namens clide, das bei Anthropic jahrelang genutzt wurde, bevor irgendjemand außerhalb des Unternehmens davon gehört hatte. Cherny kam im September 2024 zum Projekt und baute den Kern in einem zweiwöchigen Sprint im Dezember neu auf. Der öffentliche Start im Februar 2025 verlief ruhig, ohne großes Aufsehen, und stieß eher auf Achselzucken als auf Begeisterung. Dann kam Claude 4 auf den Markt, und die Verbreitung explodierte fast über Nacht.
Seine eigene Einschätzung des aktuellen Stands des Tools, direkt ausgesprochen: „Wir sind erst zu 1 % fertig."
Diese Einordnung ist wichtig für die Art und Weise, wie du an die Nutzung herangehen solltest. Cherny beschreibt kein fertiges Produkt mit einem festen, korrekten Nutzungsmuster. Er beschreibt etwas, das noch aktiv umgebaut wird, von einem Team, das das Tool nutzt, um das Tool zu bauen. Claude Code wurde wiederholt mit Claude Code selbst neu geschrieben – eine Schleife der Selbstverbesserung, die es gab, bevor der Begriff „Loop Engineering" überhaupt öffentlich verwendet wurde. Es lohnt sich, einen Moment darüber nachzudenken, denn es erklärt etwas, das viele neue Nutzer verwirrt: Warum scheint sich die „richtige" Art, dieses Tool zu nutzen, ständig zu verschieben? Es ist keine Inkonsistenz. Es ist ein Tool, dessen eigene Entwickler noch aktiv entdecken, wozu es tatsächlich in der Lage ist – in Echtzeit und mit dem Tool selbst.
Die Jahre als internes Forschungstool, bevor es jemals ein Produkt wurde, erklären auch, warum ein Großteil der untenstehenden Philosophie für eine Entwicklersoftware ungewöhnlich meinungsfreudig wirkt. Die meisten Tools sammeln von Tag eins an Features an, um eine breite externe Nutzerbasis mit konkurrierenden Bedürfnissen zufriedenzustellen. Claude Code hat zuerst seine Philosophie angesammelt, innerhalb eines kleinen Teams, das seine eigenen Probleme löste, bevor es jemals den Workflow von irgendjemand anderem erfüllen musste. Genau diese Geschichte ist der Grund, warum es sich lohnt, sich speziell mit Chernys eigenen Nutzungsmustern zu befassen, anstatt mit allgemeinen Ratschlägen zu „KI-Programmiertools" – es ist die Zeit wert, die man braucht, um es wirklich zu verinnerlichen.
Der Kernwandel: Vom Prompten zum Entwerfen von Loops
Das mit Abstand Wichtigste, was Cherny öffentlich über die tatsächliche Nutzung von Claude Code gesagt hat, ist die obige Aussage über Loops. Es lohnt sich, zu verstehen, was das in der Praxis tatsächlich bedeutet, und nicht nur als zitierbarer Satz.
Ein Prompt ist eine einzelne Anweisung, einmal gesendet, einmal beantwortet. Ein Loop ist ein System: Er promptet Claude, bewertet das Ergebnis, entscheidet, was als Nächstes passiert, und wiederholt sich – ohne dass ein Mensch in jedem einzelnen Zyklus dazwischensitzt. Chernys angegebene Stellenbeschreibung – „Meine Aufgabe ist es, Loops zu schreiben" – bedeutet, dass er seine Zeit damit verbringt, die Systeme zu entwerfen, die Prompts erzeugen und bewerten, und nicht selbst Schritt für Schritt Prompts zu tippen.
Sein bestätigter täglicher Workflow spiegelt dies direkt wider. Das Telefon als primäre Schnittstelle, nicht die Laptop-Tastatur. Fünf bis zehn aktive Sitzungen gleichzeitig, die jeweils Sub-Agenten hervorbringen können, manchmal ein paar hundert auf einmal, manchmal ein paar tausend über Nacht bei tiefergehender Arbeit. Dutzende Loops laufen kontinuierlich im Hintergrund, beaufsichtigen Pull Requests, halten die kontinuierliche Integration (CI) gesund und clustern Feedback nach einem wiederkehrenden Zeitplan. Routinen, die serverseitig weiterlaufen, auch wenn sein Laptop zugeklappt ist.
Der praktische Nutzen für alle, die Claude Code täglich nutzen: Die Obergrenze dessen, was das Tool leisten kann, wird nicht durch die Güte eines einzelnen Prompts bestimmt. Sie wird dadurch bestimmt, wie gut du das System um wiederholte, automatisierte Zyklen aus Prompting, Überprüfen und erneutem Versuch herum entwirfst.
Was sich im Systemprompt tatsächlich geändert hat – und warum es wichtig ist
Cherny hat auch direkt über eine spezifische, technische Entscheidung gesprochen, die zeigt, wie er darüber denkt, Claude überhaupt zu instruieren: „Wir haben ~80 % des Claude-Code-Systemprompts für unsere neuesten Modelle entfernt. Das haben wir über das Schreiben von Systemprompts gelernt."
Dieser Schnitt erfolgte speziell mit der Opus-4.8-Generation und reduzierte den Systemprompt von ungefähr 15.000 Zeichen auf etwa 4.500, ohne messbare Einbußen bei den Programmier-Bewertungen. Die Lektion dahinter ist, laut Anthropics eigener Anleitung zum Context Engineering, dass starre, erschöpfende Regellisten nicht mehr notwendig sind, sobald ein Modell fähig genug ist, echtes Urteilsvermögen an den Tag zu legen. Regeln werden zu Ermessensentscheidungen. Beispiele für die Tool-Nutzung werden durch Schnittstellen ersetzt, die so gestaltet sind, dass sie sich selbst dokumentieren. Vorab bereitgestellter, erschöpfender Kontext wird durch progressive Offenlegung (Progressive Disclosure) ersetzt: Informationen werden nur dann angezeigt, wenn eine bestimmte Situation es tatsächlich erfordert, anstatt standardmäßig in jede einzelne Sitzung geladen zu werden.
Eine Nuance, die man ehrlicherweise erwähnen sollte, da sie die einfache Version dieser Geschichte verkompliziert: Als Opus 5 herauskam, ergaben unabhängige Entwicklertests, dass sein tatsächlicher Systemprompt etwa 72 % länger war als der von Opus 4.8. Das ist kein Widerspruch zu der obigen Lektion, sondern eine tiefere Version davon. Der Prompt schrumpfte beim Umfang starrer Anweisungen, wuchs dann aber wieder mit reichhaltigeren, spezifischeren Referenzen, ausgearbeiteten Beispielen, Test-Suites und Bewertungsrastern (Rubrics) – die Art von Kontext, die ein wirklich fähigeres Modell tatsächlich gut nutzen kann. Die Erkenntnis ist nicht „kürzer ist immer besser", sondern dass der Umfang der Anweisungen dem folgen sollte, was das jeweilige Modell tatsächlich benötigt, um ein gutes Urteilsvermögen an den Tag zu legen – kein festes Ziel in die eine oder andere Richtung.
Eine CLAUDE.md schreiben, wie es Anthropics eigene Teams tun
Dies führt direkt zu der Frage, wie du deine eigenen Anweisungen auf Projektebene strukturieren solltest. Anthropics offizielle Dokumentation ist sich bezüglich des zu verwendenden Gedankenmodells sehr klar: Stell dir Claude als einen brillanten, aber sehr neuen Mitarbeiter vor, der unter Amnesie leidet und explizite Anweisungen benötigt.
Die praktischen Auswirkungen dieser Rahmung: Brillant bedeutet, dass du allgemeine Kompetenz nicht übermäßig erklären musst; sie ist bereits vorhanden. Neu bedeutet null angesammeltes Wissen über die Geschichte oder Konventionen deines spezifischen Projekts. Amnesie bedeutet, dass jede einzelne Sitzung bei null beginnt; CLAUDE.md ist das Einzige, das Kontext zuverlässig zwischen den Sitzungen weiterträgt.
Anthropics dokumentierte Anleitung zielt darauf ab, diese Datei unter 200 Zeilen zu halten, wobei einige der diszipliniertesten Teams mit nur 60 Zeilen auskommen. Der Test dafür, ob etwas in die Datei gehört: Ist das wirklich für fast jede Sitzung relevant, oder nur für einen engen, situativen Teilbereich der Arbeit? Universelle Dinge – Build-Befehle, nicht verhandelbare Stilregeln, Test-Erwartungen, echte Leitplanken – gehören in die Stammdatei. Alles, was enger gefasst ist, gehört in eine importierte Datei, die nur dann in den Kontext gezogen wird, wenn die spezifische Arbeit einer Sitzung es tatsächlich erfordert, und zwar mit der [@path/to](https://x.com/@path/to)/file-Importsyntax, die das Tool direkt unterstützt.
Für Anweisungen, die wirklich nicht übersprungen werden können, verwendet Anthropics eigene interne Praxis explizite Hervorhebungsmarkierungen wie „IMPORTANT" oder „YOU MUST", die ausdrücklich für die wenigen Regeln reserviert sind, bei denen die Kosten, wenn Claude sie übersieht, wirklich hoch sind. Alles auf diese Weise zu markieren, macht den Zweck völlig zunichte, da es aufhört, als Signal zu funktionieren, sobald es wahllos angewendet wird.
Plan-Modus: Verstehen, bevor man handelt
Ein spezifisches Verhaltensmuster, das es wert ist, in deine Arbeit mit dem Tool eingebaut zu werden: Claude dazu zu bringen, zu planen, bevor es ausführt, anstatt direkt in Änderungen zu springen.
Das ist nicht nur ein Feature-Schalter, sondern spiegelt einen echten Wandel wider, den Anthropics eigene Materialien beschreiben: Neuere Modelle planen korrekt, ohne dass sie so stark im Voraus gesteuert werden müssen wie frühere Modelle, so sehr, dass einige Teams berichtet haben, keinen expliziten Schritt im Plan-Modus mehr für jede Aufgabe erzwingen zu müssen, weil das eigene Standard-Denken des Modells bereits einen kohärenten Plan erzeugt, bevor es handelt. Dennoch bleibt es für wirklich komplexe Änderungen an mehreren Dateien ein sinnvoller Kontrollpunkt, explizit zuerst einen Plan anzufordern und ihn zu überprüfen, bevor man die Ausführung genehmigt. So wird eine falsch verstandene Anforderung erkannt, bevor sie sich über ein Dutzend Dateibearbeitungen ausbreitet, und nicht erst danach.
Sub-Agenten und paralleles Arbeiten
Chernys bestätigter Workflow, Hunderte, manchmal Tausende von Sub-Agenten in einer einzigen Sitzung laufen zu lassen, weist auf eine strukturelle Fähigkeit hin, die es wert ist, verstanden und bewusst eingesetzt zu werden, anstatt versehentlich.
Ein Haupt-Agent kann eine komplexe Aufgabe in kleinere Teile zerlegen und Sub-Agenten einsetzen, um sie unabhängig auszuführen, wobei jeder in seinem eigenen Kontext arbeitet, anstatt dass alles in einem kontinuierlichen Gespräch um Platz konkurriert. Das dient zwei Zwecken gleichzeitig. Es ermöglicht, dass Arbeit, die ein einzelnes Kontextfenster sprengen würde, stattdessen über viele kleinere Fenster läuft. Und es fügt eine echte Verifikationsebene hinzu, da ein Sub-Agent, der die Ausgabe eines anderen Agenten überprüft, Arbeit prüft, die er nicht selbst erzeugt hat. Das ist strukturell zuverlässiger als ein Agent, der seine eigene Hausaufgabe im selben Atemzug benotet, in dem er sie erstellt hat.
Speziell für paralleles Arbeiten ermöglichen Git-Worktrees mehreren Sitzungen, gleichzeitig in separaten Branches oder Verzeichnissen zu arbeiten, ohne dass laufende Änderungen der einen Sitzung die einer anderen stören. Das ist die mechanische Infrastruktur für das gleichzeitige Ausführen vieler paralleler Loops, so wie Cherny es persönlich beschreibt. Nicht ein einzelner Agent, der schneller arbeitet, sondern viele Agenten, die gleichzeitig an wirklich getrennten Arbeitspaketen arbeiten.
Die Grep-Entscheidung: Eine Fallstudie für Einfachheit statt Raffinesse
Eine spezifische, gut dokumentierte technische Entscheidung von Chernys eigenem Team veranschaulicht eine breitere Philosophie, die es wert ist, verinnerlicht zu werden. Claude Code hat Vektorsuche und Embeddings für die Codebase-Suche verworfen, zugunsten von schlichtem Grep und Glob. Seine eigenen Worte zum Ergebnis: „Hat alles übertroffen. Und zwar deutlich."
Die Lektion geht über diese eine spezifische Entscheidung hinaus. Eine ausgefeilter klingende Lösung – die semantische Vektorsuche – ist nicht automatisch besser als eine einfachere – grep –, wenn die einfachere tatsächlich gut auf das Problem abgestimmt ist. Codebasen haben exakte Syntax, exakte Funktionsnamen, exakte Importpfade – die Art von präzisem, wörtlichem Abgleich, bei dem grep glänzt und den ein unscharfer semantischer Abgleich tatsächlich untergraben kann, indem er plausible, aber falsche Ergebnisse liefert.
Die praktische Erkenntnis für die Konfiguration deiner eigenen Workflows: Greife nicht standardmäßig zum komplexer klingenden Tool oder zur komplexeren Architektur, nur weil du annimmst, dass Komplexität Leistungsfähigkeit bedeutet. Teste zuerst die einfache Option anhand deines tatsächlichen Anwendungsfalls. Oft gewinnt sie, und selbst wenn nicht, hast du bestätigt, dass der komplexere Ansatz seinen Platz verdient, anstatt es nur anzunehmen.
Lass einen Agenten niemals seine eigene Arbeit benoten
Ein separates, bestätigtes Prinzip aus Anthropics eigener Praxis des Harness-Engineering, das direkt dafür relevant ist, wie du jeden Verifikationsschritt in deinen eigenen Claude-Code-Workflows strukturieren solltest: Generierung und Bewertung sollten in wirklich getrennten Rollen stattfinden, denn ein Modell, das seine eigene Ausgabe im selben Atemzug überprüft, in dem es sie erzeugt hat, neigt dazu, positiv zu bewerten, selbst wenn ein menschlicher Prüfer den Fehler sofort erkennen würde.
In der Praxis bedeutet das, dass der Agent, der Code schreibt, nicht auch der Durchgang sein sollte, der entscheidet, ob dieser Code gut genug für die Veröffentlichung ist. Ein separater Bewertungsschritt, idealerweise mit Zugang zu etwas, das der erzeugende Agent nicht hatte – die tatsächliche Ausgabe der Test-Suite, das ursprüngliche Anforderungsdokument – fängt ein, was die Selbstbewertung übersieht. Dies ist dasselbe Prinzip, das hinter dem Sub-Agenten-Verifikationsmuster oben steht, angewandt als allgemeine Disziplin und nicht als spezifisches Feature.
Effort- und Kontextverwaltung
Für alle, die längere, anspruchsvollere Sitzungen durchführen, ist es wichtig zu verstehen, wie man das Effort-Level direkt signalisiert. Das Einfügen von „ultrathink" in einen Prompt signalisiert die maximale Denktiefe für diese spezifische Antwort, ohne die allgemeinen Sitzungseinstellungen zu ändern. Für die automatische Workflow-Orchestrierung auf Sitzungsebene kombiniert das Setzen des Effort-Levels auf die höchste Stufe tiefes Denken mit automatischer Aufgabenzerlegung über eine Sitzung hinweg. Dies erfordert jedoch ein Modell, das diese Effort-Stufe tatsächlich unterstützt; nicht jedes Modell in einer bestimmten Produktpalette tut das.
Das Kontextmanagement selbst verdient bei langen Sitzungen bewusste Aufmerksamkeit. Je länger eine Sitzung läuft, desto mehr kann der angesammelte Kontext das Signal dessen verwässern, was gerade tatsächlich wichtig ist – dasselbe Problem, das aufgeblähte CLAUDE.md-Dateien verursachen, nur dass es dynamisch innerhalb eines einzigen Gesprächs passiert und nicht statisch in einer Datei. Regelmäßig eine neue Sitzung für eine wirklich neue Arbeitsphase zu starten, anstatt ein einziges Gespräch auf unbestimmte Zeit zu verlängern, ist eine echte, praktische Disziplin, die es wert ist, angewendet zu werden, anstatt anzunehmen, dass mehr Kontext immer streng genommen besser ist.
Ein praktisches Beispiel: Das auf eine reale Aufgabe anwenden
Um all das oben Genannte konkret statt abstrakt zu machen, zeige ich hier, wie diese Prinzipien bei einer realen, alltäglichen Aufgabe tatsächlich zusammenwirken: dem Hinzufügen eines neuen Features zu einer bestehenden Codebase mit angemessener Komplexität, einigen miteinander verbundenen Dateien, einigen vorhandenen Tests und einer nicht-trivialen, aber nicht exotischen Änderung.
Beginne mit der bereits vorhandenen CLAUDE.md: kurz, universell, die Build- und Test-Befehle, die nicht verhandelbaren Stilregeln, nichts Situationales, das sie verstopft. Das bedeutet, dass die Sitzung mit echtem, relevantem Kontext startet, der automatisch geladen wird, ohne dass du die Konventionen deines Projekts von Grund auf neu erklären musst.
Anstatt einen einzelnen, langen, hoffnungsvollen Prompt zu schreiben, der das gesamte Feature in erschöpfendem Detail beschreibt, beschreibe das Ziel und lass die eigene Planung des Modells die Zerlegung übernehmen – der Philosophie des reduzierten Gerüsts aus der obigen Diskussion über Systemprompts vertrauend. Bei einer Aufgabe dieser Größe ist es den zusätzlichen Schritt wert, explizit zuerst einen Plan anzufordern, da eine hier falsch verstandene Anforderung eine Zwei-Minuten-Korrektur kostet, anstatt später eine Stunde, um Änderungen über mehrere Dateien wieder aufzurollen.
Sobald der Plan richtig aussieht, lass die Ausführung weitergehen. Wenn sich die Aufgabe auf natürliche Weise in wirklich unabhängige Teile aufteilt – zum Beispiel ein Datenmodell aktualisieren und separat die UI aktualisieren, die es verwendet – ist das ein natürlicher Kandidat für die Sub-Agenten-Zerlegung, wobei jedes Teil in seinem eigenen Kontext arbeitet, anstatt alles in einem einzigen kontinuierlichen Gespräch zu drängen.
Bevor du das Ergebnis als fertig betrachtest, führe einen separaten Verifikationsdurchgang durch, anstatt dem eigenen Selbstbericht des implementierenden Agenten zu vertrauen, dass alles funktioniert. Das kann so einfach sein wie eine neue Sitzung oder ein Sub-Agent mit Nur-Lese-Zugriff, der die tatsächliche Testausgabe und den Diff gegen den ursprünglichen Plan prüft, anstatt nur ein selbstbewusstes „das ist vollständig" aus demselben Kontext zu akzeptieren, der den Code geschrieben hat.
Beachte, was in diesem Durchlauf fehlt. Keine exotischen Tools. Keine ungewöhnliche Konfiguration. Nur die gewöhnliche Anwendung von Plan-Zuerst für wirklich komplexe Arbeit, Sub-Agenten-Zerlegung für wirklich unabhängige Teile und getrennte Verifikation anstelle von Selbstbewertung – dieselben drei Prinzipien, die sich durch alles oben Genannte ziehen, angewandt auf eine konkrete Aufgabe, anstatt sie abstrakt zu beschreiben.
Das über eine einzelne Person hinaus skalieren
Alles oben Beschriebene sind Praktiken für eine Person, die Claude Code bewusst einsetzt. Chernys eigener bestätigter Workflow – Hunderte von Sub-Agenten täglich, Tausende über Nacht – ist selbst bereits eine Form der Skalierung: eine Person, die eine wirklich große Menge paralleler, automatisierter Arbeit steuert. Aber dieselben Prinzipien gelten auch für ein Team, das diese Praktiken gemeinsam übernimmt, mit einigen spezifischen Überlegungen, die es wert sind, direkt benannt zu werden.
CLAUDE.md hört in dem Moment auf, eine persönliche Präferenzdatei zu sein, in dem mehr als eine Person in einem Team tatsächlich mit Claude Code an derselben Codebase arbeitet. Behandle Änderungen daran mit derselben Review-Disziplin, die du bei jeder gemeinsamen Konfiguration anwenden würdest, die den Workflow des gesamten Teams betrifft. Ein Teammitglied, das nach einer einzigen frustrierenden Sitzung eine einmalige „Hotfix"-Anweisung ohne Review hinzufügt, ist genau der Mechanismus, der aufgeblähte, sich selbst widersprechende Dateien erzeugt, die nicht mehr zuverlässig befolgt werden. Ein leichtgewichtiger Review-Schritt – auch wenn nur eine zweite Person kurz auf den Diff schaut, bevor er gemerged wird – fängt einen erheblichen Teil davon ab, bevor es sich zu einem echten Problem ansammelt.
Die Verifikationsdisziplin ist im Team-Maßstab sogar noch wichtiger als für einen Einzelnutzer. Wenn eine Person sowohl ihre eigene agentengestützte Arbeit schreibt als auch überprüft, besteht zumindest eine Chance, dass sie persönlich etwas bemerkt, das der Agent übersehen hat. Wenn ein Team sich darauf verlässt, dass Claude-Code-Ausgaben durch einen gemeinsamen Review-Prozess laufen, ist das Prinzip der getrennten Bewertung von früher keine Option mehr, sondern der eigentliche Mechanismus, der die Codebase davor schützt, dass die selbstbewusste, aber falsche Selbsteinschätzung eines Agenten die Produktion erreicht. Die Alternative wäre, darauf zu vertrauen, dass irgendein Mensch irgendwann im Workflow eines vielbeschäftigten Teams zufällig das bemerkt, was der Agent selbst nicht markiert hat.
Es lohnt sich auch, explizite Verantwortlichkeit für regelmäßige CLAUDE.md-Audits festzulegen – dieselbe Wartungsdisziplin, die für jedes gemeinsame, wachsende Dokument empfohlen wird. Ohne eine klar zugewiesene verantwortliche Person fällt diese Arbeit tendenziell durchs Raster, gerade weil sie keine einzelne unmittelbare Aufgabe blockiert, wie es ein kaputter Build tut. Und sechs Monate lang ansammelnde Ergänzungen ohne Besitzer erzeugen genau die Art von aufgeblähter, widersprüchlicher Datei, die das Prinzip der universellen Anwendbarkeit eigentlich verhindern soll.
Wo diese Prinzipien falsch angewendet werden
Einige wenige spezifische Fehlinterpretationen der obigen Ideen tauchen wiederholt auf. Es lohnt sich, sie direkt zu benennen, da jede eine einfache, spezifische Korrektur hat.
„Loops über Prompts" als Freibrief zu behandeln, das Verständnis der Aufgabe komplett zu überspringen. Chernys eigene Aussage ist, dass seine Aufgabe darin besteht, Loops zu schreiben, nicht dass er aufgehört hat, darüber nachzudenken, was diese Loops tatsächlich tun sollen. Einen guten Loop zu entwerfen – eine gute Erfolgsdefinition, eine gute Stopp-Bedingung – erfordert immer noch ein so klares Verständnis des Problems, wie es auch das Schreiben eines guten einzelnen Prompts erfordern würde. Der Loop ersetzt das wiederholte manuelle Tippen, nicht das anfängliche Denken.
Die Reduzierung des Systemprompts als „gib dem Modell immer weniger Kontext" zu lesen. Das Gegenbeispiel von Opus 5 weiter oben in diesem Artikel existiert speziell, um diese Fehlinterpretation zu korrigieren. Die eigentliche Lektion ist, dass der Umfang der Anweisungen dem entsprechen sollte, was ein bestimmtes Modell wirklich braucht, um ein gutes Urteilsvermögen an den Tag zu legen. Das bedeutet manchmal weniger starre Regellisten und manchmal mehr reichhaltiges, spezifisches Referenzmaterial. Kontext wahllos zu kürzen, weil „die neuesten Modelle weniger brauchen", wendet eine nuancierte, modellspezifische Erkenntnis als pauschale Regel an.
Einfache Aufgaben aus Gewohnheit übermäßig in Sub-Agenten zu zerlegen. Die Sub-Agenten-Zerlegung verdient ihre Komplexität bei wirklich großen, wirklich unabhängigen Arbeitspaketen. Eine kleine, eng gekoppelte Änderung nur zur Verwendung des Musters in künstliche Sub-Agenten-Teile zu zerlegen, erhöht den Koordinationsaufwand, ohne den Nutzen zu bringen, der es bei größeren Aufgaben rechtfertigt. Das frühere praktische Beispiel in diesem Artikel hat Sub-Agenten bewusst nur dort eingesetzt, wo die Teile natürlich unabhängig waren, nicht als Standard für jede Aufgabe, unabhängig von der Größe.
Die Verifikation unter der Annahme zu überspringen, dass „die neueren Modelle sie nicht mehr brauchen". Das Prinzip der getrennten Bewertung ist keine Notlösung für schwächere Modelle, die mit zunehmender Leistungsfähigkeit überflüssig wird. Es ist eine strukturelle Tatsache über die Selbstbewertung: Ein Modell, das seine eigene Arbeit in demselben Kontext überprüft, in dem es sie erzeugt hat, wird es immer schwerer haben, seine eigenen blinden Flecken zu entdecken, als eine unabhängige Prüfung es hätte, egal wie leistungsfähig das zugrunde liegende Modell wird. Das gilt auch für menschliche Prüfer, und es hört nicht auf, wahr zu sein, nur weil der Prüfer klüger wird.
Die tatsächlichen täglichen Gewohnheiten, die es wert sind, übernommen zu werden
Fassen wir alles oben Genannte zu einer konkreten, praktischen täglichen Praxis zusammen. So sieht es tatsächlich aus, wenn man Chernys gezeigtem Ansatz folgt.
Hör auf, jede Aufgabe als einen einzelnen Prompt zu behandeln, der beim ersten Versuch richtig sein muss. Entwirf stattdessen einen Loop: einen Agenten, der die Aufgabe versucht, eine Möglichkeit zu prüfen, ob der Versuch erfolgreich war, und einen definierten Pfad dafür, was als Nächstes passiert, abhängig von dieser Prüfung: bestanden, erneut versuchen oder direkt an dich eskalieren.
Halte deine CLAUDE.md kurz und behandele sie als Onboarding-Material für einen fähigen, aber kontextfreien neuen Mitarbeiter, nicht als umfassendes Handbuch. Verschiebe alles Situationale in importierte Dateien, anstatt das Stammdokument aufzublähen.
Nutze den Plan-Modus bewusst bei wirklich komplexen Arbeiten mit mehreren Dateien und vertraue bei einfacheren, klar abgegrenzten Aufgaben auf die eigene Standard-Planung des Modells, anstatt aus Gewohnheit überall einen zusätzlichen Schritt zu erzwingen.
Zerlege große Aufgaben in Sub-Agenten, die in separaten Kontexten arbeiten, anstatt zu versuchen, eine gesamte komplexe Aufgabe in einem einzigen kontinuierlichen Gespräch zu halten. Verwende einen separaten Durchgang, um bedeutende Arbeit zu verifizieren, anstatt der Selbstbewertung eines einzelnen Agenten zu vertrauen.
Greife standardmäßig zum einfachsten Tool, das dein spezifisches Problem plausibel lösen könnte, so wie grep für diesen speziellen Anwendungsfall die Vektorsuche geschlagen hat. Greife erst zu mehr Komplexität, wenn die einfache Option tatsächlich getestet und für unzureichend befunden wurde.
Baue echte Parallelität in deinen Workflow ein, indem du Git-Worktrees für wirklich unabhängige Arbeitspakete verwendest, anstatt alles über eine sequenzielle Sitzung laufen zu lassen, nur weil das die Standardmethode ist.
Wohin das tatsächlich führt
Chernys eigene Formulierung „Wir sind erst zu 1 % fertig" sollte man als praktische Aussage ernst nehmen, nicht nur als bescheiden klingenden Satz. Die oben beschriebenen spezifischen Muster – Loop-Design statt einzelnem Prompting, aggressives Zurückschneiden des Systemprompts, wenn Modelle leistungsfähiger werden, Sub-Agenten-Zerlegung, getrennte Verifikation – sind keine feste, endgültige Methodik. Sie sind der aktuelle Stand eines Tools und einer Praxis, die ihr eigener Schöpfer als noch am Anfang beschreibt.
Die eigentliche Fähigkeit, die es zu entwickeln lohnt, ist nicht das Auswendiglernen der heutigen spezifischen Konfiguration von Best Practices. Es geht darum, die zugrunde liegenden Prinzipien gut genug zu verstehen, um sich weiterhin anzupassen, während sich das Tool selbst ständig ändert – so wie Chernys eigenes Team Claude Code wiederholt mit Claude Code neu aufgebaut hat, den Loop verfeinernd, anstatt eine einzelne Version davon als fertig zu betrachten.
Das ist der rote Faden, der alles in diesem Artikel verbindet. Keine statische Liste von Tipps, sondern eine funktionierende Philosophie: Entwirf Systeme, anstatt einzelne Anweisungen zu tippen; halte Anweisungen schlank und lass die Modellfähigkeit mehr von der Arbeit übernehmen, wenn sie sich verbessert; verifiziere unabhängig, anstatt der Selbstbewertung zu vertrauen; und setze standardmäßig auf Einfachheit, bis sich Komplexität tatsächlich als notwendig erweist. Direkt von der Person, die das Tool gebaut hat, und wie sie es tatsächlich selbst nutzt.
Folge @cyrilXBT für weitere Claude-Code-Analysen, die auf verifiziertem, öffentlich dokumentiertem Material basieren.
