Replit（レプリット）は、自律型コーディングエージェントを評価する新しいアプローチを発表した。これは、生成されたコードが単体テストに合格するかどうかだけでなく、エージェントが構築したアプリがエンドユーザーにとって実際に機能するかどうかを測定することを目的としている。同社はこの変化を、いわゆる「バイブコーダー」のニーズに基づいていると説明している。バイブコーダーは通常、リポジトリー、テストスイート、または定義済みのフレームワークではなく、自然言語のアイデアから始め、アプリがクリックされて操作されたときに機能するかどうかで成功を判断する。
Replitによると、モデル、プロンプト、ツール、製品インターフェイスの変更ペースが速いため、単発の評価スコアでは継続的な改善を導くには不十分になっている。同社は、リリース前に不具合を検出するためのオフラインベンチマーク、変更適用後に実際のユーザー行動を把握するためのオンラインA/Bテスト、集計指標の背後にある不具合を解明するための本番環境トレース分析という3つの要素からなる測定戦略を策定した。この組み合わせは、各測定層が他の層の欠点を補う階層型安全モデルと比較された。
バイブコーディング特有の要件を捉えるため、Replitは匿名化された本番環境のトレースと平易な英語で書かれた製品要件文書（PRD）を基にした公開ベンチマークであるViBenchを発表した。Replitの説明によると、ViBenchではエージェントはPRDのみに基づいて実行可能なアプリケーションをゼロから構築し、スタック、ルート、コンポーネント、インタラクションフローを自由に選択できるとのことだ。この柔軟性によってテスト上の課題が生じるとReplitは述べており、評価エージェントは固定ロケーターや既存のスキャフォールディングに頼るのではなく、開発者エージェントが考案したものを何でも探索する必要があるとしている。
Replitは、各PRDと、完成したアプリが満たすべき機能レベルのインタラクションとアサーションを記述した自然言語テストプランをペアにしたテストアーキテクチャーについて説明した。評価エージェントはPlaywrightを基盤として、オフラインシミュレーション、ファイル操作、マルチテナントなどの複雑な動作を実行する。このエージェントは、アプリの構造を段階的に発見していくノートブック環境で動作する。このアプローチは、自動自己テストを目的とした、これまでのREPLベースの検証作業の拡張として位置付けられた。
Replitストラクチャーは、ViBenchを大規模に実行するための重要な要素として特定された。Replit社は、社内の運用システムを使って、独立したリソース豊富なサンドボックスを起動し、それを迅速にフォークして相互汚染なしに多数の評価を並列実行できると述べている。同社は、ViBenchの基盤が他のバイブコーディングシナリオもサポートしていることを強調した。エージェントは、既存のコードベースを拡張する（Vibe-to-ref）か、エージェント自身が生成する成果物を改善する（Vibe-on-Vibe）ことで評価でき、同じPRDとテストプランのバックボーンを新しい製品サーフェスやインタラクションパターンに合わせて調整できる。
ViBenchの初期結果では、2つの注目すべきパターンが明らかになったとされている。第一に、最先端のコーディングベンチマークで高得点を獲得しても、特にオープンウェイトモデルの場合、完全なアプリケーション構築において必ずしも高いパフォーマンスを発揮するとは限らない。第二に、エージェントが自身のコードベースを拡張するように求められると、編集を重ねるごとにエラーが蓄積され、モデルのパフォーマンスが低下する傾向がある。Replitはこれらの結果を踏まえ、個別のテストに合格するための最適化から、その後のユーザーからの要求にも耐えうる堅牢なアプリケーションの構築へとシフトする必要があると提言した。
Replitは、オフラインベンチマークだけでは不十分であることを強調し、エージェントの変更が実際のユーザーにどのような影響を与えるかを検証する手段として、定期的なA/Bテストを実施していると述べた。同社は、プロンプト編集、ツールやハーネスの変更、モデルの切り替え、その他の行動を変えるアップデートについて、多くの場合同時並行でA/Bテストを実施しているが、相互作用の影響を避けるためにアトリビューションコントロールを使っていると報告した。A/Bテストは、ユーザーがプロジェクトを継続しているかどうか、コスト指標がどのように変化するか、感情や出荷活動に変化があるかどうかを明らかにするのに役立つと評価されているが、同時に、有益な作業によって増加したセッション時間と行き詰まった時間を区別するなど、解釈上の課題も提起している。
集計された実験指標を超えた説明の必要性に対応するため、Replitはセッショントレースをクラスター化された問題グループに整理するシステムであるTelescopeを発表した。Telescopeは、ユーザーメッセージ、エージェントの応答、ツール呼び出し、エラー、メタデータからセッションを再構築し、障害の軌跡を証拠に基づいた短いファセットに要約し、それらの要約を埋め込み、密度ベースの手法を使って類似のケースをクラスタリングすると説明されている。結果として得られるクラスターとファセットにより、エンジニアとエージェントは代表的なセッションをより迅速に見つけ、関連する障害を調査し、どのワークフローが支配的か、どのワークフローが放棄されているか、何が繰り返し壊れているかに基づいて緩和策の優先順位付けを行うことができるとされている。
これらの測定システムを継続的改善のフレームワークに組み込むことが次のステップとして提示された。Replitは、本番ログ、トレースクラスター、最近の障害から仮説を生成し、修正候補を作成して根拠を添付したドラフトプルリクエストとして提出し、ViBench、A/Bメトリクス、軌跡データ、ベースラインに基づいて候補を評価し、変更をリリース、反復、または破棄するための推奨事項を生成する自己改善ループの概要を示しました。同社は、人間のエンジニアがリリースとアーキテクチャー上の決定に対する最終承認権を保持し、ループは証拠を準備し、回帰テストを行い、試行した内容と失敗した内容を記録することで、将来の実行で行き詰まりを回避し、成功したパターンを再利用できるようにすると明確にした。
ループの動作を示す具体的な例が一つ挙げられた。Telescopeクラスターが、集計メトリクスには現れない環境設定におけるロングテールコールドスタートの問題を検出した。ループは、このパターンを明らかにし、パッチを生成し、回帰テストを追加し、ViBenchに対して候補を検証してコアフローが損なわれていないことを確認した。人間のレビューの後、変更は同日中に本番環境にプッシュされ、影響を受けたユーザーのブロックが解除されたことで、ユーザーの満足度も回復した。
Replitは、パイプラインにおける限界と人間の責任を認めた。人間は、ループが優先すべき仮説を選択し、トレースが放棄されたワークフローを示している場合にアーキテクチャー上のトレードオフを決定し、最適化目標が製品目標と一致するように評価をキュレーションし、証拠と影響範囲の考慮事項が理解された後にローンチを承認すると説明された。同社はこのバランスを、自動化システムに検索、測定、および合成を任せつつ、製品の方向性とリスクに関する決定はエンジニアとプロダクトマネージャーに委ねる方法として位置付けた。
エンドツーエンドの、本番環境に基づいた測定と反復的な改善ループを重視する姿勢は、SWE-benchやTerminal-Benchといった既存のエージェント型コーディングベンチマークの欠点を補うものとして提示された。これらのベンチマークは制約のある環境でコードを評価するものの、Vibeコーダーが求めるユーザー向けの正確性を見落としがちであると指摘されている。Replitは、自律型ソフトウェアエンジニアリングエージェントに関心のある実務家に対し、ViBenchへの参加を促し、採用プロセスは提供された連絡先を通じて開始できることを示しました。参考文献やより詳細な技術的議論については、リンク先の研究論文や共同研究者の投稿を参照するよう指示した。
出典：Replit
この製品の詳細については、Replit製品ページをご覧ください。
