Devin の仮想マシンにおけるエンドツーエンドテスト機能の構築から学んだこと
3 ヶ月前、私は Cognition に入社し、ソフトウェアエンジニアリングの未来を築く手伝いを始めました。Devin は初の AI ソフトウェアエンジニアとしてローンチされて以来、大きく進化してきました。そして、その背後にいるチームが実際に毎日 Devin を使っているのを見て、私は圧倒されています。
特に印象的だったのは、Devin が自身のコンピュータを使ってクラウド上で自律的に作業を検証する方法です。Slack 統合の検証から複雑な Windsurf 機能のテストまで、チームは常に多数の Devin をテストモードで稼働させています。この記事では、なぜ私たちがクラウド上のエージェントによるエンドツーエンド検証にそれほど注力しているのか、そしてその構築にどのように取り組んでいるのかを共有します。
非同期ソフトウェアエンジニアリングへの移行
Cognition では、最近新たなマイルストーンに到達しました。初めて、イベント、自動化、スケジュール、他の Devin を介して、非同期にトリガーされる Devin の数が多くなりました。この傾向は、最近ローンチした Auto-Triage によってさらに加速すると予想しています。
この非同期の世界に移行するにあたり、開発者が検証済みの結果に戻ってきて、すぐにマージできる状態であることが極めて重要です。今年の初めに、Devin Review をローンチしました。これは、複雑なコード差分に対する人間の理解を拡張するコードレビューツールです。バグを指摘するだけでなく、Devin がループを閉じ、差分がクリーンになるまで各指摘事項を修正します。しかし、クリーンなレビューだけでは不十分なことがよくあります。エンジニアは、自分たち自身でテストするのと同じように、変更がエンドツーエンドでテストされるのを確認したいのです。
Devin が、バグチャンネルでメッセージを見る前に、ユーザーの苦情を修正する PR を提出してくれるのは素晴らしい気分です。さらに魔法的なのは、その PR に修正が実際に機能するという証拠が付いてくることです。そして、この魔法はやがて必須になるかもしれません。プロアクティブなエージェントの台頭により PR が増えるにつれて、未検証の変更はすぐに管理不能になるからです。
始まりから
Devin はローンチ以来、常にクラウド上の仮想マシンで作業を実演できました。約 6 ヶ月前、Devin のコンピュータ操作機能を拡張しました。具体的には、Devin のハーネスに、スクリーンショットの撮影、マウスの移動、クリック、ドラッグ、タイピング、キー押下、スクロール、待機、ズーム、録画の開始/停止などのツールを追加しました。コンピュータ操作自体は以前からありましたが、最先端のラボによる最新のモデル群がこれらのツールを実際にうまく活用し始めたと感じています。
コンピュータ操作により、Devin に新たな楽しい機能が追加されました。例えば、デスクトップゲームの作成とプレイ、ブラウザを使った Amazon での商品注文などです。しかし、私たちが気づいた真の価値は、Devin が自身の作業をテストできる能力でした。Devin はアプリを起動し、クリックしながら進め、変更が実際に機能することを確認します。これはまさにエンジニアが行う方法です。すべてがクラウド上で実行され、並行してスケールアウトできます。エンジニアが 10 から 20 の Devin を並行して実行し、それぞれが独自の開発サーバーで変更を処理しているのを見たとき、これが本当に衝撃的でした。これは単一のラップトップでは決してできないことです。自動化されたクラウドテストは、ローカルでコードを実行して検証する必要がなくなり、膨大な時間を節約してくれました。
正直なところ、ここに至るまでは順調ではありませんでした。途中で多くの障害モードに遭遇し、それぞれがこのシステムをより信頼性の高いものにするために何が必要かを教えてくれました。
信頼性の向上
初期のバージョンでは、テスト中に Devin が脱線することが非常に頻繁にありました。さまざまな形で発生しました。製品の無関係な部分を過剰にテストする、機能に到達する前にセットアップで迷子になる、あるいは PR が実際に変更しようとしていたコアな動作を単純に見逃すなどです。
これに対処するために、Devin がテストモードに入るとき、まずテスト計画を作成させ、何をテストするかを明確に定義させています。この計画はソースに基づいており、仮定に基づいてはいけません。コードに基づいていないと、モデルは存在しないアプリのパスをたどれると仮定してしまう傾向があります。さらに、テスト計画により、Devin が正常にテストできる変更の複雑さが大幅に向上します。最も野心的なリクエストの中には、複数のサービスを実行し、特定の管理者設定を構成し、適切なフラグを有効にしてからでないと動作に到達できない機能が必要なものもありました。コードを事前に読むことで、Devin はテストの途中で不足しているものを発見するよりも、環境を正しくセットアップする可能性がはるかに高くなります。テスト計画は事前調整の役割を果たし、アクティブにテストしているときに Devin が漂流する可能性を低減します。
Devin が計画を実行するにつれて、独自の注釈をタイムラインに追加します。これには、セットアップメモ、各名前付きテストの開始、合格、不合格、または未テストとしてマークされたアサーションなどが含まれます。Devin は、アクションを実行する直前に期待される動作を注釈として付けると、その結果について嘘をつく可能性が低くなることがわかりました。これはテスト駆動開発と非常によく似ており、事前に期待値をコミットすれば、予期しない結果を合格と合理化することがはるかに難しくなります。
テストフローの一部は、ほぼすべての実行で繰り返されます。ログインはその典型的な例です。コンピュータ操作でログインフォームを操作するには、メールアドレスを入力し、SSO を完了し、リダイレクトをクリックし、ページが読み込まれるたびにスクリーンショットごとに待機する必要があります。これは時間とトークンの両方でコストがかかります。これらのアクションの信頼性とコストを向上させるために、Devin は作業を決定論的なスクリプトに抽出し、リポジトリ内のテストスキルとして保存しました。これにより、Devin はスクリプトを実行して認証済みのブラウザセッションを数秒で取得し、テストのコア部分にジャンプできます。これらのスクリプトの決定論的な性質は、不安定性を劇的に減少させました。また、Devin がこのループを自ら閉じるように更新しました。セットアップ手順を苦労して理解した場合、Devin はその知識をリポジトリ内のテストスキルとして保存し、ワンクリック PR としてユーザーに修正を提案できます。
また、テストフェーズを異なるモデルにルーティングする実験も行っています。テストはコードを書くのとは異なる強み、例えばスクリーンショットの読み取り、UI 状態の追跡、次のブラウザアクションの決定などに依存するため、一部のモデルはコード編集に通常選ばれるモデルよりもこれらに優れています。
今日の Devin での自律テストの使用
現在、Devin は 2 つの方法でテストモードに入ります。変更をテストするように明示的に依頼するか、Devin が PR を作成した後に関連する変更をテストすることを提案するかです。そこから、テスト計画を作成し、作業を開始します。
Devin のテスト機能を使い始めたばかりの頃は、多くの場合、あなたの支援が必要になります。良い例は、アプリをローカルで実行するときにシークレットが必要な場合です。このプロセスをスムーズにするために、Devin はセッション内で 不足している可能性のある認証情報やその他の情報をあなたに尋ねる ことができます。より困難なケースでは、Devin のコンピュータを引き継いで、OTP コードなどを入力することもできます。良いニュースは、Devin がリポジトリのセットアップを完了すると、将来のすべてのセッションが起動するスナップショットを生成する YAML ブループリントの形で宣言的設定を保存できることです。
得られるもの
Devin がテストを完了すると、アプリが機能したかどうかを伝えるだけではありません。生の画面録画は有用ですが、それだけでは十分ではないと感じました。何を見ているのか、なぜ Devin が各アクションを実行したのか、テストのどの部分が合格または不合格になったのかを理解する必要があります。
簡単なレビューのために、Devin は実行中の重要な瞬間のラベル付きスクリーンショットを含むテストレポートを返します。これにより、Devin が何をテストしたか、その過程でアプリがどのように見えたかをすぐに確認できます。
より詳細なレビューが必要な場合は、Devin はリッチなプレイヤー UI を備えたテスト動画も生成します。この動画にはチャプターがあり、テストセクション間をジャンプしたり、実行全体をスクラブしたり、合格または不合格になったアサーションを時系列リストビューで検査したりできます。後処理では、アクション間の無駄な時間が圧縮され、アクションの前後の瞬間は通常の速度で再生されます。これにより、長時間の実行が実際に見られる録画に凝縮されます。これらのアーティファクトは Web インターフェースで利用でき、Devin が Slack から起動された場合は Slack にも配信されます。
課題
コンピュータ操作にはまだ課題があります。一例はタイミングです。Devin がトースト通知をテストしている場合、スクリーンショットが早すぎたり遅すぎたりすると、トーストを完全に見逃し、期待される動作が実際に発生したかどうかについてモデルが混乱する可能性があります。
もう 1 つの障害モードは「チート」です。モデルは、UI をクリックして操作する代わりに、ブラウザで JavaScript を実行してプログラム的に状態をトリガーすることに過度に依存する傾向があります。これは機能のテストには役立ちますが、ユーザーは多くの場合、実際のユーザーがアプリを操作するのと同じように Devin がアプリを実行するのを見たいと考えます。
私たちは、改善された評価、ハーネス内のより厳格なガードレール、そしてコンピュータ操作がますます向上する新しい世代のモデルを通じて、これらの問題に積極的に取り組んでいます。
非同期開発の未来は検証される
過去数ヶ月で、Devin で 1 日あたり承認されたテスト実行数は 2 倍以上になりました。この成長は単純なことを反映しています。非同期エージェントは、開発者がその結果を信頼できる場合にのみ有用です。多くの場合、その信頼はコードだけからは得られません。多くの変更では、アプリが実際に実行され、重要なフローが実行され、結果が簡単に検査できる形でキャプチャされたことを知りたいのです。
それが、Devin の自律テストが提供するように設計されているものです。Devin はテストを計画し、アプリを操作し、何が起こったかを記録して注釈を付け、最後に結果をレビュー可能にするアーティファクトを返します。改善すべき点はまだ多くありますが、これが未来の正しい形だと私たちは考えています。つまり、エージェントは非同期に作業を完了するだけでなく、証拠を持って戻ってくるのです。
私たちは、Devin が自身の作業をテストすることでどれだけの時間を節約してくれるかに常に驚かされており、多くのお客様がまだ Devin の自動テスト機能を十分に活用していないと感じています。実験を支援するために、現在テストモードでは通常の使用コストの 5 分の 1 で課金しています。
devin.ai または windsurf.com で私たちの成果をお試しください。また、このような問題に取り組むのが楽しそうだと思われたら、ido [at] cognition.ai までご連絡ください。
