- Cursorが数週間にわたり自律コーディングエージェントを並列実行し、大規模プロジェクトを完成できるかを実験
- 当初は動的コラボレーション構造を使ったが、ロック(lock)競合と作業の重複でボトルネックが発生
- その後、プランナー(Planner) と ワーカー(Worker) に役割を分離し、並列性と効率を大幅に向上
- この構造でWebブラウザをゼロから実装し、数百のエージェントが100万行以上のコードを作成
- 実験の結果、シンプルな構造と適切なプロンプト設計が長期自律コーディングのスケーリングの鍵だと判明
単一エージェントの限界
- 現在の単一コーディングエージェントは単純な作業には効率的だが、複雑なプロジェクトでは速度が遅い
- 複数エージェントを並列実行するのが自然な拡張方向だが、作業調整が難しい
- 初期には事前計画なしで動的コラボレーション方式を試行
- 各エージェントが他のエージェントの状態を見て、自ら次の作業を決める構造
協調学習の過程
- すべてのエージェントが同等の権限を持ち、共有ファイルを通じて作業を調整する構造を導入
- 各エージェントは他のエージェントの状態を確認し、作業を割り当てて状態を更新
- 重複防止のためロック(lock)メカニズムを使用
- 問題点
- エージェントがロックを長時間占有したり解放しなかったりして、全体速度が20台中2〜3台レベルまで低下
- ロック保持中に失敗したり、ロックなしでファイルを修正したりするなど、システムの不安定性が発生
- 楽観的同時実行制御(optimistic concurrency control) に切り替え
- 読み取りは自由にし、書き込みは状態変更時に失敗するよう設定
- シンプルで安定しているが、階層のない構造ではエージェントがリスク回避的な行動を示す
- 難しい問題を避けて小さな修正だけを繰り返し、進展のない作業ループが発生
プランナーとワーカー構造
- 役割を分けた階層型パイプラインへ移行
- プランナー(Planners) : コードベースを探索しながらタスクを生成し、必要に応じて下位プランナーを生成
- ワーカー(Workers) : 与えられたタスクだけを実行し、完了後に変更をプッシュ
- 各サイクルごとに判定エージェント(judge) が次の段階へ進むかを決定
- この構造により協調上の問題の大半が解決され、大規模プロジェクトへのスケーラビリティを確保
長期実行実験
- 実験目標: Webブラウザをゼロから実装
- 約1週間実行し、1,000ファイルに100万行以上のコードを作成
- 数百のワーカーが同時に同じブランチへプッシュしたが、競合は最小限
- 結果のコードはGitHubで公開済み
- 追加実験
- Solid → Reactマイグレーション: 3週間で +266K/-193K の変更、マージ可能性を確認
- 動画レンダリング改善: Rust版で25倍高速化し、ズーム・パン・モーションブラー機能を追加
- 該当コードはまもなく本番環境に反映予定
主な学習結果
- 数十億トークンを投入した結果、完全に効率的ではないものの、予想以上の成果を確認
- モデル選択が長期自律作業の核心
- GPT-5.2は集中力維持、指示追従、正確な実装で優秀
- Opus 4.5は早期終了する傾向
- GPT-5.2はGPT-5.1-codexよりプランナー役に適している
- 役割ごとに最適なモデルを選んで使用
- 複雑性の除去が性能向上に寄与
- 品質統合者(integrator)の役割はむしろボトルネックを生む
- ワーカー自身で競合解決が可能
- シンプルな構造が最も効果的
- 分散システム理論や組織設計モデルは一部しか有効でない
- 構造が少なすぎると競合・重複が発生し、多すぎると脆弱性が増す
- プロンプト設計がシステム挙動に決定的な影響
- 長期集中の維持、病理的行動の防止、協調の促進に重要な役割
今後の課題
- マルチエージェント調整は依然として難題
- プランナーがタスク完了時に自動で次の段階を計画するよう改善が必要
- 一部のエージェントは過度に長く実行されるため、定期的な再起動が必要
- しかし核心的な問い、すなわち「エージェントを増やせば自律コーディングを拡張できるのか」については
- 数百のエージェントが数週間協調しながら実際に進展できることを確認
- この技術は今後Cursorのエージェント機能に反映される予定
1件のコメント
Hacker Newsのコメント
Steve YeggeのWelcome to Gas Townに関連する作業をしているので、興味深く読んだ
最近共有したLLM予測記事では、2029年ごろにはAI支援コーディングでブラウザを作ることが驚きではなくなると書いたが、今回のCursorのプロジェクトはその2つ目の試みになる
別の例はこのReddit投稿で見られる
リポジトリのテストを自分で回してみたが、エラーと警告だらけで、CIもずっと前から失敗していた。こういう状態を「成功例」と呼んでいいのか分からない。完全自律コーディングよりも、人間中心の支援型アプローチのほうが現実的だと思う
なぜそのPRをまだマージしていないのか気になる。AIエージェント群が長期的に複雑なソフトウェアを完成させる未来は魅力的だが、今の例はあまりに弱い。人間との協業ポイントのほうが重要だ
段階的に難易度を上げながら実験しなかったのは惜しい。React CRUD → Paintクローン → ファイルマネージャー → ブラウザの順に徐々に拡張していれば、進歩の段階を明確に見られただろう
私も似たやり方でtjsを作った。世界最速かつ最も正確なJSON Schema Validatorで、git subtreeを活用したplanner/delegateパターンが効果的だった。標準とテストがよく定義されたソフトウェアなら、AIエージェントが素早く書き直して最適化できる
関連コマンドはspawn-perf-agents.mdで見られる
ブラウザをゼロから作るのは非常に難しいが、記事で提示された内容は詳細分析が不足していた。単に「コンパイルできる」というレベルなら意味は薄い。本当の検証は、次の変更を安定してマージできるかどうかだ
ブログによれば数兆トークンを使ったというが、OpenAI APIの単価で計算すると数千万ドル規模になる。このくらいなら、いっそブラウザチームに寄付したほうがよかったかもしれない
実際にビルドしてみたが、100件を超えるコンパイルエラーが出た。ほとんどのコミットがCI失敗状態で、実際には複数のオープンソースライブラリを組み合わせたものだった。
quickjs、wgpu、winit、egui、html parserなど既存のコンポーネントをそのまま使っていたのに、CEOは「カスタムJS VM」だと主張していて、誤解を招く
それでも、こうした統合をAIが自律的にやったという点は印象的だ
コードは非常に脆弱で不安定に見えた。たとえばrender_placeholder関数は、単にフレームバッファを埋めるための仮コードのように見える。
こうしたコードが実際にどんな役割を果たしているのか、またテストごとのトークン/時間コストがどれくらいなのか気になる