Ein Analysebericht über ein Interview mit Boris Cherny, dem Erfinder von Claude Code, landete im August bei mir. Kernempfehlung: über 80 Prozent des System-Prompts löschen, das Modell arbeite ohne diesen Ballast intelligenter. Klang plausibel. Also habe ich es in meiner Claude-Code-Konfiguration ausprobiert und meine 72 selbstgeschriebenen Skills abgeschaltet.

Das Ergebnis war deutlich schlechter.

Was in dem Bericht stand

Der Bericht empfiehlt eine Methode, die Cherny „Ablation“ nennt: System-Prompt komplett löschen, den Agenten am echten Projekt arbeiten lassen, Fehler protokollieren, und Anweisungen erst dann zurückholen, wenn dasselbe wiederholt schiefgeht. Dazu Zahlen, die aufhorchen lassen. Die Bun-Codebase, über 100.000 Zeilen, in elf Tagen von Zig nach Rust umgeschrieben. Arc-AGI-3 von einstelligen Werten auf 30 Prozent.

Ich habe das Originaltranskript geholt und dagegengelegt. An fünf Stellen kippt der Bericht die Aussage.

Die „Lethal Trifecta“ steht dort als Sicherheitsarchitektur aus drei Schutzschichten. Im Interview ist sie das Gegenteil, nämlich das Problem — der Begriff stammt von Simon Willison und beschreibt eine Risikokombination. Die Electron-nach-Swift-Migration ist im Bericht „vollständig transformiert“ und lief „14 Tage völlig autark“. Cherny im Transkript: „It’s still running.“ Nach zwei Wochen also nicht fertig. Die Bun-Migration wurde angeblich „durch einen einzigen strategischen Prompt initiiert“. Auf genau diese Nachfrage antwortet er: „No, it wasn’t one shot, but there was steering.“ Aus täglich „20 oder 30 dieser Routinen“ werden im Bericht 20 bis 30 Pull Requests. Und das Max-20X-Kontingent, im Bericht ein strategischer Hebel für zwanzigfache Leistung, war ein Giveaway ans Publikum der Startup School.

Die wichtigste Abweichung ist aber eine Auslassung. Cherny sagt über den gelöschten Prompt:

„the model is actually a little bit more intelligent without these prompts. But when you use Claude Code as a product, you do actually want some of these prompts because it helps you use the product and it helps the model behave in the way that you would want.“

Der zweite Halbsatz fehlt im Bericht. Aus einer Methode mit drei Schritten wird so eine Löschanweisung mit einem.

Warum mein Test schlechter lief

Der Unterschied liegt in der Art der Anweisung. Cherny löscht Verhaltenskorrekturen: „read before write“, „use absolute paths“, „batch your tool calls“. Dinge, die ein aktuelles Modell von selbst richtig macht und die nur noch Aufmerksamkeit binden.

Meine Skills tragen etwas anderes. Sie enthalten Wissen, das unmöglich im Training stecken kann: die Architektur meines Chatbot-Moduls, die Umsetzung der KI-Offenlegung nach EU AI Act Artikel 50, das YAML-Schema meines Report-Generators, die Konventionen für Modul-Manifeste in meinen Kundenprojekten. Von 72 eigenen Skills sind 37 auf Odoo, FastReport oder meine Infrastruktur zugeschnitten. Kein Modell kann das raten.

Falls du selbst mit einer gewachsenen Konfiguration arbeitest, lohnt genau diese Unterscheidung, bevor du etwas löschst: Steht dort eine Anweisung, wie das Modell arbeiten soll, oder steht dort Wissen, das es nirgends herbekommt?

Was ich gemessen habe

Vor dem Umbau habe ich gezählt statt geschätzt. In meiner Konfiguration stehen rund 16.000 Tokens im Kontext, bevor ich das erste Wort tippe: 33.869 Zeichen Skill-Beschreibungen, 8.705 Zeichen Agenten-Beschreibungen, 13.279 Zeichen Basis-Instruktionen, dazu ein Hook, der Skills und Agenten ein zweites Mal hineinschreibt.

Die Hälfte davon stammt aus einer einzigen Erweiterung, die in meinem Setup 71 Skills, 34 Agenten und 19 Hook-Einträge mitbringt. Ich brauche sie nur bei bestimmten Projekten.

Was ich gebaut habe

In mein Sync-Werkzeug SCCS ist ein Profil-Schalter eingezogen. sccs profile off gsd verschiebt die Skills und Agenten einer Erweiterung in einen Parkbereich außerhalb des Claude-Verzeichnisses, entfernt ihre Hook-Einträge aus der Konfiguration und setzt die Statusleiste auf ein Ersatz-Preset. sccs profile on gsd holt alles zurück.

Gelöscht wird dabei nichts. Kollidiert eine Datei im Parkbereich mit einer gleichnamigen, bricht der Vorgang ab, statt zu überschreiben.

Zwei Details haben mich beim Bauen mehr Zeit gekostet als der Schalter selbst. Erstens installiert mein eigenes Wartungswerkzeug die abgeschaltete Erweiterung beim nächsten Lauf wieder, bis es lernt, deaktivierte Profile zu überspringen. Zweitens hätte die Sync-Funktion beim ersten Lauf angefangen, die geparkten Reste ins Git-Repository zu schieben, wenn ich die Ausschlussliste an derselben Stelle gefiltert hätte. Ein Test hält das jetzt fest.

Was der Schalter wirklich bringt

Rund 5.000 Tokens. Nicht die Hälfte meines Setups, wie ich zuerst gehofft hatte.

Die 71 Skills der Erweiterung tragen sehr knappe Beschreibungen; der dickere Brocken sind meine eigenen 72 mit 26.058 Zeichen. Spürbarer als die Tokens ist etwas anderes: Acht der 19 Hook-Einträge sind Guards, die bei jedem Lese-, Schreib- und Shell-Aufruf einen Node-Prozess starten. Bei jedem. Auch wenn die Erweiterung an diesem Tag nichts zu tun hat.

Wie es weitergeht

Ich arbeite ab jetzt mit abgeschaltetem Profil und schaue, wo es mir fehlt. Das ist Chernys dritter Schritt, den der Bericht weggelassen hat. Abschalten, messen, und zurückholen, was sich als nötig erweist.

Drei Punkte stehen noch auf der Liste. Meine Regeldatei enthält Anweisungen wie „lies vor dem Schreiben“, genau die Sorte, die Cherny zu Recht streicht. Der Hook, der Skills und Agenten dupliziert, kostet etwa 2.000 Tokens ohne Gegenwert. Und sieben meiner Skill-Dateien liegen über 40 KB, die größte bei 80 KB, was beim Aufruf rund 20.000 Tokens auf einen Schlag bedeutet.

Ob das am Ende spürbar bessere Antworten gibt oder ob ich nur eine schönere Zahl im Kontextfenster habe, weiß ich noch nicht. Ich melde mich, wenn ich es weiß.