CursorのProjectsはエージェント開発に構造的な進化をもたらします。1人のコーディネーターが数千のコーディングエージェントを数週間から数ヶ月にわたり指揮し、作業の進行に合わせて状態とコンテキストを維持します。デフォルトではクラウド上で並列処理を行い、ハードウェアや環境の同一性が重要な場合はローカルエージェントを起動します。共有コンテキスト層は成果物、アーキテクチャノート、チームの好みを蓄積し、新規参加者(人間でもエージェントでも)が白紙の状態ではなく組織の知識をもってスタートできるようにします。サブスクリプション機能により、PRのオープン、CIの失敗、Slackの報告などのシグナルに基づいてコーディネーターが行動し、断続的なプロンプトを継続的な運用に変えます。実質的にコード作業のためのプロダクションコントロールプレーンと言えます。
重要なのはスループットと完了率です。コーディネーターが依存関係を管理しながら、機能開発はコンポーネント間で並行して進められます。通常70%で停滞するマイグレーションも、段階的なPRと徐々に緩和されるレビューゲートによって完了まで押し進められます。デザインシステムのメンテナンス、リンターのルール展開、不安定なテストのトリアージといった“ガーデニング”作業は自律的なバックグラウンドジョブになります。CursorはProjectsを活用するチームでマージされたPRの大幅な増加を報告しており、組織の具体的な数値に関わらず、パターンは明確です。永続的なコーディネーションと共有コンテキストの組み合わせが効果を生みます。ただし、ポリシーがなければ管理されないボリュームがレビュー疲労と確率的な品質低下を招くリスクがあります。
購入者の関心は「エージェントがコードを書けるか」から「安全で測定可能なエージェントフリートを運用できるか」に移ります。つまり、CIの信頼性、テストカバレッジ、ブランチ保護、シークレット管理の準備が必要です。また、バックログのプロダクト化も求められます。マイグレーションテンプレート、レビュー基準、ロールバック計画を定義し、レビュー担当者を守るために並列度を調整し、PRサイクル時間、障害回復、欠陥流出率でROIを追跡します。S字カーブを想定してください。初期は人間が介在し、中期は制御された自律運用、後期はターゲットを絞った監視下での安定した自動化です。インフラのように調達し、DevOpsのようにガバナンスし、信頼性機能のように人員を配置してください。チャット実験としてではなく、運用モデルとして扱うべきです。


