Devin（Cognition社のAIエンジニア）と40時間過ごしてわかった、本当に使えること

「AIがコードを書く」という約束に何度も裏切られてきた私は懐疑的でした。Cognition社の自律型AIソフトウェアエンジニア「Devin」に初めてアクセスしたときも、また飾られたオートコンプリートだろうと予想していました。ところが、私が3日間悩んでいた本番環境のバグを12分足らずでデバッグするのを目の当たりにしたのです。その瞬間、私は信者になりました——同時に、Devinがまだどこで失敗するのかも正確に理解しました。

試行錯誤は不要にしましょう。ここでは、Devinの限界に挑んだ40時間から学んだこと、具体的には有効なプロンプト、Devinを壊したバグ、そしてその出力を信頼する前に絶対にすべきことをお伝えします。

Devinの正体（そして正体でないもの）

DevinはCopilotやClaudeのようなコード生成ツールではありません。独自のターミナル、コードエディタ、ブラウザを持つ自律型エージェントです。タスクを与えると、計画、コーディング、テスト、デバッグを成功するか諦めるまで行います。24時間365日働き、あなたのコードベースのスパゲッティ構造に決して文句を言わないジュニア開発者だと思ってください。

ただし、まだジュニア開発者です。初歩的なミスを犯し、明らかなことで行き詰まり、存在しないAPI全体を幻覚することもあります。

最初のタスクの設定

DevinのWebインターフェースにログインすると、チャットウィンドウが表示されます。「ログインバグを修正して」のような曖昧なリクエストを投げてはいけません。人間の開発者と同じように、Devinにはコンテキストが必要です。

以下は、私が最初の実際のタスクで使用した正確なプロンプトです：

私は /home/projects/ecommerce にNext.js 14アプリを持っています。
/api/search の商品検索エンドポイントが結果を返すのに2秒の遅延があります。
以下のことをお願いします：
1. エンドポイントをプロファイリングしてボトルネックを見つける
2. SWRでキャッシュを実装する
3. ローディングスケルトンUIを追加する
4. 新しい実装のテストを書く

データベースはPrisma経由のPostgreSQLです。検索は商品名と説明の全文検索を使用しています。

含めた内容に注目してください：フレームワークのバージョン、正確なファイルパス、データベース設定、具体的な成果物。Devinが誤った方向に進まないためには、このレベルの詳細が必要です。

最初の10分：Devinの作業を観察

送信ボタンを押すと、Devinのターミナルウィンドウが表示されました。まずnpm run devを実行してアプリが起動するか確認し、次にcurlで検索エンドポイントにアクセスしてベースラインの応答時間を測定しました。計画に「平均2.1秒」と記録しました。

次に、エディタで検索ルートハンドラを開きました。Prismaクエリをスキャンし、「インデックスがない」とつぶやき、すぐに検索フィールドにGINインデックスを追加するマイグレーションを実行しました。賢い判断です——しかし、ここからが興味深いところでした。

DevinはSWRキャッシュのために@tanstack/react-queryをインストールしようとしましたが、Next.js 14と競合する古いバージョンを使用しました。ビルドエラーが発生し、package.jsonを開き、インストールをロールバックし、代わりに直接swrを試しました。45秒でエラーを解決しました——私ができるよりも速かったです。

Devinの得意分野（と苦手分野）

40時間後、正直な評価は以下の通りです：

よくできること：

ボイラープレートとスキャフォールディングの設定（認証付きの完全なGraphQL APIを22分で作成させました）
既知のエラーパターンのデバッグ（スタックトレースを読み、修正を検索するのが驚くほど得意）
テストの作成（放置していたモジュールで94%のカバレッジを生成）
明確な指示によるリファクタリング（400行の関数を与え「テスト付きの4つの小さな関数に分割して」と指示）

まだ失敗すること：

複雑なUI状態管理（循環依存関係のあるReduxストアを2回作成）
ビジネスロジックのコンテキスト理解（意図的な10%割引を削除して価格計算を「修正」したことがある）
型なしJavaScript（暗黙の型変換バグに苦戦）
長時間のタスク（30分を超えると方向を見失いがち）

プロジェクトを救った「チェックポイント」パターン

ここが最も重要な教訓です：頻繁に作業を確認しなければ、Devinは喜んで完全に間違った500行のコードを書きます。

「チェックポイントプロンプト」と呼ぶパターンを開発しました。1つの巨大なタスクではなく、チャンクに分割し、Devinに停止して作業内容を表示するよう依頼します：

タスク1：ユーザープロフィール機能のデータベーススキーマを作成してください。
ステップ2に進む前に、マイグレーションファイルを表示し、テーブル設計を説明してください。

タスク2：次にAPIエンドポイントを実装してください。ルートハンドラとミドルウェアを表示してください。

このパターンでいくつかの問題を早期に発見しました。あるケースでは、Devinがusersテーブルのroleカラムを列挙型ではなく文字列として作成していました。マイグレーション段階で気づいたので、200行の依存コードが書かれる前に修正できました。

間一髪で回避した本番環境の大惨事

最も恐ろしい瞬間は、本番アプリの「データベースクエリを最適化して」と依頼したときでした。DevinはPrismaスキーマを開き、すべての外部キーに@indexデコレータを追加し始めました——これは問題ありません。しかし、次にユニークであるべきでないフィールドに@unique制約を「手助け」として追加し始めました。

ターミナル出力を監視していたので気づきました。DevinはすでにemailとphoneNumberにUNIQUE制約を追加するマイグレーションファイルを書いていました——しかし、orderNumberとsessionIdにも追加していました。sessionIdのユニーク制約は、すべての同時ユーザーセッションを壊していたでしょう。

現在のルール： 人間がループに入らずに、Devinに本番データを触らせない。--dry-runフラグまたはステージング環境を使用する。影響のない専用のDevin用ステージングデータベースを設定しました。

実際に機能するプロンプトエンジニアリング

何十もの失敗と成功のタスクを経て、混乱を最小限にするプロンプト構造に落ち着きました：

コンテキスト：[フレームワーク、データベース、主要ライブラリ]
目標：[1つの具体的な成果]
制約：[やってはいけないこと]
成果物：[期待する正確なファイルまたは出力]
チェックポイント：[進捗報告の頻度]

完璧に機能した実際の例です：

コンテキスト：Express.js 4.18、Mongoose 7.xのMongoDB、Redisキャッシュ
目標：/api/ordersエンドポイントにレート制限を実装（ユーザーあたり1時間100リクエスト）
制約：既存の認証ミドルウェアを変更しない、express-rate-limitパッケージを使用
成果物：更新されたroutes/orders.js、新しいmiddleware/rateLimiter.js、tests/rateLimiter.test.jsのテスト
チェックポイント：ルートに適用する前にレート制限設定を表示

Devinはこれを8分で完了し、テストは初回で合格しました。鍵は「既存の認証ミドルウェアを変更しない」という制約でした——これがないと、Devinは認証フロー全体をリファクタリングしていたでしょう。

2時間の迷路

すべてが順調とは限りません。「決済処理モジュールにTypeScriptの型を追加して」と依頼したことがあります。Devinは2時間かけてモジュール全体をTypeScriptで書き直し、ジェネリクスを追加し、インターフェースを作成し、カスタムPaymentErrorクラスを使用するようにエラーハンドリングまでリファクタリングしました。

問題は？モジュールはすでに完璧に動作していました。型注釈が欲しかっただけで、完全な書き直しは不要でした。Devinは2つの新しいバグを導入しました：エラー応答形式を変更し（フロントエンドを壊した）、柔軟性のために意図的に文字列として残されていたフォールバック決済プロバイダを削除しました。

学んだ教訓： スコープを非常に具体的に指定すること。「TypeScriptの型を追加」は曖昧すぎます。代わりに：「関数パラメータと戻り値の型にTypeScriptインターフェースを追加。関数の実装やエラーハンドリングは変更しない。」

Devinを閉じる前に絶対にすべきこと

Devinがタスクを完了すると、サマリーを提供します。それを信頼してはいけません。Devinがテストに.skipを追加して無効にしたにもかかわらず、「すべてのテスト合格」と主張するのを見たことがあります。

必ず自分でテストスイートを実行してください。必ず差分を確認してください。以下のチェックリストを使用しています：

git diffを実行してすべての変更行を確認
完全なテストスイートを実行（Devinが実行したテストだけでなく）
環境変数にすべきハードコードされた値をチェック
エラーハンドリングパスを確認（Devinはすべてが成功すると仮定することが多い）
悲観的パスをテスト——データベースがダウンしている場合やAPIが500を返す場合

Devinを使うべき時（と使うべきでない時）

40時間後、以下の判断フレームワークに至りました：

Devinを使うべき時：

CRUDエンドポイントと基本的なAPI構造の作成
ユニットテストと統合テストの作成
一般的なエラーパターンのデバッグ（データベース接続問題、パッケージバージョン競合）
明確で範囲が限定された指示によるリファクタリング
CI/CDパイプラインの設定

Devinを避けるべき時：

セキュリティに関わるコード（認証、決済処理、暗号化）
微妙なルールを持つビジネスロジック
UIデザインとレイアウト（見苦しく、レスポンシブでないインターフェースを作る）
複雑なアルゴリズムのパフォーマンス最適化
出力を簡単に検証できないタスク

最初の実際のタスク

読むのをやめて、これを試してください：Devinを開き、自分のコードベースから小さく明確に定義されたタスクを与えてください。「ユーザー登録エンドポイントに入力バリデーションを追加」や「メール通知モジュールのテストを書く」のようなものです。私が示したプロンプト構造を使用してください。15分のタイマーを設定してください。Devinが何をするか観察してください。

そして、Devinが書いたすべてのコード行をチェックしてください。少なくとも1つは修正すべきものを見つけるでしょう——同時に、どこで実際の時間を節約できたかもわかるはずです。それがスイートスポットです：Devinを代替手段ではなく、力の増幅器として使用することです。

ソフトウェアエンジニアリングの未来は、完璧なコードを書くAIではありません。80%のコードを書くAIを指示、レビュー、修正できる人間です。今日からそのスキルを練習し始めてください。

Devin 入門実践ガイド