Karpathyのautoresearchとすべてを変えるエージェントループ
リポジトリ
Andrej Karpathyが今週autoresearchを公開した。(Xでの告知)
3つのファイル。1つのGPU。訓練コードを修正し、5分間の実験を実行し、結果が改善したか確認し、変更を保持または破棄し、ループするエージェント。1時間に約12回の実験。一晩で約100回。人間の介入はゼロ。
エージェントは眠らない。気が散らない。3回前の実験で何を試したか忘れない。ただループを回し続ける。
3つのファイル
アーキテクチャは徹底的にミニマルだ。
prepare.pyはロックされている。データ読み込みと評価のためのユーティリティ。エージェントは触れない。train.pyはエージェントが修正する唯一のファイルだ。モデル、オプティマイザ、訓練ループを含む。program.mdは人間がエージェントへの指示を書く場所だ。
最後のファイルが面白い。もうPythonをプログラムするんじゃない。エージェントに何を探索するか指示するmarkdownファイルをプログラムするんだ。エージェントがPythonを書く。
Karpathyの言葉: 「かつて、最先端のAI研究は肉のコンピュータによって行われていた... その時代はとっくに終わった。」
リポジトリよりパターンが重要な理由
autoresearch自体はデモだ。シングルGPU、トイモデル、分散訓練なし。Karpathyも今後どれだけサポートするか分からないと言っている。
しかし、それが示すパターンは本物だ。
明確な指標を持つ自律エージェントループ。 エージェントには最適化すべき1つの数値(バリデーションのbits per byte)がある。修正できるファイルは1つ。実験ごとの時間予算は固定。そして無限にループする。
このパターンはML研究以上のものに使える。明確な成功指標を定義でき、エージェントに制約されたアクション空間を与えられるドメインは、まさにこの方法で自動化可能になる。
我々が作るものとのつながり
autoresearchと呼ばなかっただけで、このパターンのバージョンを何ヶ月も動かしてきた。
Recursive Driftの自己読み取りフィードバックループは同じ仕組みだ。エージェントがSQLiteから過去3つの投稿を読む。ボイスを研究する。全文検索でトピックの重複をチェックする。新しいコンテンツを生成する。60以上の正規表現パターンで検証する。出力をスコアリングする。閾値以下ならリトライする。出力が次のサイクルの入力になる。
Karpathyのループ: コード修正 --> 訓練 --> 評価 --> 保持/破棄 --> 繰り返し。 我々のループ: 過去の出力を読む --> 生成 --> 検証 --> スコアリング --> 繰り返し。
同じアーキテクチャ。異なるドメイン。出力が入力としてフィードバックされるから、どちらも時間とともに複利する。
違いは、Karpathyが数値指標(bits per byte)を最適化するのに対し、我々はボイスの一貫性とサブスタンス密度を最適化すること。彼のループはH100で動く。我々のループはMac MiniとClaude Codeサブスクリプションで動く。
ビルダーがここから学ぶべきこと
3つ。
1. markdownをプログラミング言語として使うパターンは本物だ。 program.mdはREADMEじゃない。実際のコントロール層だ。コードを書くことから、コードを書くエージェントへの指示を書くことへのシフトは、あらゆるレベルで起きている - Karpathyの ML研究から、コンテンツパイプラインから、GTM自動化まで。
2. 制約こそが機能だ。 3つのファイル。1つの指標。5分間の実験。問題空間がイテレーションできるほど狭いから、エージェントは機能する。エージェントに無限のスコープを与えれば、彷徨う。1つのファイルと1つの数値を与えれば、最適化する。
3. ループがプロダクトだ。 モデルじゃない。訓練コードじゃない。エージェントフレームワークじゃない。ループ - 仮説を立て、テストし、評価し、イテレーションする - こそが複利的な結果を生む。ループの中の具体的なツールは交換可能だ。ループ自体がアーキテクチャだ。
Karpathyはデモを作った。その背後にあるパターンはインフラだ。
エージェントシステムを構築しているなら、コードよりも制約設計を研究すべきだ。リポジトリはMITライセンス。パターンは無料だ。