Devinとの1ヶ月間の考察

2024 年 3 月、Founders Fund が主導し 2100 万ドルのシリーズ A ラウンドを成功させた新しい AI 企業が、業界の重鎮たちからの支持を得て登場しました。支援者には Collison 兄弟、Elad Gil、そして他の技術界の著名人たちが含まれています。その背後にあるチームは IOI（国際情報オリンピック）金メダリストであり、私たちが理解することさえできないプログラミング問題を解決する能力を持つ人々です。彼らの製品である Devin は、人間同様にチャットできる完全自律型のソフトウェアエンジニアになると約束しました。新しい技術の学習から成熟したコードベースのデバッグ、フルアプリケーションのデプロイメント、さらには AI モデルのトレーニングに至るまで、あらゆるタスクをこなすことが可能です。

初期のデモは非常に魅力的でした。ある動画では、Devin が人間の介入なしに Upwork のバウンティ（課題）を独自に完了し、PyTorch プロジェクトをインストールして実行する様子が映し出されました。1 同社は、Devin が SWE-bench ベンチマークにおいて、実世界の GitHub イシューの 13.86% をエンドツーエンドで解決できると主張しました。これは以前のシステムと比較して約 3 倍の性能です。当初は限られたユーザーのみがアクセスできる状態だったため、「これがソフトウェア開発を革命化する」という興奮に満ちたツイートが相次ぎました。

AI 開発ツールを日常的に実験している Answer.AI のチームにとって、Devin は何か違う雰囲気を感じさせました。もしそれが約束したことの半分でも実現できれば、私たちの働き方そのものを変革する可能性があります。しかし、Twitter では熱狂的な声が溢れていましたが、実際にそれを使っている人々の詳細な報告はあまり見当たりませんでした。そこで私たちは、Devin を本格的にテストすることにしました。幅広い現実世界のタスクに対して検証を行い、その能力を試すことにしたのです。これが私たちの物語です。2024 年最も注目された AI プロダクトの一つと実際に協働しようとした、徹底的で現実的な試みです。

Devin とは何か？

Devin の独自性を支えているのはそのインフラストラクチャです。一般的な AI アシスタントとは異なり、Devin は Slack を通じて稼働し、独自のコンピューティング環境を起動します。Devin とチャットするということは、ウェブブラウザ、コードエディタ、シェルを備えた完全なコンピューティング環境にアクセスできる AI と対話していることになります。依存関係のインストールやドキュメントの参照、さらに自身が作成した Web アプリケーションのプレビューさえも可能です。以下は、Devin に作業させるタスクを開始する方法の一つを示すスクリーンショットです：

Slack を通じて Devin とタスクを開始する一例

この体験は、同僚とチャットしているような感覚を味わえるように設計されています。あなたが何を望むかを説明すると、Devin が作業を開始します。Slack を通じて、問題解決のプロセスを見守ったり、必要な際に認証情報を求めたり、完了した仕事のリンクを共有したりできます。裏側では Docker コンテナ内で動作しており、これによりシステムを保護しながら安全に実験を行うために必要な隔離環境が提供されます。Devin はまた Web インターフェースも提供しており、これを通じてその環境へのアクセスを得て、IDE や Web ブラウザなどでの作業をリアルタイムで確認することも可能です。以下は Web インターフェースのスクリーンショットです：

初期の成果

最初のタスクはシンプルですが実用的なものでした：Notion データベースからデータを抽出し、Google スプレッドシートに転送することです。Devin は驚くべき能力でこれに取り組みました。Notion API のドキュメントページへ移動し、必要な情報を理解すると、Google Cloud Console での必要な認証情報の設定を私に案内しました。単に API の手順を羅列するのではなく、必要な各メニューやボタンクリックを手順通りに案内することで、通常は面倒なドキュメント調査の時間を大幅に短縮しました。全体のプロセスには約 1 時間かかりましたが、人間の関与はわずか数分程度でした。最後に Devin は、データを完璧にフォーマットした Google スプレッドシートのリンクを共有してくれました。

生成されたコードは少し冗長でしたが、確かに動作しました。これは、開発者の時間を多く消費する「接着剤コード」のタスクを処理できる AI の未来への一瞥のように感じられました。Johno も同様に、Devin を使用して木星と土星の歴史的な位置に関する主張を否定するための惑星トラッカーを作成し、成功を収めています。特に印象的だったのは、環境設定やコード記述という重労働をすべて Devin が担当し、彼がこれを完全にスマートフォンを通じて管理した点です。

テストの拡大

初期の成功に基づき、私たちは Devin の非同期機能を積極的に活用しました。会議中に Devin にドキュメント作成を行わせたり、デザイン作業に集中している間にデバッグを行わせたりすることを想定していました。しかし、テストを拡大するにつれて、ひび割れが現れました。一見単純なタスクでも、技術的な行き止まりに陥ったり、過度に複雑で実用性の低い解決策を生み出したりして、数時間ではなく数日かかることがありました。

さらに懸念されるのは、実際には不可能なタスクに対して Devin が前に進もうとする傾向です。単一の Railway デプロイメントに複数のアプリケーションをデプロイするよう指示した際（Railway はこれをサポートしていません）、この制限を特定する代わりに、Devin は存在しない機能をでっち上げながら、さまざまなアプローチを試すことに 1 日以上費やしました。

最も苛立たしい点は、失敗そのものではなく、これらの試みを救済するためにどれだけ時間を費やしたかです。

何が間違っていたのかのより深い考察

この時点での私たちの旅路において、私たちは困惑していました。Devin は API 統合を competently に処理し、機能的なアプリケーションを構築する様子を見てきましたが、より単純に見えるタスクでは struggling していました。これは単なる不運なのでしょうか？それとも私たちが使い方を間違えているのでしょうか？

1 ヶ月という期間を通じて、私たちはこれらのカテゴリにおける試行を体系的に文書化しました：

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

調査タスクを実行する

既存のプロジェクトの分析と修正を行う

結果は厳しいものでした。20 のタスクのうち、失敗が 14 件、成功が 3 件（初期の 2 件を含む）、結論が出ない結果が 3 件でした。さらに示唆に富むのは、どのタスクが成功するかを予測するパターンを見出せなかったことです。当初の成功事例と似ているように見えるタスクでも、予期しない方法で失敗することがありました。これらのタスクに関する詳細は以下の付録に記載しています。以下に、各カテゴリでの私たちの経験を要約します：

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

このカテゴリは Devin の得意分野であるはずでした。確かに、同社のデモ動画では Upwork のバウンティを自律的に完了している様子を示しており、私自身の初期の成功事例もグリーンフィールド開発（ゼロからの新規開発）を処理できる可能性を示唆していました。しかし、現実はより複雑であることが証明されました。

Braintrust という LLM 観測プラットフォームとの統合を試みた際の経験です。タスクは明確でした：合成データを生成してアップロードすること。しかし、Devin が提示したのは焦点の定まった解決策ではなく、単なるコードのスープとしか言いようのないものでした。抽象化の層が重なり、単純な操作さえも不必要に複雑なものになっていました。最終的に Devin の試みは断念し、Cursor を使って統合ステップを一つずつ構築しました。その方がはるかに効率的であることが証明されました。同様に、AI ノートテーカーと Spiral.computer 間の統合作成を依頼した際にも、Devin はチームメンバーの一人が「自分でゼロから書いた場合よりもはるかに読みづらく、スパゲッティコードだ」と表現するようなコードを生成しました。両システムのドキュメントへのアクセス権限があったにもかかわらず、Devin は統合のあらゆる側面を不必要に複雑化してしまいました。

おそらく最も示唆的だったのは、ウェブスクレイピングへの挑戦でした。Google Scholar のリンクを追跡し、特定の著者から最新の 25 件の論文を取得するというタスクです。Playwright などのツールを使えば straightforward な作業のはずでした。Devin がウェブブラウジングとコード記述の能力を有していることを考えれば、特に実現可能なはずだったのです。しかし実際には、HTML の解析を試みる無限ループに陥り、自身の混乱から抜け出せなくなりました。

1. 調査タスク

もし Devin が具体的なコーディングタスクに苦戦しているなら、研究指向の作業ではより良い結果が出るかもしれない。しかし、その結果はせいぜい半端なものだった。基本的なドキュメント検索（初期の Notion/Google Sheets 統合で見た通り）には対応できたが、より複雑な研究課題は難しかった。

Devin に正確なタイムスタンプ付きのトランスクリプト要約を調査するよう依頼した際、私たちが直面していた特定の技術的課題に対して、関連する周辺情報を書き写すだけで、核心の問題に取り組むことはなかった。潜在的な解決策を探ったり、重要な技術的課題を特定したりする代わりに、根本的な問題に対処しない一般的なコード例を提供しただけだった。Devin が進歩しているように見えたときでさえ、結果は往々にして見た目ほどではなかった。例えば、例として最小限の DaisyUI テーマを作成するよう求められた際、動作するように見えるソリューションを生成した。しかし、よくよく確認すると、そのテーマは何も機能していないことが判明した。私たちが目にした色は、カスタマイズされたものではなく、デフォルトのテーマからのものであった。

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

おそらく Devin の最も懸念すべき失敗は、既存のコードベースを扱う際に現れたものである。これらのタスクには文脈の理解や確立されたパターンとの一貫性の維持が必要であり、これは AI ソフトウェアエンジニアの能力の中核となるべきスキルである。

Devin を nbdev プロジェクトと連携させる試みは、特に示唆に富む結果となりました。Python プロジェクトを nbdev へ移行するよう依頼された際、包括的なドキュメントへのアクセス権を与えたにもかかわらず、Devin は基本的な nbdev のセットアップさえ理解できませんでした。さらに謎深かったのは、ノートブックの操作に対するそのアプローチです。ノートブックを直接編集するのではなく、それらを修正するための Python スクリプトを作成し、単純なタスクに不必要な複雑さを付加していました。時折、有用なメモやアイデアを提供することはありましたが、実際に生成されたコードは一貫して問題を抱えていました。

セキュリティレビューでも同様の課題が浮き彫りになりました。GitHub リポジトリ（700 行未満のコード）をセキュリティ脆弱性の観点から評価するよう依頼した際、Devin は行き過ぎた対応を取り、多数の偽陽性を検出したり、存在しない問題を幻覚のように報告したりしました。このような分析は、Devin の複雑なアプローチよりも、単一の焦点を絞った LLM（大規模言語モデル）呼び出しによってより適切に処理できたはずです。

このパターンはデバッグタスクでも続きました。セットアップスクリプトで SSH キー転送が機能しない理由を調査する際、Devin はスクリプトそのものに執着し、問題が別の場所にある可能性を全く考慮しませんでした。このトンネルビジョン（視野狭窄）により、実際の根本原因を解明する手助けができなかったのです。同様に、ユーザー入力とデータベース値の間の競合チェックを追加するよう依頼された際、あるチームメンバーは Devin の試行錯誤に数時間を費やした末に断念し、約 90 分で自分自身でその機能を実装しました。

チームとしての振り返り

集中的なテストを1ヶ月行った後、私たちのチームは集まり、その経験を整理しました。これらの引用文が私たちの気持ちを最もよく表しています:

「実行可能なタスクとは、私が自分でする方が速く、自分のやり方でできるほど小さく明確なものだ。時間短縮が見込めるような大きなタスクについては、おそらく失敗するだろうと思う。つまり、実際に使いたいというニッチな領域はない。」— Johno Whitaker

「当初は、それがどれほど近い存在かを見て興奮しました。いくつかの調整で済むと感じたからです。しかし次第に、より多くの修正が必要になり、最終的には最初からやり直して一歩ずつ進んだ方が良かったと気づき、フラストレーションが溜まりました。」— Isaac Flath

「Devin は AnswerAI で重要な内部ツールを使用することに苦戦しました。これは他の問題も相まって使いにくさにつながりました。これには膨大な量のドキュメントや例を提供したにもかかわらずです。Cursor のようなツールでは、より漸進的に方向を修正する機会が多くあるため、この問題は発見されていません。」— Hamel Husain

Devin と対照的に、開発者が主導権を握るワークフロー（Cursor など）では、Devin で直面したほとんどの問題を回避できることがわかりました。

結論

Devin との協働は、自律型 AI 開発が目指すべき姿を示しました。UX は洗練されており、Slack を通じたチャット、非同期での作業状況の確認、環境設定や依存関係の処理などを見守ることができます。動作した際には非常に印象的でした。

しかし、それが問題なのです——それはほとんど機能しませんでした。試みた 20 のタスクのうち、14 が失敗し、3 つが決着つかない結果に終わり、成功したのはわずか 3 つだけでした。さらに懸念されるのは、どのタスクが成功するかを予測できない点です。初期の成功事例と類似したタスクでさえも、複雑で時間のかかる方法で失敗しました。有望に見えた自律的な性質はむしろ足かせとなり、Devin は根本的な障害に気づくことなく、不可能な解決策を追求するために数日間を費やしてしまいました。

これは、AI ツールにおいて繰り返し観察されるパターンを反映しています。ソーシャルメディア上の熱狂や企業の評価額は、現実世界での実用性とはほとんど関係がありません。最も信頼できるシグナルは、製品やサービスをリリースするユーザーの詳細なストーリーから得られることがわかりました。当面は、開発プロセスを主導しつつ、その過程で AI の支援を提供してくれるツールを使い続けることにします。

付録：Devin で試みたタスク

以下に、Devin に与えたプロジェクトの一覧を示します。テーマ別に分類されています：(1) 新規プロジェクトの作成、(2) リサーチ、(3) 既存コードベースの分析、(4) コードベースの変更。

1. 新規プロジェクトの作成

プロジェクト名

ステータス

説明

考察

Planet Tracker

成功

木星と土星の歴史的な位置に関するいくつかの主張を否定したかったのです

Devin は見事にこなしました。実際、Slack を通じてスマホから Devin と対話し、その場で実現させました。

Notion から Google スプレッドシートへのデータ移行

成功

私は Devin に、Notion ドキュメントの情報をプログラムで取得して Google シートに転送するよう指示しました。これは私が Devin を使って実行した最初のプロジェクトであり、見事に完了しました。Devin は Notion と Google API のドキュメントを自ら読み込みました。また、Google Cloud コンソールへのナビゲーションを案内し、クリックすべき各メニューに関する手順も提供してくれました。これらは私自身でやれば相当な時間がかかる作業でした。最終的には、このタスクを実行する適切な Python スクリプトが手元に残りました。

これは私が Devin と行った最初のやり取りであり、期待したとおりに正確に動作しました。私にとっては全く新しい経験でした。この時点で私は Devin に対して非常に興奮していました。

Railway での複数アプリデプロイ

結論が出ない

私は Devin に、複数のアプリケーションを単一の Railway デプロイメントに展開し、異なるアプリがテスト用に同じローカルデータベースを共有できるように指示しました。

実は、私の理解ではこれは実際には不可能なタスクであり、定義が不十分だったようです。しかし、Devin はその課題に取り組み続け、Railway との連携方法についていくつかの誤った情報（ハルシネーション）を生成してしまいました。

合成データの生成と Braintrust へのアップロード

失敗

私は LLM 観測プラットフォームである Braintrust のテスト用に、合成データを作成するよう Devin に依頼しました。

Devin は理解しにくいほど複雑なコードを作成し、エラー修正に苦労して行き詰まってしまいました。最終的には、Cursor を使って段階的かつ反復的な手法でこのステップを完了させることになりました。

2 つのアプリケーション間の統合を作成する

失敗

私は、AI ノートテーカーである Circleback と Spiral.computer の間に、それぞれのドキュメントへのポインタを含む統合を Devin に作成するように依頼しました。

しかし、得られたのは非常にひどいスパゲッティコードで、ゼロから自分で書くよりもはるかに読みづらかったです。そこで、この特定のタスクに Devin を使うためにさらに時間を投資しないことに決めました。

Google Scholar のリンクを追跡して論文をウェブスクレイピングする

失敗

私は、Playwright を使用して Google Scholar から著者の最新の 25 件の論文をプログラムで取得し、有料壁（ペイウォール）に遭遇した場合はその特定の文書をスキップしてもよいと Devin に指示しました。

Devin は HTML の解析を試みるうちに抜け出せない罠にはまり込み、立ち往生してスリープ状態になってしまいました。

HTMX を使用した最小限のバッチアップロード例アプリを作成する

失敗

私は、HTMX のドキュメントページにあるバッチ編集の例を読み、それと疑似サーバーコードを基に、FastHTML ガラリー向けのこの例の最小限の FastHTML バージョンを作成するように Devin に依頼しました。

しかし、作成された例は動作せず、また最小限でもありませんでした。Devin は存在しないリクエストオブジェクト内のオブジェクトを使用し、トースト（これも動作しませんでした）やインライン CSS スタイリングなど、多くの不必要な要素を追加してしまいました。

FrankenUI のテーマに合わせるための DaisyUI テーマを作成する

失敗

Devin に、DaisyUI と highlight.js のテーマを FrankenUI のテーマに合わせて作成し、同じアプリでシームレスに使用できるように依頼しました。

Devin は DaisyUI の既存のテーマを FrankenUI のテーマにマッピングしましたが、多くの場合でうまく一致しませんでした。また、理解できないほど大量の変更が必要となり、結局何をすべきか混乱してしまい、その成果は一切使いませんでした。

1. 調査を行う

プロジェクト名

ステータス

説明

考察

Discord ボットの作成方法を調査する

成功

Devin に、Python を使用して Discord ボットを構築し、毎日のメッセージを要約してメールを送信する方法について調査を依頼しました。また、可能であれば Claudette を利用するように指示しました。最後に、その調査結果をノートブックに記述し、私がテストに使える小さなコードスニペットを含めるよう求めました。

Devin は、ノートブックを作成する中間ステップとして Markdown ファイル形式の調査メモを作成しましたが、これは私が求めていなかったものです。しかし、実装がどのように組み立てられるかという段階的な計画を見ることができ、非常に役立ちました。ノートブックで提供されたコードは 100% 正確ではありませんでしたが、これらをどうつなぐかのイメージを得るための疑似コードとして有用でした。これは主に調査プロジェクトであり、一般的なアイデアを知りたいだけだったため、これは成功と呼べます。

正確なタイムスタンプを伴うトランスクリプト要約に関する研究

失敗

私がトランスクリプトの要約に取り組む際に直面する課題の一つは、ノートに付随する正確なタイムスタンプを取得したいという点です。これにより、YouTube のチャプターサマリーや同様の用途で活用できるはずです。具体的には、トランスクリプトから正確なタイムスタンプを取得すること自体に問題はありませんが、タイムスタンプを要約と関連付けることが困難です。なぜなら、タイムスタンプの処理がしばしば不正確になるからです。したがって、これは一種の AI エンジニアリング研究課題と言えます。

Devin は私の問題に関連する事項を反復して提示しましたが、実際にこの問題を解決しようとはせず、研究や問題解決への取り組みも十分ではありませんでした。また、私にとって有益ではないコードや例示への指針を示すにとどまりました。

例として最小限の DaisyUI テーマを作成する

失敗

私は Devin に、例として最小限の DaisyUI テーマを作成するよう依頼しました。私の目的は、より包括的な方法での作成が成功しなかったため、そこから始められる出発点を得ることでした。

Devin はこれを FastHTML アプリとして作成するというリクエストを無視しており、その方向に進めるために何度かのやり取りが必要でした。最終的に、異なるボタンタイプと連携しているように見えるアプリを作成しました。見た目は良好なリンクを提供しましたが、実際にテーマの修正を試みると、そのテーマが何の役割も果たしていないことが明らかになりました。アプリ内の他の色はデフォルトのテーマからのものでした。これは有益な出発点とは言えません。

1. 既存コードの分析

プロジェクト名

ステータス

説明

考察

コードベースのセキュリティレビューの実行

結論が出ない

このタスクでは、Devin に GitHub リポジトリを指させ、セキュリティ上の脆弱性を評価するよう指示しました。対象となるコードベースは 700 行未満です。必要に応じてサンプルコードを含む markdown ファイルにメモを書くように指示しました。

Devin はいくつかのセキュリティ上の脆弱性を特定しましたが、非常に過剰反応し、存在しない問題も幻覚として報告してしまいました。おそらくこれは Devin にとって最適なタスクではなかったでしょう。この種の作業は、お気に入りの大規模言語モデル（LLM）への単一の呼び出しでも同等に良好な結果が得られるはずです。

ブログ記事のレビューと改善点を含むプルリクエストの作成

失敗

Devin にブログ記事をレビューし、変更点を提案してプルリクエストを作成するよう依頼しました。最終的に Devin は失敗しました。私が使用していた静的サイトジェネレーター（Quarto）の仕組みを理解できなかったためです。

このタスクは Cursor のような環境内であれば成功したかもしれません。Devin はプロジェクト構造や既存ファイルから十分に学習できておらず、ブログ記事を正しく編集するために必要なフロントマターやその他の規約を誤って扱ったようです。

アプリケーションのレビューと改善が期待される領域の特定

失敗

先に言及したタイムキーピングアプリを Devin に表示させ、改善点を提案するようオープンエンドなタスクを与えました。

Devin が提示した提案は全く意味をなしませんでした。

セットアップスクリプトで SSH キー転送が動作しない理由のデバッグ

結論出