Composerの開発における特徴的な点の1つは、将来のモデルの学習プロセスを改善するために、過去のバージョンのモデルを活用していることです。

こうしたブートストラップが特に効果を発揮するのが、環境設定です。RLの学習には実際に動く環境が必要であり、開始時点で環境が壊れていると、モデルは問題解決を学ぶ代わりに設定のデバッグにトークンを浪費してしまいます。最悪の場合、環境が悪いせいで問題そのものがまったく解けなくなり、報酬シグナルを得られないまま計算資源だけを消費することになります。

これに対処するため、私たちはComposer autoinstallを開発しました。これは、以前のComposerモデルを使って、未設定の状態でチェックアウトされたリポジトリから、動作するRL環境を自動的に作成するシステムです。最新バージョンのモデルであるComposer 2の学習では、その前身であるComposer 1.5を使ってこのプロセスを進めました。単に手順どおりに進めるだけでなく、最新のコーディングモデルは、設定を成功させ、プロジェクトの依存関係をモックし、その設定が正しく完了していることをテストするために、かなり粘り強く取り組めることがわかりました。

#より良い環境は、より良い学習シグナルを生む

モデル開発の多くの側面と同様に、autoinstall は本番の Cursor システムから着想を得ています。Cursor の クラウドエージェント には、ユーザー向けにクラウド環境のセットアップを自動化し、エージェントがモック環境でプロジェクトに取り組めるようにする機能があります。git checkout から始めて、エージェントはパッケージをインストールし、設定を行い、コードが実行可能で安定していることを確認するための基本的なチェックを実行します。これにより、以降のリクエストを正しいセットアップ済みの状態から始められるようになります。

RL の学習では、この問題はさらに本質的ですが、同時に難しさもあります。リポジトリから始めて、autoinstall の目標は、将来の未知のコーディング課題を解くための、コードベースの実行可能なモックのベースバージョンを作成することです。このベース環境は非常に重要です。というのも、Composer は、プログラミング言語の lint コマンド、検索、サンドボックス化された shell の使用を含む、完全なツールセットを使って学習されるからです。環境を正しく設定できないと、学習効率が下がり、報酬シグナルを得られないまま計算資源を無駄にしてしまう可能性があります。

#1つのエージェントが成功を定義し、次のエージェントがそれを達成しようとする

Autoinstall は2段階で行われます。最初の「目標設定」段階では、特定のチェックアウト時点に固定したコードベースを Cursor エージェントに渡し、環境が正しく設定されていれば実行されるはずの10個のコマンドと、その出力の概要を提案するよう求めます。

エージェントは、その環境に関する README や Makefile を調べるほか、uv のようなプロジェクトマネージャーや clippy のようなリンターなど、言語ごとによく使われる典型的なコマンドも試します。エージェントの作業には通常、設定用コマンド、利用可能であればテスト、そして実行ファイルの起動コマンドが含まれます。

第2段階では、環境の初期状態と、提案された10個のうち選ばれた3つの対象コマンドを、別の Composer エージェントに渡します。するとエージェントはコードベースを調べ、それらのコマンドを実行できるように環境を設定するため、ツール呼び出しを使って作業を進めます。その後、3つのコマンドすべてが実行でき、出力が最初のエージェントによる対象の説明と一致するかをテストします。一致しない場合は、第2段階を最初からやり直します。この処理を5回繰り返しても、エージェントが十分満足のいく水準まで環境を設定できなければ、その環境は破棄します。

Autoinstall を通じて、Composer は可能な限り完全な形で環境を正しく設定することを目指します。そのために、不足しているファイルをモックしたり、プレースホルダー画像を作成したり、さらにはダミーのデータベーステーブルを作成したりします。プロジェクトによっては、S3 フォルダや不足している sidecar コンテナのように、テストを実行するために必要な追加のコンポーネントをインストールする必要があります。Composer はこうしたものもしばしばモックし、MinIO の config や Docker コンテナを作成して動作させます。長時間実行されるプロセスをサポートするために、Autoinstall では RL の使用開始時にそれらを起動する start script を作成できるようにしました。

#実運用プロジェクト向けの Autoinstall

Autoinstall のプロセスを説明するために、Autoinstall を使って複雑な実運用プロジェクトを設定した実際の実験を取り上げます。対象のプロジェクトは celo-org/celo-monorepo で実装されている Celo で、複数の主要な依存関係を持つ大規模なブロックチェーンプロジェクトです。このプロジェクトは、インストールに必要な多数の依存関係を管理したうえで、Testing のために認証フローをモック化する必要があるため、Autoinstall の興味深いテストケースになっています。

最初の Autoinstall 段階では、インストールに必要な主要コマンドを見つけるために、エージェントがプロジェクトのドキュメントとコードを調べていく様子が見られました。ただし、このプロジェクトに付属するドキュメントは比較的少なかったため、追加の設定コマンドを探す目的で Web コマンドも使い、プロジェクトのドキュメントサイトを検索しました。特定されたコマンドの大半はインストールやテストに関するものでしたが、ドキュメントにはこのソフトウェアを利用するための基本的な最小アプリケーションも含まれていました。

第 2 段階では、エージェントは実際にこれらのコマンドを動かすタスクを与えられました。タスクの内容自体は明確でしたが、モデルはどのような問題に直面するかを事前には把握していませんでした。このケースでは、Foundry のような追加の依存関係や関連する repo をインストールする必要があることが分かりました。この必須プロジェクトのドキュメントを読むために、Web 検索も使いました。また、この環境で最小アプリケーションを実行することもタスクに含まれていました。この段階の最初の反復では、このテスト用アプリケーションを動かすことに失敗しましたが、2 回目の反復では、アプリケーションをローカルで起動して要件を満たすために、モックユーザーを作成できることを突き止めました。

#次世代へのブートストラップ。

Autoinstall は、以前のモデルを使って RL プロセスをブートストラップする興味深い例です。特に Composer 2 は、Terminal-Bench で大幅に高いスコアを記録しています (Composer 1.5 の 47.9% に対して 61.7%) 。これは、モデルが開発環境を設定する能力を測るテストを含むベンチマークです。つまり、autoinstall にとって Composer 2 は、より優れた基盤になることを示しています。今後の実行では、以前の Composer インスタンスが、実行管理、データの前処理、アーキテクチャ調整など、学習プロセスのさまざまな側面で大きな役割を果たすようになると見込んでいます。

Composer 2 について詳しく見る