Devinで20以上のタスクを実行した1ヶ月後のDevin使用の振り返り

2024年3月、Founders Fundが主導し、コリソン兄弟、エラッド・ギル、その他の技術界の著名人を含む業界のリーダーたちが支援する2100万ドルのシリーズAである。そのチームとは？国際情報学オリンピックの金メダリストである彼らは、私たちのほとんどが理解できないようなプログラミングの問題を解決できるような人たちだ。彼らの製品であるDevinは、新しい技術の学習や成熟したコードベースのデバッグから、完全なアプリケーションのデプロイ、さらにはAIモデルのトレーニングまで、あらゆることが可能で、人間の同僚のようにあなたとチャットできる完全自律型のソフトウェア・エンジニアになることを約束している。

初期のデモは説得力があった。 初期のデモは説得力があった。 デヴィン PyTorchプロジェクトをインストールして実行することで、人手を介さずにUpworkの懸賞金タスクを独自に完了する方法。同社は、DevinがSWE-benchベンチマークで13.86%の実世界のGitHub問題をエンド・ツー・エンドで解決できたとしており、これは従来のシステムより約3倍優れている。当初は一部のユーザーしか利用できなかったため、ソフトウェア開発に革命をもたらすというエキサイティングなツイートが投稿された。

する 回答.AI AI開発ツールを頻繁に試しているチームの一員である私たちは、Devinには何か違うものを感じた。もしDevinが約束していることの半分でも実現すれば、私たちの仕事のやり方を変えてくれるかもしれない。しかし、ツイッター上では熱狂的なファンが多い割に、実際に使っている人の詳細な証言はあまり見つからなかった。そこで私たちは、実世界のさまざまなタスクに対して徹底的にテストすることにした。2024年に最も注目されるAI製品のひとつを実際に使ってみた、徹底的な試みがここにある。

デヴィンとは？

Devinがユニークなのは、そのインフラだ。一般的なAIアシスタントとは異なり、DevinはSlack経由で独自の計算環境を実行・起動する。Devinと話すとき、あなたはウェブブラウザ、コードエディタ、シェルを備えた完全な計算環境にアクセスできるAIと話していることになり、依存関係をインストールしたり、ドキュメントを読んだり、作成したウェブアプリケーションをプレビューすることさえできる。以下は、Devinを起動してタスクを実行する方法のスクリーンショットだ：

Slack経由でDevinにタスクを開始させる1つの方法

この体験は、まるで同僚とおしゃべりしているような気分になるようにデザインされている。あなたが欲しいものを説明すると、Devinが作業に取りかかる。Slackを通じて、Devinが問題を解決する様子を見たり、必要なときに認証情報を要求したり、完了した作業へのリンクを共有したりすることができる。舞台裏では、DevinはDockerコンテナで実行され、あなたのシステムを保護しながら安全に実験するために必要な分離を与えてくれる。Devinはウェブ・インターフェースも提供しており、IDEやウェブ・ブラウザなどを使って環境にアクセスし、リアルタイムで作業を見ることができる。以下はウェブ・インターフェースのスクリーンショットである：

初期の成功

私たちの最初の仕事は、単純だが真実だった。 ノーティオン データベースはGoogle Sheetsに抽出された。Devinは驚くべき能力でこの問題を解決してくれた。NotionAPIのドキュメントにナビゲートし、何が必要かを理解し、Google Cloud Consoleで必要な認証情報を設定するプロセスを案内してくれました。単にAPIコマンドを投げ出すのではなく、各メニューやボタンのクリックをガイドしてくれたので、通常なら退屈なドキュメント検索が必要な時間を節約できました。全プロセスに要した時間は約1時間（ただし、人間とのやり取りは数分）だった。最後にDevinは、私たちのデータを含む完璧にフォーマットされたGoogleシートへのリンクを共有してくれた。

生成されるコードは少し長いが、機能する。これは未来を垣間見るような気がする。開発者の多くの時間を奪う "糊塗されたコード "のタスクを処理できるAIだ。ジョノは、木星と土星の歴史的な位置に関する主張を否定するために惑星トラッカーを作成し、デヴィンと同様の成功を収めた。特に印象的なのは、彼はこれをすべて携帯電話から行い、Devinが環境のセットアップとコードの記述という力仕事をすべてこなしたことだ。

テストの拡大

初期の成功を踏まえ、私たちはDevinの非同期機能を活用しました。私たちは、ミーティング中にDevinにドキュメントを書いてもらったり、設計作業に集中している間に問題をデバッグしたりすることを想像していました。しかし、テストの規模を拡大するにつれ、亀裂が生じた。一見単純に見える作業でも数時間ではなく数日かかることが多く、Devinは技術的な行き詰まりにぶつかったり、複雑すぎて使いこなせないソリューションを作成したりした。

さらに心配なのは、実質的に不可能なタスクを強要するデヴィンの傾向だ。複数のアプリケーションを1つのRailwayデプロイメント（Railwayがサポートしていない機能）にデプロイするよう求められたとき、デビンはこの限界を認識する代わりに、1日以上かけてさまざまなアプローチを試し、存在しない機能をごまかした。

最も苛立たしいのは、失敗そのものではなく、すべてのツールには限界がある。

何が問題だったのかを洞察する

私たちの旅の中で、私たちは混乱していた。DevinはAPIをうまく統合し、機能的なアプリケーションを構築することができたが、一見単純なタスクに苦戦していた。これは運が悪かっただけなのか？私たちの使い方が間違っていたのだろうか？

1カ月間にわたり、私たちは以下のカテゴリーにおける試みを系統的に記録した：

1. 新規プロジェクトをゼロから作成する
2. 研究指令の実施
3. 既存プロジェクトの分析と修正

結果は散々だった。20個のタスクのうち、失敗が14個、成功が3個（最初の2個を含む）、結論が出ない結果が3個だった。さらに決定的だったのは、どのタスクが成功するかを予測するパターンを見出すことができなかったことだ。初期の成功例と同じようなタスクが、予期せぬ形で失敗したのだ。これらのタスクの詳細については、以下の付録を参照されたい。 以下は、その過程における各カテゴリーの経験の要約である：

1.ゼロから新しいプロジェクトを作成する

このカテゴリーはDevinの得意分野であるはずだ。結局のところ、同社のデモビデオでは、Upworkで報奨金タスクを自律的に完了させる方法が紹介されており、私たち自身の初期の成功は、それが真新しい開発に対応できることを示唆している。しかし、現実はもっと複雑だった。

例えば、Braintrustと呼ばれるLarge Language Model（LLM）観測可能性プラットフォームとの統合を試みたときのことだ。課題は明確だった。合成データを生成し、それをアップロードすることだった。Devinは焦点を絞った明確なソリューションを提供する代わりに、コードのスープとしか言いようのないものを生成した。つまり、単純な操作を不必要に複雑にする抽象化の複数の層だ。私たちは結局、Devinの試みを放棄して カーソル ステップ・バイ・ステップで統合を構築する方が効率的であることがわかりました。同様に、私たちのAIノートテイカーとSpiral.computerの統合を依頼されたとき、Devinはチームメンバーの一人が「ゼロから書いたコードより読みにくいスパゲッティコード」と表現するようなものを作成した。両システムのドキュメントにアクセスできるにもかかわらず、デヴィンは統合のあらゆる面を複雑にしすぎたようだ。

最も重要なのは、ウェブクローリングの試みだろう。DevinにGoogle Scholarのリンクを追跡し、著者の最新論文25本をクロールするよう依頼した。これはPlaywrightのようなツールにとっては簡単なタスクである。Devinのウェブ閲覧能力とコード作成能力を考えれば、これは特に簡単に達成できるはずだった。その代わり、HTMLを解析しようとする無限ループにはまり、自分のやり方から抜け出すことができなかった。

2.研究義務

もしデヴィンが特定のコーディング作業に苦戦しているのなら、研究志向の取り組みではもっとうまくいく可能性があるのだろうか？結果はよくてもまちまちだ。初期のNotionとGoogle Sheetsの統合で見られたように）基本的なドキュメント検索はできるが、より複雑なリサーチタスクは難しいことがわかった。

私たちがDevinに、正確なタイムスタンプを持つトランスクリプション・サマリー（私たちが直面した具体的な技術的課題）を見るように頼んだとき、Devinは核心的な問題に取り組むのではなく、表面的に関連する技術情報を繰り返しただけだった。潜在的な解決策を探ったり、主要な技術的課題を特定したりする代わりに、根本的な問題に対処しない一般的なコード例を提供した。デビンが進歩を遂げたように見えても、その結果はたいてい見かけとは違っている。たとえば、例として最小限のDaisyUIテーマを作成するよう求められたとき、Devinは一見うまくいくように見えるソリューションを生成した。私たちが見た色はデフォルトのテーマによるもので、私たちがカスタマイズしたものではなかったのだ。

3.既存コードの分析と修正

おそらくデヴィンが最も心配する失敗は、既存のコードベースを扱うときに起こる。これらの作業では、コンテキストを理解し、確立されたパターンとの一貫性を維持する必要がある。

Devinにnbdevプロジェクトを扱わせようとした試みは、特に示唆に富んでいた。Pythonプロジェクトをnbdevに移行するよう依頼されたとき、Devinは包括的なドキュメントを提供しても、基本的なnbdevのセットアップを把握することができなかった。ノートブックを直接編集するのではなく、Pythonスクリプトを作成して修正するため、単純な作業に不必要な複雑さが加わってしまったのだ。時折有用なコメントやアイデアを提供してくれるものの、実際に生成されるコードには一貫して問題がある。

セキュリティ・レビューでも同様の問題が見つかった。DevinにGitHubリポジトリ（コード行数700行未満）のセキュリティ脆弱性の評価を依頼したところ、多くの偽陽性のフラグを立てたり、存在しない問題をごまかしたりして、やりすぎてしまいました。この種の分析は、おそらくDevinの洗練されたアプローチよりも、的を絞ったラージ・ランゲージ・モデル（LLM）呼び出しによって処理するのがベストだろう。

このパターンはデバッグ作業中も続いた。セットアップ・スクリプトでSSHキー転送が機能しない理由を調査する際、デビンはスクリプト自体に集中し、問題が別の場所にあるかもしれないとは考えなかった。この "覗き見効果 "は、実際の根本原因を発見するのに役立たなかったことを意味する。同様に、ユーザー入力とデータベースの値の競合チェックを追加するよう求められたとき、あるチームメンバーは、デビンの試みを何時間もかけて研究した。

チームとしての反省

1ヶ月に及ぶ集中的なテストの後、私たちのチームは経験を整理するために集まった。これらの言葉は私たちの気持ちを最もよく表している：

このマシンがこなせるタスクはとても小さく、明確に定義されているので、自分のやり方でやった方が早い。時間を節約できるような大きなタスクでは、失敗する可能性が高いと思う。その結果、本当に使いたいユースケースはない。- ジョノ・ウィテカー

最初は、とても近かったし、いろいろと手を加えられるような気がして、とても興奮した。その後、どんどん変えていかなければならないので徐々にフラストレーションがたまり、最終的にはゼロから少しずつやっていったほうがいいという境地に達した。- アイザック・フラース

Devin は、AnswerAI の内部ツールを使いこなすのに苦労していました。Devinには、豊富なドキュメントと例を提供していますが、これはまだ問題です。Cursor のようなツールでは、このような問題はありません。- ハメル・フサイン

Devinと比較して、開発者主導の（Cursorのような）より多くのプロセスは、Devinで遭遇した問題のほとんどを回避できることがわかった。

評決を下す

デヴィンとのコラボレーションは、自律的なAI開発のビジョンを示している。Slackを通じてチャットしたり、非同期で動作するのを見たり、環境をセットアップして依存関係を処理するのを見たり。うまくいったときは感動的だ。

しかし、そこに問題がある。 私たちが試みた20のタスクのうち、14の失敗、3つの不確かな結果、そしてわずか3つの成功があった。さらに心配だったのは、どのタスクが成功するかを予測できなかったことだ。初期の成功例に似たタスクでさえ、複雑で時間のかかる方法で失敗した。デビンは、根本的な障害を特定するよりも、不可能な解決策を追求することに何日も費やしていた。

これは、我々がAIツールで繰り返し観察してきたパターンを反映している。ソーシャルメディアの盛り上がりや企業の評価は、実際の実用性とはほとんど関係がない。我々が見つけた最も信頼できるシグナルは、製品やサービスを提供するユーザーの詳細なストーリーから得られる。今のところ、私たちはAIの支援を受けながら開発プロセスを推進できるツールにこだわっている。

付録：デビンが試みたミッション

以下の表は、Devinに与えたプロジェクトを、(1)新規プロジェクトの立ち上げ、(2)リサーチ、(3)既存コードベースの分析、(4)コードベースの修正、といったトピックごとに分類したものである。

1.新規プロジェクトの立ち上げ

2.実施研究

3.既存コードの分析

4.既存プロジェクトの修正