Cursor Agent SwarmはSQLテストスイートの80%に合格したが、より重要なのはアーキテクチャ
Cursorによると、新しいagent swarmは非公開のSQLテストスイートに4時間以内で80%合格した一方、従来のシステムは2時間を迎える前に失敗しました。この結果は、データベースのドキュメントだけを使用してSQLiteをRustで再構築するという難度の高い実験から得られたものです。
Cursor agent swarmが重要なのは、AIコーディングにおける競争の単位を変えるからです。競争はもはや、どのモデルが最も優れたコードを書くかだけに限られません。どのシステムが作業を分割し、コンテキストを保護し、競合を解決し、変更をレビューし、高価な推論リソースを効率的に配分できるかも含まれるようになりました。
これは、1つの高性能モデルを長時間稼働するコーディングループ内に置く手法を含め、単一エージェントのワークフローに圧力をかけます。また、同一のエージェントを緩やかに連携させたグループにも疑問を投げかけます。Cursorの中心的な主張は、最大の改善をもたらしたのは単純な並列処理ではなく、アーキテクチャだったというものです。
この結果は、独立したベンチマークではなく、依然として企業主導の実験です。Cursorはタスク、ハーネス、モデルの組み合わせ、評価プロセスを管理していました。それでも、このテストはマルチエージェントによるソフトウェア開発における新たな経済性を詳しく示しています。
Cursor Agent Swarmのテストで何が変わったのか
Cursorは、緩やかに連携するswarmを、戦略的な計画と集中的な実行を分離した階層型システムに置き換えました。
Cursorは7月20日付のagent swarm economicsに関する調査記事で、この実験について説明しています。同社は、以前のswarmの弱点を露呈させたタスク、すなわちSQLiteをRustでゼロから実装する課題に再び取り組みました。
エージェントには835ページのSQLiteマニュアルが提供されました。Cursorによると、SQLiteのソースコード、実行可能バイナリ、テストスイート、インターネットアクセスは与えられませんでした。そのためswarmは、記述された仕様を動作するデータベース実装へと変換する必要がありました。
Cursorは、もともとSQLite向けに作成されたデータベース非依存のテストシステムであるsqllogictestを使って、完成したソフトウェアを評価しました。公式のSQL testing documentationでは、データベースの出力を既知の正しい結果と比較する仕組みであると説明されています。
このスイートには、数百万件の生成されたクエリが含まれる場合があります。ステートメント、結合、フィルター、データ状態のさまざまな組み合わせにおいて、データベースが正しい答えを計算できるかを測定します。
これは、SQLiteのあらゆる特性を再現するよりも限定された目標です。Sqllogictestは、パフォーマンス、メモリ使用量、インデックス効率、トランザクション動作、ロック、完全な互換性を評価しません。
しかし、このベンチマークにも、広範で相互に作用する機能が求められます。データベースは、コンパイルに成功し、単純なステートメントを実行できても、結合、型の挙動、式、集約、状態変更では大きく失敗する可能性があります。
Cursorによると、新しいswarmはテストされたすべてのモデル構成で旧システムを上回りました。Grok 4.5が計画と実行の両方を担当した場合、新システムは4時間後に80%の合格率へ到達しました。
旧Grok 4.5 swarmは、最初の2時間で68,000件のコミットを生成しました。Cursorは、その動作が破壊的なループに陥ったため、2時間目が終わる前に実行を停止しました。
この対比こそが本当のニュースです。旧システムは目に見える活動をより多く行いましたが、成果の一貫性は劣っていました。大量のコミットは、有益な進展ではなく無駄な混乱を表していました。
同じ比較期間中、新しいハーネスが変更を生成する速度はより緩やかでした。安定したアーキテクチャを維持し、非公開テストに対する改善を続けました。
4つの新構成すべてにおいて、4時間後の結果は73%から85%の範囲でした。またCursorは、4時間の比較期間終了後、最終的にはすべての新構成がスイート全体に合格したと報告しています。
これらの後半の結果は、慎重に解釈する必要があります。Cursorによると、コードは近道や偏ったテスト対象がないか手作業でレビューされましたが、そのレビューを実施したのは同社自身です。また、エージェントは独立した再現チームによる検証も受けていません。
したがって、この実験が裏付けるのは特定の結論です。Cursorは、このタスクに対してより効果的な内部オーケストレーションシステムを構築しました。agent swarmが本番環境レベルのSQLiteを独力で再現できると証明したわけではありません。
この違いが重要なのは、データベースがクエリの正確性だけで成り立つものではないからです。本番ソフトウェアには、予測可能なパフォーマンス、耐久性、セキュリティ、互換性、保守性、そして長年にわたる敵対的なテストも必要です。
それでも、Cursor agent swarmは意味のある基準を超えました。多数の同時参加者を連携させながら、長大な仕様を実質的に動作するシステムへと変換しました。
計画役と実行役の分担が単純な並列処理を上回った理由
swarmが改善したのは、単に同時に働くエージェントが増えたからではなく、各エージェントが受け取る無関係なコンテキストが減ったからです。
Cursorはタスクをツリーとして整理します。ルートは全体目標を表し、各ブランチには段階的に範囲が狭くなる設計および実装の割り当てが含まれます。
プランナーエージェントは、そのツリーを分割して意思決定を行います。ワーカーエージェントは、具体的なコーディングとテストが行われる末端部分を担当します。
プランナーは、割り当てられたコンポーネントを実装しません。ローカルなデバッグの詳細でコンテキストウィンドウを埋めることなく、プロジェクトの構造、主要な制約、依存関係を保持します。
ワーカーは、システム全体を再設計しません。範囲が限定されたタスクを受け取り、利用可能なコンテキストを1つのコンポーネント、テストの失敗、または統合上の問題に費やせます。
この役割分担は、長時間稼働するエージェントに繰り返し見られる弱点に対処します。単一のエージェントは、増え続ける履歴を抱えながら、全体的な計画と局所的な実装を行き来しなければなりません。
履歴が増えるにつれて、モデルは以前の制約を見失ったり、古くなった試行に注意を浪費したりする可能性があります。システム全体を弱体化させながら、1つの関数だけを最適化してしまうこともあります。
プランナーとワーカーの構造は、その衝突を抑えます。戦略的なコンテキストはプランナーが保持し、戦術的なコンテキストはワーカーが保持します。
Anthropicは、自社のmulti-agent research systemで、関連するオーケストレーター・ワーカーパターンを文書化しています。リードエージェントが戦略を策定し、並列調査を専門化されたサブエージェントへ委任します。
Cursorはこのパターンをソフトウェア構築に適用しています。そこでは、出力が変化し続ける1つのコードベース内で共存しなければなりません。この要件により、複数の独立した調査要約を統合する場合よりも連携が難しくなります。
コードは共有状態を生み出します。あるエージェントが型の名前を変更したり、インターフェースを修正したり、ストレージの挙動を変えたりすると、ほかの多数のタスクが以前の設計に依存している可能性があります。
Cursorの以前のswarmは、この共有状態に苦戦しました。エージェント同士が変更を上書きし、概念を重複させ、ファイルを奪い合い、中核コンポーネントへのリスクの高い変更を避けていました。
新システムでは、それぞれの障害モードに対して明示的な仕組みが追加されました。プランナーは重要な決定を共有設計ドキュメントに記録します。依存するコードには、その決定へのコンパイル時に検証される参照が含まれます。
計画が競合すると、調整プロセスによってドキュメントが統合されます。修正された決定は、コンパイルエラーとその後の修正を通じて伝播します。
Cursorは、中立的なマージエージェントも導入しました。これらのエージェントは、どちらの貢献者の局所的な手法も擁護せずに衝突を解決します。
大規模なファイルには特別な処理が施されます。ワーカーは過負荷になったファイルを報告でき、その後システムは別のエージェントがファイルをより小さなモジュールに分割するまで、新たな変更をブロックします。
swarmは、管理された破壊的変更を許可することもできます。エージェントは理由を記録すれば、通常の担当範囲外にある中核コードを変更できます。
すると、依存するコンポーネントのビルドが失敗します。ほかのエージェントはその説明を確認し、新しい決定に合わせて担当部分を更新します。
このプロセスでは、コンパイラエラーを連携メッセージとして扱います。すべてのエージェントがすべての会話を保持しなくても、環境が設計変更の影響を伝えます。
Cursorはこの考え方を、参加者が共有環境を変更することで連携するスティグマジーと関連付けています。同社のField Guideは、蓄積された知識に同じ原則を適用しています。
Field Guideは、インデックスが新しいエージェントに提供される、厳選されたフォルダーです。エージェントは、予想外の教訓、繰り返し発生する落とし穴、有用な規約を、固定された行数制限内で記録します。
この制限は重要です。共有メモを無制限にすると、階層構造が防ごうとしたコンテキスト過負荷を最終的に再現してしまいます。
代わりに、エージェントはどの発見を継続的に注目すべき情報として残すかを判断しなければなりません。保持される知識の質が上がれば、その後の作業時間を短縮できるはずですが、Cursorはこの効果を個別に測定した結果を公開していません。
コンテキスト管理の観点から見ると、このCursor agent swarmは群衆というより組織に近いものです。役割、意思決定の記録、レビュー、所有権、仲裁によって個々の行動が制約されます。
単純な並列処理も依然として有用ですが、主要な仕組みではありません。ワーカーが増えると、生産的な作業と連携上の失敗の両方が増幅されます。
新しい設計は、実装能力に合わせて連携能力も拡大させようとしています。これは、追加のエージェントセッションを開始するよりも難しいエンジニアリング課題です。
Cursor Agent Swarmの経済性は専門化されたモデル構成に有利
Cursorが示した最も重要な経済的知見は、トークンの大部分が実行に使われる一方、最も難しい推論は比較的少数の計画上の決定に集中しているように見えることです。
Cursorは4つの主要な構成をテストしました。2つは計画と作業に同じモデルを使用し、残る2つは、より高性能なプランナーと高速なワーカーモデルを組み合わせました。
この実験における最終的な品質水準は、全体としてほぼ同等でした。しかし、必要なリソースは異なっていました。
報告されたすべての実行で、ワーカーは少なくとも69%のトークンを消費しました。ほとんどの構成では、その割合が90%を超えました。
この分布は、チームがモデル選択を考える方法を変えます。すべてのタスクに最も高性能なモデルを適用すると、反復的な実装に高価な推論能力を費やすことになります。
多くの末端タスクでは、新しいアーキテクチャは必要ありません。必要なのは、明示されたインターフェースに従うこと、範囲が限定された機能を追加すること、テストを実行すること、または局所的な不具合を修正することです。
高性能なプランナーは、タスクがワーカーに届く前に曖昧さを減らせます。仕様が具体化されれば、より低コストなモデルでも実行できます。
その結果は、コンパイラのパイプラインに似ています。高水準の目標が段階的に小さな指示へ落とし込まれ、各単位が直接実行可能な形になります。
ただし、この比喩には限界があります。従来のコンパイラは決定論的な変換を適用します。agent swarmは、あらゆる段階で確率的なモデルを使用します。
そのためCursorは、計画ツリーをレビューと調整の仕組みで取り囲んでいます。これらのシステムは、分解や実装の過程で意味が変化した場合に、それを検出しようとします。
Cursorによると、レビューには相当な計算資源が使われました。同社は、完成した作業の確認には作成よりも労力がかからないため、レビューは依然として効率的だと主張しています。
Cursorは、1つの万能なレビュアーを信頼するのではなく、複数のレビュー視点を使用しました。一部のエージェントはトランスクリプトを調べ、別のエージェントは出力を検査し、さらに別のエージェントは変化し続けるコードベースだけを評価しました。
異なるモデルとプロンプトにより、相関性の低い判断も得られました。あるレビュアーはインターフェースの逸脱を見つけ、別のレビュアーは不完全な動作や不適切に配置された複雑性を特定する可能性があります。
これは、マルチエージェントコーディングに対する一般的なイメージを正す重要な点です。有用なシステムとは、エージェントで満たされた部屋で可能な限り速くコードを書くことではありません。
これは、計画、実装、レビュー、競合解決、記憶、検証を備えた、統制された生産ラインです。追加される各工程はリソースを消費しますが、下流で発生するより大きな失敗を防ぐことができます。
OpenAIは、Symphony orchestrationを通じて、異なるオーケストレーション層について説明しています。このシステムは、プロジェクト管理タスクを継続的に稼働するコーディングエージェントと人間によるレビューに接続します。
Symphonyは、課題キューをエージェントの作業へ変換することに重点を置いています。Cursorの実験は、単一の野心的なプロジェクト内におけるタスク分解と共同実装へ、さらに深く踏み込んでいます。
どちらのシステムも、同じ市場圧力を示しています。コーディング製品は今後、モデルへのアクセスだけでなく、オーケストレーション、可観測性、レビューをめぐって競争するようになるでしょう。
モデルプロバイダーも、より複雑な購買パターンに直面します。チームは、アーキテクチャにはあるモデル、実装には別のモデル、レビューにはさらに別のモデルを選ぶ可能性があります。
これにより、1つのモデルがすべてのカテゴリーで勝たなければならないという前提が弱まります。モデルは、1つの役割を一貫して果たすことで経済的価値を持つことができます。
高速なワーカーモデルは、一般的なコーディングベンチマークで首位に立たなくても、利用を拡大できる可能性があります。フロンティアモデルは、より少数ながらレバレッジの高い意思決定を行うことで価値を維持できるでしょう。
このアーキテクチャは、新たな最適化問題も生み出します。プランナーがわずかに優れていても、実行全体が自動的に効率化されるわけではありません。
Cursorは、プランナーの振る舞いが下流へ流れる作業量に影響することを発見しました。使用するトークンが少ないプランナーでも、ワーカーの消費量を増加させる指示を生成する可能性があります。
したがって、チームにはシステムレベルの測定が必要です。モデル単体の速度、ベンチマークスコア、トークン効率だけでは、マルチエージェント実行の総コストを予測できません。
重要な単位は、完了してレビュー済みのタスクになります。この単位には、失敗した試行、マージの解決、テストの反復、レビュアーの作業、人間の介入が含まれます。
これはエンジニアリングリーダーに実務的な影響を及ぼします。一見低コストなワーカー群でも、計画によって重複タスクや不安定なインターフェースが生じれば、無駄が増える可能性があります。
高性能なプランナーもボトルネックになり得ます。すべての意思決定が1つの高コストなモデルを待つ場合、並列実行の規模が計画層の処理能力を上回る可能性があります。
Cursorは、プランナーとワーカーの組み合わせを網羅した完全なマトリクスを公開していません。また、成熟したリポジトリでも同じ順位が維持されるかどうかを示していません。
それでも、同社の結果は購入者により明確な問いを提示しています。高コストな推論がどこで結果を変えるのかを見極め、無差別な使用を避けるべきです。
80%というSQLの結果が証明していないこと
高いテスト合格率は機能面での進歩を示す証拠ですが、それだけでエンジニアリング品質や本番運用への準備が整っていることを証明することはできません。
Cursorは、有用なホールドアウト評価を選択しました。エージェントにはsqllogictestスイートが提供されておらず、同社によれば、各実行後に近道が使われていないかを手作業で確認しています。
こうした統制により、ベンチマークを直接攻略する余地は減ります。しかし、測定上の懸念がすべて取り除かれるわけではありません。
Sqllogictestが問うのは、エンジンが正しい結果を返すかどうかです。そのドキュメントでは、パフォーマンス、リソース使用量、トランザクション動作、並行処理、ロックが明示的に対象外とされています。
したがって、実際のアプリケーションには不向きなままでも、実装が高いスコアを獲得する可能性があります。低速なアルゴリズムを使用したり、メモリをリークしたり、クラッシュを適切に処理できなかったり、安全でない並行処理動作を露呈したりする可能性があります。
80%という数字も、1つのスイートにおける一部の割合を示しているにすぎません。システムがSQLiteの80%を再構築した、あるいは本番機能の80%に匹敵したという意味ではありません。
そのような表現は、性質の異なる単位を混同することになります。テストカバレッジはクエリの分布に依存しますが、製品の完成度には評価器の対象外の動作も含まれます。
最終的な100%という結果にも、同様の注意が必要です。含まれるすべてのテストに合格したということは、テストされたすべての結果に一致したことを意味します。SQLiteの完全なセマンティクスと運用実績を再現したことを意味するわけではありません。
Cursorは、この制約の一部を認めています。同社は以前のブラウザプロジェクトについて、洗練されたソフトウェアにはほど遠い概念実証だったと述べています。
このブラウザ実験が重要なのは、大規模なスウォームの魅力と弱点の両方を示しているからです。完成品を生み出さないまま、膨大な量のコードを生成できてしまいます。
SQLiteのテストは、定量的な目標を定めることで、以前の実証を改善しています。それでも、保守性と運用適合性の検証は後に残されています。
Cursorは、単独で生成された実装の1つを一般公開し、検証できるようにしました。また、そのコードについては初期レビューしか行っていないとも述べています。
独立したメンテナーは、アーキテクチャ、未定義動作、テストの欠落、安全でないRustの使用、文書化されたSQLiteの動作との乖離を調査すべきです。実行を繰り返せば、結果が安定しているかどうかも明らかになります。
評価研究も、慎重になるべき別の理由を提示しています。MicrosoftのAgentLens studyは、複数のモデルバックエンドにわたる2,614件のソフトウェアエージェントの軌跡を調査しました。
評価サブセット内の合格軌跡のうち、研究者は10.7%を「Lucky Passes」と分類しました。これらの実行は、回帰サイクル、闇雲な再試行、検証の欠如、順序の乱れた作業を経て正しい結果に到達していました。
ここから得られる教訓は、Cursorの実行が幸運だったということではありません。その結論を裏付ける独立した証拠はありません。
教訓は、最終的な合格率だけではプロセスの品質を説明できないということです。2つのシステムがまったく異なる経路をたどりながら、同じスコアに到達する可能性があります。
Cursorの比較は、実際にその点を補強しています。旧スウォームは破壊的なループに陥りながら、数万件ものコミットを生成しました。活動量だけを見ていると、連携の悪化が隠されてしまいました。
新しいシステムは、設計記録、レビュー、構造化された調整を通じて、プロセスの健全性を可視化しようとしています。しかしCursorは、外部の研究者がそれらの仕組みを十分に評価できるだけの実行レベルのデータを公開していません。
再現性も未解決の問題です。同社が報告したのは4つの構成にわたる1回の比較サイクルであり、信頼区間を伴う大規模な統計サンプルではありません。
モデルは確率的な意思決定を行うため、AIエージェントの実行結果は変動します。後半で生じたアーキテクチャ上の誤りが、その後の数百件のタスクの方向を変える可能性があります。
複数回繰り返せば、報告された曲線が典型的な動作を表しているのか、好条件の軌跡なのかが分かります。また、プランナー間のばらつきも明らかになります。
成熟したコードベースでは、異なる課題が生じます。Cursorのエージェントは空のリポジトリから開始し、実装環境全体を制御していました。
既存のエンタープライズシステムには、文書化されていない前提、移行上の制約、外部サービス、古いテスト、人間の所有権の境界が存在します。エージェントは、組織的な影響を伴わずにそれらのシステムを自由に再構築することはできません。
セキュリティ上重要な作業には、別の懸念もあります。Cursorは、オープンソースソフトウェアの脆弱性を発見し、修復するためにスウォームを使用したと述べています。
これは有望な用途ですが、自動化された脆弱性対応には慎重な開示管理が必要です。欠陥をより速く発見するスウォームは、より大きなレビュー待ち行列を生み出したり、機密性の高い発見を露呈したりする可能性もあります。
障害がユーザーに影響を与える場合、生成されたパッチには人間による説明責任が必要です。中立的なマージエージェントはコードの競合を解決できますが、事業リスクを引き受けることはできません。
チームには、信頼できる組織的なコンテキストも必要です。エージェントは、過去の意思決定、インシデント履歴、顧客への約束、社内基準を理解しなければなりません。
検索可能なエンジニアリングナレッジベースは、そのコンテキストの維持に役立ちます。ただし、レビュー、アクセス制御、責任ある所有権の代わりにはなりません。
したがって、Cursorの結果に対する最も妥当な解釈は具体的なものです。階層化され、計測機能を備えたスウォームが、制約されたデータベース構築テストにおいてCursorの以前のハーネスを大幅に上回りました。
最も妥当性の低い解釈は、このスコアを、自律型スウォームが本番エンジニアリングチームを置き換えられる証拠とみなすことです。公開された証拠は、その主張を裏付けていません。
エージェントスウォームの準備が整ったかを示す3つのシグナル
次の段階は、再現性、既存リポジトリでの性能、実際の本番利用から得られる証拠によって評価されるべきです。
第1のシグナルは、SQLite実験の独立した再現です。Cursorはタスクの説明を提供し、関連コードを公開しており、外部分析への道を開いています。
信頼できる再現では、モデル構成ごとに複数回の試行を実施すべきです。スコア曲線、リソース消費量、失敗の分類、人間の介入を公開する必要があります。
研究者は、クエリの正しさ以外もテストすべきです。パフォーマンス、クラッシュからの復旧、トランザクション分離、メモリ安全性、互換性を調べることで、機能の幅にエンジニアリング上の深さが伴っているかが分かります。
繰り返し実行して同様の曲線と保守可能な実装が得られるなら、Cursorのアーキテクチャに関する主張はより強固になります。ばらつきが大きかったり、隠れた介入があったりすれば、その主張は弱まります。
第2のシグナルは、確立されたリポジトリ内での性能です。仕様から開始することで、プロフェッショナルなソフトウェア開発を支配する多くの歴史的制約を回避できます。
より強力なテストでは、成熟したオープンソースプロジェクト内の移行作業や横断的な機能をCursorエージェントスウォームに割り当てます。その後、メンテナーがレビュー負担と統合品質を評価できます。
有用な測定項目には、取り消された変更、流出した不具合、マージ競合、レビュー時間、人間による再構築を必要とした作業の割合が含まれます。
重要な指標は、生成されたコード量ではありません。既存システムに組み込まれた後も維持される、受け入れ済みの作業です。
このテストでは、プランナー・ワーカー階層が所有権を尊重しているかどうかも明らかになります。成熟したプロジェクトでは、公開インターフェースや基盤となる抽象化を変更する前に、協議が必要になることがよくあります。
スウォームがローカルの慣習を維持し、メンテナーの作業を軽減できれば、単一エージェント型のコーディング製品に圧力をかけるでしょう。エージェント数に応じてレビューコストが増加するなら、その優位性は縮小します。
第3のシグナルは、継続的な本番導入です。Cursorによれば、このシステムはすでにブラウザの構築、テストカバレッジの向上、脆弱性の修復、GPUカーネルの最適化、数十億の合成トークンの生成を行っています。
これらの例はCursorから提供されたものであり、比較可能な外部ベースラインがありません。次に役立つ証拠は、スウォームの活動と安定したエンジニアリング成果を結び付けるものです。
チームは、デプロイ頻度、インシデント発生率、ロールバック頻度、セキュリティ上の発見、エージェントによる変更のレビューに費やした時間を追跡すべきです。これらの指標は、実証の域を超えても速度が維持されるかどうかを示します。
本番利用では、モデルの専門化も試されます。組織は、1つのプランナーが数時間ではなく数日間にわたって、混成ワーカー群を確実に指揮できるかどうかを把握する必要があります。
人間の責任は引き続き中心的です。エンジニアは、システムが何を変更してよいのか、どのテストを合格基準とするのか、自動修復をいつエスカレーションする必要があるのかを決定しなければなりません。
新たに生まれつつある仕事は、1つのコーディングアシスタントにプロンプトを与えることだけではありません。意図の明確化、評価の設計、コンテキストの整備、自動化された組織の監督が含まれます。
この変化によって、Cursorの「作業単位としての仕様」という主張に重みが生まれます。精密な仕様は、拡大し続けるエージェント階層への実行可能な入力になります。
しかし、仕様に運用上の真実がすべて含まれることはほとんどありません。重要な知識は、会議、インシデントノート、過去のプルリクエスト、顧客との会話に存在することがよくあります。
それらの情報源を安全に接続するシステムが優位性を持つでしょう。スウォームが意図を維持できるのは、アクセスし、解釈し、検証できる範囲に限られます。
開発者にとって、当面の教訓は実践的です。エージェント数、コミット数、生成された行数を数えてマルチエージェントコーディングを評価してはいけません。
システムがどのように責任を分担しているかを問うべきです。意思決定をどう記録し、対立をどう解消し、リグレッションをどう検出し、コンテキストをどう制限し、完了した作業をどう測定するのかを検証してください。
エンタープライズ向けの購入者にとって、モデルの選択は意思決定の一層にすぎなくなりつつあります。オーケストレーションハーネスによって、モデルの能力が信頼できる成果へとどう変換されるかが決まります。
モデルプロバイダーにとって、専門化は機会を生み出します。最適なプランナー、ワーカー、レビュアー、調整役が、同じモデルである必要はありません。
Cursorの実験は、継続的な人間の判断なしにスウォームが本番環境向けソフトウェアを生み出せるかどうかについて、決着をつけるものではありません。しかし、調整アーキテクチャがモデルの活動量そのもの以上に重要になり得ることは示しています。
Cursorのエージェントスウォームが4時間でSQL目標の80%に到達したのは、誰が計画し、誰が実装し、意見の相違がどのように伝播するかをシステムが制約していたためです。
いま問われているのは、仕様が不完全で、リポジトリに履歴があり、障害が実際のユーザーに及ぶ状況でも、その構造が有効であり続けるかどうかです。コミット数ではなく、再現結果に注目してください。
