Cursor Agent Swarm、ツリー分解によりRustでSQLiteを構築し、テスト合格率80%を達成
Cursorによると、同社のagent swarmは4時間以内にRustでSQLiteを構築し、テスト合格率80%を達成した。このシステムはツリー分解を採用し、計画と実装を異なるエージェントに割り当てた。以前のswarmは競合から抜け出せなくなり、2時間目を終える前に停止された。
この結果が重要なのは、Cursorが単に1つのリポジトリ内へ、より多くのコーディングエージェントを配置したわけではないからだ。同社は、エージェントによる作業の分担、アーキテクチャ上の決定の保持、衝突の解決、蓄積されたコードのレビュー方法を変更した。したがって、この実験はモデルの知能と同じくらいオーケストレーションを検証するものとなっている。
Cursorの以前のswarmは、すでにブラウザエンジンをゼロから構築していた。そのプロジェクトでは動作するソフトウェアが生まれたが、完成度には程遠い状態だったことをCursor自身が認めている。SQLiteの実験では、より明確な問いが提示される。数百のエージェントが密結合した1つのシステムを変更する間、構造化されたswarmは一貫性を維持できるのか。
その問いに対する答えは、まだ出ていない。実験の実施と評価はCursor自身が行っており、見出しとなった結果を確認する独立監査も行われていない。また、1つのSQLテストスイートで80%を獲得しても、SQLiteとの完全な互換性、本番環境での安全性、同等のパフォーマンスが証明されるわけではない。
それでも、この比較はAIソフトウェア開発で拡大する問題について、珍しく具体的な証拠を提示している。エージェントを追加すれば成果物は増えるが、意見の不一致も増加する。Cursorの答えは、制御された階層の中で計画、実行、調整、レビューにそれぞれ異なる役割を与えることだ。
CursorのAgent Swarm、RustによるSQLite構築で80%を達成
重要な変化はswarmの規模拡大ではなく、局所的な決定がプロジェクト全体を圧倒しないようにswarmを編成したことだった。
Cursorは、以前のシステムが達成できなかった課題に再挑戦した後、2026年7月20日に結果を公開した。課題は、データベースのドキュメントを仕様として使用し、RustでSQLiteを再構築することだった。
Cursorのswarm実験によると、エージェントには835ページのSQLiteマニュアルが与えられた。SQLiteのソースコード、実行可能バイナリ、テストスイート、インターネットアクセスは与えられなかった。Cursorによれば、この分離によって直接的なコピーを防ぎ、可視化されたテストに合わせて最適化する余地を減らしたという。
チームは、完成したデータベースをsqllogictestで評価した。このフレームワークは複数のデータベースエンジンでSQL文を実行し、その結果を既知の正解と比較する。テストフレームワークには、幅広いSQLの動作を網羅する数百万件のクエリが含まれている。
swarmはCursorがどのテストを使用するかを知らされていなかった。各実行後、Cursorの研究者はコードとエージェントの活動の両方を調査し、抜け道が使われていないかを確認したという。また、実装作業が想定されるテストケースだけを狙うのではなく、システム全体を幅広くカバーしているかも確認した。
この条件下で、新しいGrok 4.5 swarmは4時間後にSQLテスト合格率80%を達成した。旧Grokベースのswarmは、連携の失敗が加速していたため、2時間が経過する前に停止された。
4時間という時点は、最終的な上限ではなかった。4種類のモデル構成において、新しい実行はその時点で73%から85%のスコアを記録した。Cursorによると、新しい構成はすべて、最終的に非公開のテストスイートで100%に到達した。
これらの後続結果を踏まえると、タイトルにある80%という数値は、実験で報告された最高スコアではなく進捗の指標である。それでも、固定された時間内に同じモデルを2つのオーケストレーションシステムで比較できるため、有用な数値であることに変わりはない。
Cursorは4つの構成をテストした。2つは計画と実装の両方に同じモデルを使用した。残る2つは、最先端の計画モデルと、より高速なワーカーモデルを組み合わせた。
新しいswarmは、テストされたすべての構成で旧ハーネスを上回った。この一貫性は、モデルの選択だけでなく、システム設計がパフォーマンスに影響したというCursorの主張を裏付けている。
ただし、この証拠はCursor独自のベンチマークプロセスから得られたものだ。同社は生成された実装の1つをMiniSQLiteリポジトリで公開しているが、すべての実行を完全な再現用パッケージとして公開してはいない。
このリポジトリにより、外部の開発者は少なくとも1つの成果物を検証できる。しかし、インフラストラクチャ、プロンプト、モデルのスナップショット、非公開の評価データ、手動レビューの判断を含む実験全体を再現することはできない。
この違いは重要だ。Cursorが報告したのは説得力のある社内結果であり、独立して立証されたSQLiteの代替品ではない。
ツリー分解が連携モデルを変えた
ツリー分解は、全体的な判断と限定的な実装作業を分離し、swarmに責任の連鎖を与えた。
Cursorの設計は、ルートとなる目標から始まる。プランナーエージェントがその目標をより小さな枝へ分割し、それぞれの枝を再帰的に委任する。ワーカーエージェントは葉の部分で作業する。そこでは、タスクが直接実装できる程度まで限定されている必要がある。
プランナーは本番用コードを書かない。そのコンテキストは要件、依存関係、アーキテクチャ上の選択、タスクの境界に集中したまま維持される。ワーカーはシステム全体を再設計しない。限定された割り当てを受け、その作業にコンテキストを使用する。
この構造は、長時間稼働するエージェントにありがちな失敗パターンに対処する。単一のエージェントは、増え続ける実装の詳細を扱いながら、当初の目標を記憶していなければならない。コンテキストが埋まるにつれて、局所的な精度か全体的な方向性のいずれかを失う可能性がある。
並列エージェントがその問題を自動的に解決するわけではない。連携がなければ、同じ機能を重複して作成したり、互換性のないインターフェースを選択したり、互いの作業を上書きしたりする可能性がある。その場合、並列性を高めるほど修復作業も増える。
ツリー分解は、各種類の決定を下せるエージェントを制限する。Cursorは、共有される設計上の問題を独立したワーカーに委任せず、プランナーが解決することを求めている。また、同じアーキテクチャ上の選択を複数の枝に割り当てないよう、プランナーに求めている。
この分業によって、構造化されていない集団が階層へと変わる。システムは依然として多数のエージェントを使用するが、すべてのエージェントがプロジェクトのあらゆる部分に対して同等の権限を持つわけではない。
新しいswarmは、重要な決定を共有設計ドキュメントにも記録する。それらの決定に依存するコードには、ドキュメントへのコンパイル時に検査される参照が含まれる。2人のプランナーが矛盾した場合、調整エージェントが決定を統合し、解決策を全体へ反映できる。
この仕組みは、Cursorがスプリットブレイン設計と呼ぶ問題に対処する。スプリットブレインは、別々のプランナーが同じ概念の異なるバージョンをコードベース全体に実装したときに発生する。それぞれのバージョンは局所的には妥当に見えても、システム全体では不整合を引き起こす可能性がある。
SQLiteの実行では、その違いが明らかになった。旧Grok swarmは54個のRust crateにまで拡大し、その中には3つの別々のSQLパッケージが含まれていた。crateはRustのパッケージ単位であり、通常はライブラリや主要コンポーネントを表す。
新しいswarmは早い段階で9個のcrateに落ち着き、それ以上追加しなかった。構造が小さいからといって、自動的に優れたソフトウェアになるわけではないが、プランナーが1つのアーキテクチャに収束したことを示している。
Cursorは、生の同時実行性よりもコンテキスト効率の方が重要だったと主張している。各プランナーはより上位の視点を維持し、各ワーカーは範囲が定められた1つのタスクを実行するのに十分なコンテキストを受け取った。この階層により、タスクの複雑さに応じてコンテキストも拡張された。
これはコンパイラのパイプラインに似ている。高水準の仕様が中間表現を通過し、最終的に実行可能な出力へ変換される。Cursorのswarmは、意図をタスクツリー、実装の割り当て、調整済みの変更、レビュー済みのコードへ変換する。
コンパイラとは異なり、すべての変換には確率的な性質が残る。プランナーが仕様を誤解する可能性がある。ワーカーが割り当てを読み違える可能性がある。レビュアーが誤った実装を承認する可能性もある。
周囲の制御は、それらのエラーを減らすために存在する。しかし、プロセスを決定論的にすることはできない。
エンジニアリングチームにとって、実践的な教訓はこのベンチマークよりも広い。エージェントのパフォーマンスは、要件、決定、例外が適切な範囲で参照可能な状態を保てるかどうかに左右される。検索可能なナレッジベースは、人間主導の作業で同様の目的を果たす。
Cursorのagent swarmがRustでSQLiteを構築し、テスト合格率80%を達成できたのは、階層によって各エージェントが知る必要のある範囲を限定したからだ。この結果は、自律型コーディングにおいてオーケストレーションが中心的なエンジニアリング分野になることを示唆している。
旧Swarmが生み出したのは、安定した進捗ではなく活動量だった
Cursorの比較は一般的な想定を覆している。エージェントの活動量が多いことは、生産性ではなく連携の失敗を示す場合がある。
旧Grok 4.5の実行は、最初の2時間で68,000件のコミットを生成した。Cursorによれば、これは新しい実行のペースのおよそ70倍だった。表面的なダッシュボードでは、旧swarmの方が劇的に活発に見えただろう。
しかし、周辺の証拠は異なる状況を示している。旧システムでは、Cursorが停止するまでに70,000件を超えるマージ競合が蓄積した。新しい実行で4時間を通して記録された競合は1,000件未満だった。
旧実行では、競合の発生頻度も加速した。エージェントは固定された統合バックログに対処していただけではない。リポジトリが変化するにつれて、より速いペースで意見の不一致を生み出していた。
あるファイルは、特に深刻なボトルネックとなった。Cursorによると、1,173のエージェントがそのファイルに触れ、7,771件の競合が発生した。新しい実行で最も競合が多かったファイルでは、47件の競合が発生した。
これらの数値は連携の崩壊を表している。ワーカーは共有された所有権、安定した境界、同時進行の変更を効率的に取り込む方法がないまま、同じ領域へ繰り返し入り込んでいた。
通常のGitワークフローは、その速度を想定して設計されていない。人間のチームはプルリクエスト、コードオーナーシップ、レビューキュー、会話に依存している。自動化されたワーカーが変更を継続的に生成すると、それらの仕組みは現実的でなくなる。
Cursorによると、以前のブラウザswarmはGitを使用し、1時間あたり約1,000件のコミットでピークに達した。新しいインフラストラクチャは、1秒あたり約1,000件のコミットでピークに達することができる。この負荷を処理するため、同社は専用のバージョン管理システムをゼロから構築した。
このシステムはパッチを保存するだけではない。衝突が表面化し、専門化されたエージェントが介入できるレイヤーとなる。
2つのワーカーが重複するコードを編集した場合、Cursorはどちらかのワーカーが相手のコンテキスト全体を取り込むことを期待しない。中立的なマージエージェントが、両者に代わって衝突を解決する。その役割は統合であり、機能の所有ではない。
swarmは、変更があまりにも多くのワーカーから集中する「メガファイル」も監視する。エージェントが肥大化したファイルを検出すると、別のエージェントがそのファイルをより小さなモジュールへ分割する間、システムは追加のコミットをブロックする。
この対応が重要なのは、ファイル構造が連携のインフラストラクチャになるからだ。モジュール境界は可読性を向上させるだけではない。同じ成果物をめぐって競合するワーカーの数を減らす。
Cursorはまた、エージェントがコアコードの変更を避ける傾向にあることを発見した。コーディングモデルは、特に既存のリポジトリ内では、小規模で破壊的でないパッチを好む慣習を学習している。
その慎重さによって、欠陥のある基盤が温存される場合がある。そのためCursorは、コア設計の修正が必要な場合、エージェントが割り当てられた範囲外で、焦点を絞った破壊的変更を行うことを認めている。
エージェントは変更のそばに説明を残す。その後、コンパイラエラーによって影響を受けるワーカーがその説明へ誘導され、依存するコードを更新できる。
このアプローチでは、Rustの型システムを調整チャネルとして利用します。コンパイラは互換性のないインターフェースを迅速に明らかにし、対処可能なエラーを提供します。これらのエラーは、グローバルな決定によってローカルな前提が無効になった箇所をエージェントが発見するのに役立ちます。
初期のスウォーム実験に対する独立したアーキテクチャ批評では、まさにこの課題が指摘されていました。個々には有能なエージェントでも、ローカルには合理的な選択を行いながら、グローバルにはうまく統合できないことがあります。共有されたモデルの挙動が生むのは相関であって、調整ではありません。
Cursorの新しいアーキテクチャは、その批判に対する回答として設計されているように見えます。グローバルな意思決定権限、永続的な設計記録、専門化された調整、自動化された強制機構が追加されています。
そのため、「スウォーム」という用語はやや誤解を招きます。この設計は、調整が自然に創発する独立した対等なエージェントの集まりではありません。階層、規則、記録、強制機構を備えた管理組織です。
この違いは実験の価値を損なうものではありません。むしろ、なぜパフォーマンスが向上したのかを説明しています。
レビューと共有メモリがエラーの連鎖的な増大を防いだ
ツリー分解によって明確な割り当てを作成できますが、継続的な進捗は、他のエージェントが誤りの上に作業を積み重ねる前に、その誤りを発見できるかどうかにかかっています。
長期にわたるソフトウェア開発では、初期のエラーが連鎖的に増大します。誤ったインターフェースが数十のモジュールに広がることがあります。一時的な回避策が、前提となる要件に変わることもあります。脆弱な抽象化の周囲にコードが増え続け、置き換えのコストが高くなる場合もあります。
Cursorは、作業に対して異なる視点を持つ複数のレビューエージェントを使用しました。一部のレビュアーにはワーカーのトランスクリプトが渡されました。他のレビュアーはその出力のみを確認するか、ワーカーの推論を知らずに周辺のリポジトリを調査しました。
単一の視点ですべての欠陥を発見することはできませんでした。トランスクリプトは意図を説明できますが、レビュアーを元のアプローチに偏らせる可能性もあります。出力のみのレビューは距離を保てますが、意思決定の理由を見落とすことがあります。
Cursorによれば、相関の少ない複数のレビュー視点を組み合わせることで、品質を継続的に向上させられたとのことです。同社は、既存の作業を確認する方が失敗したブランチを作り直すより低コストだったため、レビューに費やした計算資源には十分な価値があったと考えています。
この主張を他の変更から切り離して評価することは、依然として困難です。Cursorはタスク分解、バージョン管理、マージ処理、アーキテクチャ記録、レビューの挙動を同時に変更しました。この実験からは、それぞれの要素がどの程度改善に寄与したかは分かりません。
スウォームは共有のField Guideも維持していました。このエージェント管理のフォルダには、後続のワーカーが知っておくべき教訓が保存されていました。各エージェントの起動時に、そのインデックスがエージェントのコンテキストへ挿入されました。
Cursorは行数制限を設け、エージェントがすべてを蓄積するのではなく、情報を厳選するよう促しました。このシステムでは、後続ワーカーの作業経路を短縮できる意外な発見が優先されました。
これはスティグマジーの一種であり、共有環境の変化を通じた調整を意味します。アリのコロニーは、後の行動に影響を与えるシグナルを残します。Cursorのエージェントは、ドキュメント、コード参照、コンパイラエラー、運用上のメモを残します。
Field Guideは、モデルベースのエージェントが持つ根本的な制約に対処します。実行中にモデルの重みは変化しません。外部記録がなければ、あるワーカーの発見は、そのコンテキストが終了した時点で失われます。
永続的なメモが正確な記憶を保証するわけではありません。エージェントが誤った結論を記録したり、古くなった回避策を残したり、特殊なケースを過度に重視したりする可能性があります。そのため、他の共有成果物と同様に、ガイドにも保守とレビューが必要です。
同じ課題は、人間のエンジニアリング組織にも見られます。チームには、アーキテクチャ上の決定、実装上の制約、予期しない挙動の記録が必要です。そうでなければ、各コントリビューターが同じ調査を繰り返すことになります。
エンジニアリングワークフロー向けに設計されたツールは、人間がそのコンテキストを保持するのに役立ちます。Cursorの実験は、自律型チームでは構成員が絶えず入れ替わるため、さらに厳格な仕組みが必要であることを示唆しています。
コードの指標は、これらの制御が一貫性に影響したことを示しています。あるモデルの組み合わせでは、旧スウォームが完全なテストスイートに合格するために64,305行のエンジンコードを必要としたのに対し、新スウォームは9,908行で合格しました。
別の組み合わせでは、旧ハーネスで19,013行のコードが生成され、スコアは97%でした。新ハーネスでは、4,645行で100%に達したと報告されています。
行数が少ないからといって、必ずしも優れたソフトウェアであるとは限りません。コンパクトなコードが、安全対策の欠如、狭い前提、不完全な機能を覆い隠す場合があります。しかし今回は、テスト結果とアーキテクチャの集約度が同じ方向に改善しました。
スウォームの出力は、戦略によっても異なりました。一部の実行では広範な基盤を構築したため、数時間にわたって低いスコアが続いた後、急激に改善しました。他の実行では限定的なSQL機能を早期に実装した後、不足部分を埋める間に伸び悩みました。
この違いは、ある一時点の単一スコアが誤解を招き得ることを示しています。Cursorは、すべての中間パーセンテージを生産性の直接的な順位として扱うのではなく、全体的な推移に注目するよう勧めています。
したがって、CursorのエージェントスウォームがRustでSQLiteを構築し、テスト合格率80%に到達したという結果は、単なる並列実装以上のものを反映しています。レビューと永続的な共有メモリが、初期のエラーが恒久的なアーキテクチャになるのを防ぎました。
SQLスコア80%は、本番環境で利用可能なSQLiteを意味しない
このベンチマークは調整能力に関する主張を裏付けていますが、生成されたデータベースがSQLiteの信頼性、互換性、セキュリティに匹敵することを証明するものではありません。
Sqllogictestは、大量のクエリに対してデータベースエンジンが期待される結果を返すかどうかを確認します。そのため、幅広いSQLセマンティクスの測定には有用です。しかし、本番環境のユーザーがSQLiteに期待するすべての特性を網羅しているわけではありません。
SQLite独自のテストプログラムには、複数のテストハーネス、広範な境界値チェック、障害シミュレーション、ファジング、長期的な回帰テスト基盤が含まれています。クエリ結果の正しさは、その保証プロセスの一部にすぎません。
データベースは、クラッシュ時にもデータを保持し、トランザクション保証を維持し、破損したファイルを安全に処理し、複数のプラットフォームで一貫して動作する必要があります。また、同時実行、リソース制限、特殊なエンコーディング、不正な形式の入力にも対応しなければなりません。
パフォーマンスも重要です。論理的に正しいクエリエンジンでも、過剰なメモリを消費したり、現実的なワークロードで性能が低かったりすれば、実用にならない可能性があります。
Cursorは、生成されたプロジェクトがSQLiteを置き換えられる段階にあるとは主張していません。同社の記事は、この取り組みをスウォーム組織とモデルの経済性に関する実験として位置づけています。利用可能な証拠には、この限定的な解釈が適しています。
80%というスコアも、4時間経過時点のチェックポイントで得られたものです。Cursorによれば、すべての新しい構成が最終的に非公開テストスイートで100%に到達しましたが、1つのスイートに合格しても、新たな疑問が生じます。
独立した実行を何回行えば同等の結果が得られるのでしょうか。成功したアーキテクチャは、仕様の変更にも耐えられるのでしょうか。スウォームは、分裂状態を再発させることなく、自らの実装を拡張できるのでしょうか。
再現性は特に重要です。モデルの出力は、プロンプト、サンプリング、インフラストラクチャ、モデルのアップデートによって変化します。ベンチマークが一度成功しただけでは、その手法がどの程度の頻度で失敗するかをチームが把握することはできません。
Cursorは、同じモデル構成と時間予算を使用して、旧ハーネスと新ハーネスを比較しました。これにより、複数の変数が制御されています。しかし、外部の研究者が評価全体を独立して再実行するのに十分な資料を、同社は公開していません。
手動検査にも別の不確実性があります。Cursorによれば、研究者は不正、安易な近道、不均一な実装がないかを確認しました。これらの確認には価値がありますが、公開されていないレビュー基準を評価することは困難です。
この実験はRustの恩恵も受けています。そのコンパイラと型システムは、実行前に互換性のないインターフェースを検出します。Cursorは、依存するコンポーネント全体にアーキテクチャ変更を伝播させるため、コンパイラエラーを明示的に利用しています。
同様のスウォームが動的言語で作業した場合、即時に得られるフィードバックは少なくなるでしょう。一部の不一致は実行時にしか表面化せず、特殊な本番入力が現れるまで隠れ続けるものもあるかもしれません。
SQLiteは、仕様が極めて充実しているという特徴もあります。スウォームには期待される挙動を説明する数百ページの資料が与えられ、成熟した外部テストフレームワークによって出力を採点できました。
多くの商用システムには、こうした利点がありません。要件はチケット、会話、ダッシュボード、文書化されていない運用知識に分散したままです。成功基準が主観的であったり、互いに矛盾したりする場合もあります。
つまり、この実験が示しているのは、普遍的なレシピではなく、効果的なエージェントスウォームを実現するための条件かもしれません。仕様と検証環境が優れているほど、システムはより安全に実装を委任できます。
セキュリティについては、別途慎重に考える必要があります。Cursorは、このアーキテクチャをオープンソースプロジェクトの脆弱性発見に利用したと述べています。これは同社が報告した適用事例であり、スウォームが生成したセキュリティパッチが一貫して安全であることの証拠ではありません。
データベースエンジンは、信頼できない入力を処理し、永続的な状態を保護します。わずかなパーサーエラー、整数のエッジケース、トランザクションのバグが、数百万件の通常のクエリを通じても検出されないまま残る可能性があります。
適切な結論は、慎重なものです。Cursorは、制約付きベンチマークにおいて、同社のエージェントスウォームがRustでSQLiteを構築し、テスト合格率80%に到達したと報告しています。この証拠から、その出力を本番環境レベルのSQLite実装と呼ぶことはできません。
モデルの選択よりも役割の割り当てが重要だった
Cursorの結果は、最先端の知能が意思決定の局面で最大の価値を発揮する一方、実装が作業全体の大半を占めることを示唆しています。
同社は、1つの高度なモデルが計画と実行の両方を担当するシステムをテストしました。また、最先端モデルが計画し、より高速なモデルがそのタスクを実装するハイブリッドシステムもテストしました。
4つの新しい構成はいずれも、最終的には同程度のテスト結果を出しました。しかし、リソース消費量は、特に計画役とワーカー役の間で大きく異なりました。
すべての実行において、ワーカーは少なくとも69%のトークンを生成しました。ほとんどの構成では90%を超えていました。実装には反復的で局所的な作業が多く含まれるため、この分布は理にかなっています。
計画に必要なトークンは少なかったものの、影響力はより大きいものでした。プランナーは、アーキテクチャを選択し、仕様を分割し、担当範囲を割り当て、ワーカーがコードを変更し始める前に曖昧さを解消しました。
このレベルでの不適切な決定は、下流で数千もの不要なアクションを生み出す可能性があります。優れた決定は、不確実な設計問題を複数の明確な実装タスクに変えられます。
このパターンは、すべてのエージェントに利用可能な最高性能のモデルが必要だという考えに疑問を投げかけます。プランナーが曖昧さを効果的に減らせるなら、多くのワーカーは範囲の限定された指示に従い、コンパイラのフィードバックに対応するだけで済みます。
ハイブリッド構成の結果は、プランナーの効率を単独で評価できないことも示しています。あるプランナーは少ないトークンしか使用しなくても、ワーカーにより長い実装経路を強いるような割り当てを作成する可能性があります。
したがって、チームは作業の全軌跡を測定する必要があります。プランナーの品質には、その決定によって生じる下流の作業量、競合、修正量も含まれます。
Cursorの実験は、モデル選択を組織設計の問題へと変えます。アーキテクチャ判断に最適なモデルは、反復的な実装、マージ、テスト、レビューに最適なモデルとは異なる場合があります。
専門化は評価の改善にもつながります。マージエージェントは、統合のクリーンさで評価できます。レビュアーは発見した欠陥で評価できます。プランナーはブランチの独立性と下流の安定性で評価できます。
1つの汎用エージェントがすべての役割を担うと、フィードバックがより不明瞭になります。プロジェクトが失敗したとき、チームは計画の欠陥、実装能力の不足、レビュー不足を容易に区別できません。
新システムのアクティビティ率が低かったことも、この解釈を補強しています。旧スウォームよりコミット数は少なかったものの、それらのコミットでは競合が劇的に減少し、より集約されたアーキテクチャに貢献しました。
したがって、成果指標として重視すべきなのは、エージェントの動きではなく、受け入れ可能で安定した機能である。コミット数、トークン量、同時稼働ワーカー数はいずれも増加し得る一方で、有用な進捗は低下する可能性がある。
この原則は、コーディングエージェントのベンダーに圧力をかける。出力が保守可能なソフトウェアとして統合されるかどうかをオーケストレーションが左右するようになると、モデルへのアクセスだけでは差別化が難しくなる。
また、企業の購入担当者にも評価基準の変更を迫る。短いデモでは、エージェントがコードを書けることは示せる。しかし、複数エージェントのシステムが何時間にも及ぶ並行作業を通じて意思決定を維持できるかどうかは示せない。
購入担当者は、システムがアーキテクチャをどのように表現し、担当範囲を割り当て、推論を記録し、競合を解決し、完了したブランチを検証するのかを確認すべきである。また、途中で仕様が変更された場合に何が起きるのかも尋ねるべきだ。
Cursorのツリーモデルは、その一つの具体的な答えを示している。コストの高い判断をルート付近に配置し、大量の実装作業をリーフ付近に配置する。調整とレビューは、それらの階層の間で行われる。
この設計はソフトウェア組織に似ているが、機械の速度で稼働する。注目すべきなのは、エージェントがエンジニアリングの階層構造を置き換えたことではない。制約のない並列処理が失敗したため、Cursorが階層構造を再構築したことだ。
CursorのSQLite実験後に注目すべきこと
次の試金石は、Cursorが一度の管理されたベンチマークを、進化し続ける外部監査対象のコードベースにおける再現可能な性能へと転換できるかどうかである。
最初のシグナルは、独立した再現である。開発者には、プロンプト、ハーネスの動作、モデル識別子、採点プロセス、および生成された複数のリポジトリが必要だ。実行を繰り返すことで、一度の成功した軌跡だけでは示せないばらつきが明らかになる。
再現において、Cursor独自のインフラを完全に再構築する必要はない。同等のワークロードにおいて、階層的な計画が競合とアーキテクチャの重複を一貫して削減するかどうかを検証すべきである。
公開されているMiniSQLiteのコードは、その出発点となる。外部のレビュアーは、SQLの対応範囲、未対応の動作、安全でない前提、およびモジュール設計を精査できる。また、非公開のテストスイートを超えて、その動作をSQLiteと比較することもできる。
重大な不具合の証拠が見つかっても、調整能力に関する成果そのものが否定されるわけではない。ただし、その主張はデータベース実装から、ベンチマーク指向の機能合成へと限定されることになる。
2つ目のシグナルは、変化する仕様に対する性能である。Cursorの実験は、大規模で安定したマニュアルから始まった。現実のプロジェクトでは、開発者が実装している最中にも仕様が変化する。
有益な追試では、長時間の実行中に要件を変更することになるだろう。スウォームは、競合の多い混乱状態に逆戻りすることなく、共有された意思決定を修正し、古くなったタスクを無効化し、依存するブランチを更新する必要がある。
このテストは、システムの設計文書とField Guideに負荷をかけることになる。永続的なメモリが役立つのは、どの記憶が古くなったのかをスウォームが特定できる場合に限られる。
3つ目のシグナルは、より幅広い言語とリポジトリへの対応である。Rustはコンパイル時に強力なフィードバックを提供し、SQLiteには成熟した仕様と測定可能な出力がある。
信頼できる汎用システムであれば、動的言語のサービス、複数言語が混在するアプリケーション、文書化に一貫性のない既存リポジトリでも一貫性を維持できるはずだ。また、クエリの正確性だけでは評価できない運用要件にも対応しなければならない。
Cursorは、このアーキテクチャをブラウザ構築、脆弱性修正、テストカバレッジ、GPU最適化、数学、合成データ生成に適用したとしている。これらのタスクに関する詳細な評価があれば、ツリー分解が一般化できるかどうかが明らかになるだろう。
最も価値のある報告には、失敗した実行も含まれる。チームが知る必要があるのは、どのような場合に階層構造が依然として破綻するのか、どの競合が調整をすり抜けるのか、そしてレビュアーが局所的には正しいものの全体には有害な作業をどの程度の頻度で承認するのかである。
もう一つ有用な指標は、人間による介入である。研究者がプロンプトを繰り返し調整したり、ループを停止したり、要件を再解釈したり、インフラを修復したりしていても、スウォームは自律的に見える可能性がある。
Cursorは、以前のGrokによる実行を一時停止し、出力を手作業でレビューしたことを明らかにしている。今後の評価では、成功した実行と失敗した実行の両方について、介入の度合いを定量化すべきである。
保守性が、最も厳しい証拠をもたらすだろう。新しいリポジトリの構築では、レガシーな制約、後方互換性への責任、長年にわたり蓄積された設計上の意思決定を回避できる。
Cursorのシステムが数か月後に、動作とアーキテクチャを維持しながら、生成したデータベースへ大幅な変更を加えられるなら、その主張はより強固になる。大部分を再生成しなければならないのであれば、この手法は持続可能なエンジニアリングというより、合成に近いものに見える。
開発者にとって、直ちに得るべき教訓は、数千ものコーディングエージェントを導入することではない。オーケストレーション、仕様、共有コンテキスト、自動検証を、エージェント型開発の中核要素として扱うことである。
エンジニアリングリーダーにとっても、重要な問いは同様に実践的だ。互いに矛盾する前提を作り出すことなく、階層化されたエージェント群が行動できるほど正確に、組織の意図を表現できるだろうか。
同社の実験によると、Cursorのエージェントスウォームは、ツリー分解を通じてRustでSQLiteを構築し、テスト合格率80%を達成した。この結果は、より優れたコーディングエージェントさえあれば、大規模な自律プロジェクトが実現するという考えに疑問を投げかける。
新たに浮上している制約は、調整能力である。独立したレビュアーが結果を再現できるか、スウォームが要件変更に耐えられるか、そしてRustや例外的に完全な仕様を持つ環境以外でも機能するかに注目すべきだ。これらのシグナルによって、Cursorが構築したものが持続可能なエンジニアリングシステムなのか、それとも印象的なベンチマークマシンなのかが決まる。
