Markdown 1枚に22.5万スター、Karpathyの不満は4つの原則になった

Markdownファイルを1つだけ入れたリポジトリが22万5,000スターを集めている。今週だけでさらに約4,000。中身はコードでもビルド手順でもリリースでもベンチマーク表でもなく、4つの原則と、「言語モデルがコードベースの変更を求められたとき、どう振る舞うべきか」に関する指示だけだ。

ファイル名は CLAUDE.md、リポジトリは andrej-karpathy-skills、メンテナーは forrestchang。Andrej Karpathy が LLM のコーディング挙動について並べた不満を、エージェントが毎セッションの冒頭で実際に読み込む形に圧縮したものだ。興味深いデータポイントは内容ではなくスター数である。エージェントの振る舞いがいま、非公式に、散文で、個人の手によってパッチされていることを示しているからだ。

Karpathy の言葉で、その不満

このリポジトリが下敷きにしている原稿からの3つの引用。

「モデルはこちらの代わりに誤った前提を置き、確認もせずそのまま走り出す。自分の混乱を管理せず、確認を求めず、矛盾を指摘せず、トレードオフを示さず、反論すべきときに反論しない。」

「コードとAPIを過剰に複雑にし、抽象を膨らませ、死んだコードも片付けない……100行で済むところを1,000行超の肥大した構造で実装してしまう。」

「十分に理解していないコメントやコードを、副作用として書き換えたり消したりすることが今もある。タスクと無関係であっても、だ。」

エージェントに書かせたコードを出荷したことがある人なら、3つとも心当たりがあるはずだ。最も多いのは2番目で、バリデーション関数を頼むと、抽象基底クラスとストラテジーパターンと設定オブジェクト、そして起こりえない状態のための40行のエラーハンドリングが出てくる。

4つの原則は何を言っているのか

書く前に考える。前提は明示する。解釈が複数あるなら黙って一つ選ばず、並べて示す。より単純な方法があるなら反論する。混乱したら止まり、何が不明なのかを言葉にする。

シンプルさが第一。問題を解く最小のコード。依頼を超えた機能は足さない。一度しか使わないコードに抽象を作らない。誰も求めていない設定可能性を入れない。起こりえない状況のエラーハンドリングを書かない。判定基準は、シニアエンジニアが「複雑すぎる」と言うかどうか。

外科手術的な変更。触る必要のあるものだけに触れる。通りがかりのコードを良くしたり、整形し直したりしない。自分なら違う書き方をしても、既存のスタイルに合わせる。無関係な死んだコードに気づいたら言及するだけにして、消さない。変更が孤立したコードを生んだなら、それだけを片付ける。判定基準は、変更したすべての行が依頼にたどれること。

ゴール駆動の実行。命令形の指示を検証可能な成功条件に変換する。「バリデーションを追加」ではなく「不正な入力のテストを書き、通す」。「バグを直す」ではなく「再現するテストを書き、通す」。

最後の一つだけが制約ではない原則だ。これはレバレッジであり、原資料で最も良い一節が添えられている。LLM は特定のゴールに到達するまでループするのが極端に得意だ。何をするか命じるのではなく、成功条件を与えて走らせればいい。

インストール、そしてそれが2行で終わるという事実

ルートは2つ、どちらも些細だ。

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

あるいはプロジェクト単位で：

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

リポジトリには Cursor 用のルール .cursor/rules/karpathy-guidelines.mdc もコミットされているので、Cursor でプロジェクトを開いたときも同じ指針が効く。MIT ライセンス。

配布の話こそが本題だ。2年前なら「モデルが過剰設計する」を直すには、ファインチューニングか、ベンダーが配るシステムプロンプトか、フレームワークが必要だった。いまはユーザーがリポジトリに置く1ファイルと、そのマシン上の全プロジェクトに入るマーケットプレイスのリストで済む。不満と修正のあいだのフィードバックループははるかに短くなり、スター数がこの数字なのはそのためだ。このファイルは、振る舞いを変える最小単位なのである。

それでもこの枠組みには懐疑的だ

このファイル自身の精神に沿って、3つ留保を挙げる。

原則はテストではない。「シンプルさが第一」は選好であって基準ではない。それを読んだエージェントは、80行で済むところに300行を出す。複雑さを測る手段がモデルにないからだ。ファイル内で実際に機能している唯一の原則、ゴール駆動の実行が効くのは、選好をチェックに置き換えているからにほかならない。テストは通るか通らないかだ。

「外科手術的な変更」はエージェントの得意分野と戦う。小さな編集を頼んで小さな編集が返ってくるなら、高いツールでキーストロークを節約しただけだ。エージェントの価値は、こちらが触りたくなかったものを再構成できることにある。ファイルの答えは、再構成は要求されたときだけ行い、自分から申し出るなというもの。もっともだが、それはこの指針が特定のユーザー向けに最適化されているということでもある。既存のコードベースがあり、diff に強い意見を持つ人だ。

誰も効果を測っていない。リポジトリはシグナルを挙げている。diff の不要な変更が減る、書き直しが減る、実装の後ではなく前に確認の質問が出る。どれも実在し、観察可能だ。しかし対照条件がない。「推測する前に聞け」と書いたファイルを入れ、エージェントは推測する前に聞くようになった。それを引き起こしたのはファイルか、それとも書き留めた行為によって、もともとあった振る舞いに気づいただけなのか。

著者はトレードオフを正直に書いている。そこは評価すべきで、指針は速度より慎重さに寄り、些細なタスクでは自分で判断せよという。正しい注意書きであり、同時に緊張でもある。1行のタイポ修正のために立ち止まって尋ねるエージェントは、直してしまうエージェントより悪い。

私が実際に書くなら、このバージョンだ

このファイルの弱点が、4つの原則のうち3つは選好にすぎないことなら、直し方はそれらをチェックに変えることだ。具体的には、実際のリポジトリで耐える4行。

編集の前に、触るつもりのファイルを列挙し、そのリストが依頼から想定されるより長ければ止まる。これで「外科手術的な変更」は気分ではなくゲートになる。

終える前にテストを走らせ、出力を貼る。これで「ゴール駆動の実行」は交渉不可になり、エージェントの前に置ける最もレバレッジの高い指示になる。

タスクに妥当な解釈が複数あるなら、両方書いてどちらかを問う。これで「書く前に考える」は願望から会話の1ターンになる。

そして diff 予算。バグ修正でおよそ150行を超えるなら止まり、各抽象の正当化を求める。乱暴だが、Karpathy が指した失敗モード、実際に時間を食うものを捕まえる。

どれもファイルにはないし、必要もない。ファイルの仕事は姿勢を定めることだ。チェックはリポジトリの持ち主の仕事である。

スター数が本当に語っていること

今年リリースされたエージェントツールの大半は能力の話だ。長いコンテキスト、より多くのツール、並列実行。このファイルは自制の話であり、ほとんどの能力リリースより注目された。

その差は示唆的だ。これらのツールに対価を払う人々は、ボトルネックはもうモデルにできることではなく、頼んでいないことをやめさせることだと結論づけた。22万5,000スターのMarkdownファイルは、不満がどこにあるかについて異例に明確なシグナルだ。

ラボにとっては少々気まずいシグナルでもある。このカテゴリで最もスターを集めたリポジトリが、モデルがすでにやっているはずの4つのことのリストなのだ。