225,000 Sterne für eine Markdown-Datei: Karpathys Klagen als Regeln

Ein Repository mit einer einzigen Markdown-Datei steht bei 225,000 Sternen. Allein diese Woche kamen rund 4,000 hinzu. Es gibt keinen Code, keinen Build-Schritt, kein Release, keine Benchmark-Tabelle – nur vier Prinzipien und eine Reihe von Anweisungen dazu, wie sich ein Sprachmodell verhalten soll, wenn es eine Codebasis ändern soll.

Die Datei heißt CLAUDE.md, liegt in einem Repository namens andrej-karpathy-skills und wird von forrestchang gepflegt. Sie verdichtet eine Reihe von Beschwerden, die Andrej Karpathy über das Programmierverhalten von LLMs geäußert hat, zu etwas, das ein Agent zu Beginn jeder Sitzung tatsächlich liest. Die Zahl der Sterne ist der interessante Datenpunkt, nicht der Inhalt, weil sie etwas darüber sagt, wie Agentenverhalten derzeit geflickt wird: inoffiziell, in Prosa, von Einzelpersonen.

Die Beschwerden, in Karpathys Worten

Drei Zitate aus dem Originalbeitrag, auf dem das Repository aufbaut:

„Die Modelle treffen in Ihrem Namen falsche Annahmen und laufen damit einfach weiter, ohne zu prüfen. Sie verwalten ihre Verwirrung nicht, suchen keine Klärung, legen Widersprüche nicht offen, stellen keine Abwägungen dar, widersprechen nicht, wenn sie es sollten."

„Sie machen Code und APIs gern überkompliziert, blähen Abstraktionen auf, räumen toten Code nicht auf … sie bauen eine aufgeblähte Konstruktion über 1,000 Zeilen, wo 100 reichen würden."

„Sie ändern oder entfernen mitunter als Nebenwirkung noch Kommentare und Code, den sie nicht ausreichend verstehen, selbst wenn das für die Aufgabe irrelevant ist."

Wer jemals von einem Agenten geschriebenen Code ausgeliefert hat, erkennt alle drei wieder. Der zweite ist der häufigste: Man bittet um eine Validierungsfunktion und bekommt eine abstrakte Basisklasse, ein Strategie-Muster, ein Konfigurationsobjekt und vierzig Zeilen Fehlerbehandlung für Zustände, die nicht eintreten können.

Was die vier Prinzipien tatsächlich sagen

Erst denken, dann coden. Annahmen ausdrücklich benennen, mehrere Interpretationen vorlegen statt stillschweigend eine zu wählen, widersprechen, wenn ein einfacherer Ansatz existiert, bei Verwirrung anhalten und benennen, was unklar ist.

Einfachheit zuerst. Minimaler Code, der das Problem löst. Keine Funktionen über die Anfrage hinaus, keine Abstraktionen für Einmal-Code, keine Konfigurierbarkeit, die niemand verlangt hat, keine Fehlerbehandlung für unmögliche Szenarien. Der Test: Würde eine erfahrene Entwicklerin das als überkompliziert bezeichnen?

Chirurgische Änderungen. Nur anfassen, was nötig ist. Benachbarten Code nicht verbessern, nicht umformatieren, was man nur durchquert. Am bestehenden Stil bleiben, auch wenn man es anders machen würde. Unabhängigen toten Code erwähnen, nicht löschen. Wenn die Änderung Waisen erzeugt, nur diese aufräumen. Der Test: Jede geänderte Zeile lässt sich auf die Anfrage zurückführen.

Zielgetriebene Ausführung. Imperative Anweisungen in überprüfbare Erfolgskriterien übersetzen. Nicht „Validierung hinzufügen", sondern „Tests für ungültige Eingaben schreiben und sie zum Laufen bringen". Nicht „den Bug beheben", sondern „einen Test schreiben, der ihn reproduziert, und ihn zum Laufen bringen".

Das letzte ist das einzige Prinzip, das keine Zurückhaltung ist. Es ist Hebelwirkung, und es kommt mit dem besten Satz des Ausgangsmaterials: LLMs sind außergewöhnlich gut darin, in Schleifen zu laufen, bis sie ein konkretes Ziel erreichen. Sag ihm nicht, was es tun soll; gib ihm Erfolgskriterien und sieh zu.

Installation, und die Tatsache, dass sie zwei Zeilen braucht

Zwei Wege, beide trivial.

/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills

Oder, pro Projekt:

curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

Eine Cursor-Regel liegt ebenfalls im Repository, unter .cursor/rules/karpathy-guidelines.mdc, sodass dieselben Leitlinien greifen, wenn das Projekt in Cursor geöffnet wird. MIT-Lizenz.

Die Vertriebsgeschichte ist der Punkt. Vor zwei Jahren hätte „Modelle überentwickeln" zu beheben ein Fine-Tuning, einen vom Anbieter ausgelieferten System-Prompt oder ein Framework bedeutet. Heute ist es eine Datei, die ein Nutzer in ein Repository legt, plus ein Marketplace-Eintrag, der sie in jedes Projekt auf dieser Maschine bringt. Die Rückkopplung zwischen Beschwerde und Korrektur ist viel kürzer, und deshalb steht der Zähler da, wo er steht: Die Datei ist die billigstmögliche Einheit von Verhaltensänderung.

Warum ich die Rahmung trotzdem skeptisch sehe

Drei Einwände, im Geist der Datei selbst vorgetragen.

Prinzipien sind keine Tests. „Einfachheit zuerst" ist eine Präferenz, kein Kriterium. Ein Agent, der das liest, produziert trotzdem eine 300-Zeilen-Lösung, wo 80 reichen würden, weil das Modell Komplexität nicht messen kann. Das einzige Prinzip der Datei, das wirklich funktioniert – zielgetriebene Ausführung – funktioniert gerade, weil es eine Präferenz durch eine Prüfung ersetzt: einen Test, der entweder besteht oder nicht.

„Chirurgische Änderungen" kämpft gegen das, worin Agenten gut sind. Wenn man eine kleine Änderung verlangt und eine kleine Änderung bekommt, hat man ein teures Werkzeug benutzt, um Tastenanschläge zu sparen. Der Wert eines Agenten liegt darin, dass er etwas umbauen kann, das man selbst nicht anfassen wollte. Die Antwort der Datei: Umbau soll verlangt werden, nicht ungefragt angeboten – vernünftig, aber es heißt, die Leitlinien optimieren für einen bestimmten Nutzertyp: jemanden mit bestehender Codebasis und einer festen Meinung zu Diffs.

Niemand misst, ob es wirkt. Das Repository nennt Signale: weniger unnötige Änderungen in Diffs, weniger Umschreibungen, klärende Fragen vor der Umsetzung statt danach. Die sind real und beobachtbar. Aber es gibt keine Kontrollbedingung. Man installiert eine Datei, in der „frag, bevor du annimmst" steht, und nun fragt der Agent, bevor er annimmt. Hat die Datei das bewirkt, oder hat das Aufschreiben einen auf Verhalten aufmerksam gemacht, das schon da war?

Der Autor benennt den Kompromiss offen, was ihm anzurechnen ist: Die Leitlinien neigen zur Vorsicht statt zur Geschwindigkeit, und bei trivialen Aufgaben soll man selbst urteilen. Das ist der richtige Vorbehalt und zugleich die Spannung. Ein Agent, der bei einem einzeiligen Tippfehler innehält und nachfragt, ist schlechter als einer, der ihn behebt.

Die Fassung, die ich tatsächlich schreiben würde

Wenn die Schwäche der Datei ist, dass drei ihrer vier Prinzipien Präferenzen sind, dann ist die Lösung, sie in Prüfungen zu verwandeln. Konkret: vier Zeilen, die den Kontakt mit einem echten Repository überstehen.

Vor dem Editieren die Dateien auflisten, die man anfassen will, und anhalten, wenn die Liste länger ist, als die Anfrage impliziert. Das macht „chirurgische Änderungen" zu einem Gate statt zu einer Stimmung.

Vor dem Abschluss die Tests laufen lassen und die Ausgabe einfügen. Das macht „zielgetriebene Ausführung" unverhandelbar und ist die Anweisung mit der höchsten Hebelwirkung, die man einem Agenten vorlegen kann.

Hat eine Aufgabe mehr als eine plausible Interpretation, beide schreiben und fragen, welche gilt. Das verwandelt „erst denken, dann coden" von einem Wunsch in einen Zug im Gespräch.

Und ein Diff-Budget: Wenn die Änderung für einen Bugfix mehr als grob 150 Zeilen hinzufügt, anhalten und jede Abstraktion begründen. Grob, aber es fängt den von Karpathy beschriebenen Fehlermodus, den, der wirklich Zeit kostet.

Nichts davon steht in der Datei, und es muss auch nicht. Die Aufgabe der Datei ist, eine Haltung zu setzen. Die Prüfungen sind die Aufgabe dessen, dem das Repository gehört.

Was der Sternzähler wirklich sagt

Der Großteil der in diesem Jahr veröffentlichten Agenten-Tools dreht sich um Fähigkeit: längere Kontexte, mehr Werkzeuge, parallele Ausführung. Diese Datei dreht sich um Zurückhaltung, und sie bekam mehr Aufmerksamkeit als die meisten Fähigkeits-Ankündigungen.

Diese Lücke ist aufschlussreich. Wer für diese Werkzeuge zahlt, ist zu dem Schluss gekommen, dass der Engpass nicht mehr ist, was das Modell kann, sondern es dazu zu bringen, mit Dingen aufzuhören, um die niemand gebeten hat. Eine Markdown-Datei mit 225,000 Sternen ist ein ungewöhnlich klares Signal dafür, wo die Frustration tatsächlich sitzt.

Für die Labore ist es zugleich ein etwas peinliches Signal. Das Repository mit den meisten Sternen in dieser Kategorie ist eine Liste von vier Dingen, die die Modelle ohnehin schon tun sollten.