When to Use Devin と Instructing Devin Effectively を読んで、他の重要なヒントも必ず確認してください。
新しい API エンドポイントの追加
良いアプローチこの指示がうまくいく理由:
悪いアプローチこの指示が失敗する理由:
“
/users/stats という新しいエンドポイントを作成し、ユーザー数と平均登録年齢を含む JSON オブジェクトを返してください。PostgreSQL の既存の users テーブルを使用してください。レスポンスの構造は、statsController.js の /orders/stats エンドポイントを参照してください。新しいエンドポイントが StatsController.test.js スイートでカバーされていることを確認してください。”- ルートと期待されるレスポンス形式が明確に指定されている
- 既存コードをテンプレートとして参照している
- データソース（users テーブル）が定義されている
- テストカバレッジの要件が含まれている
悪いアプローチこの指示が失敗する理由:
- どの統計情報を含めるべきかが不明確
- データソースについての言及がない
- 既存パターンへの参照がない
- テスト要件が欠けている
データ表示用のフロントエンド機能
良いアプローチこの指示がうまくいく理由:
悪いアプローチこの指示が失敗する理由:
“
UserProfileComponent に、ユーザーのロール（admin、editor、viewer）の一覧を表示するドロップダウンを追加してください。スタイリングには DropdownBase を使用してください。ロールが選択されたら、既存の API を呼び出してユーザーロールを設定してください。選択内容によって DB 上のユーザーロールが更新されることを確認して検証してください。適切なテスト方法については、あなたのナレッジを参照してください。”- 特定のコンポーネント名が明示されている
- 含めるべきロールが具体的に列挙されている
- 既存のスタイリング用コンポーネントが参照されている
- ユーザーの操作フローが定義されている
- 検証手順が含まれている
悪いアプローチこの指示が失敗する理由:
- 「ユーザーフレンドリー」が主観的で曖昧
- 具体的な UI コンポーネントが示されていない
- ユーザーの操作フローが不明確
- 検証基準が曖昧
その他の例
良い例
ユニットテストの作成
“AuthService のメソッド
login と logout に対して Jest テストを追加してください。これら 2 つの関数のテストカバレッジが少なくとも 80% になるようにしてください。UserService.test.js をサンプルとして参照してください。実装後、npm test -- --coverage を実行し、両方の関数でカバレッジレポートが 80% 超になっていることを確認してください。また、有効な認証情報と無効な認証情報の両方でテストが通ること、そして logout によってセッションデータが正しくクリアされることも確認してください。”UserService.test.js）、および具体的な検証手順を含む明確に定義されたスコープがあるためです。既存コードの移行やリファクタリング
“
logger.js を JavaScript から TypeScript に移行してください。すでに tsconfig.json と検証用のテストスイート LoggerTest.test.js があります。エラーなくコンパイルできるようにし、既存の設定は変更しないでください！ 移行後は、1) tsc を実行して型エラーがないことを確認し、2) npm test LoggerTest.test.js でテストスイートを実行してすべてのテストが通ることを確認し、3) コードベース全体で既存の logger メソッド呼び出しがすべて、型エラーなしで動作し続けていることを確認してください。”tsconfig.json）と即時フィードバック用のテストスイートがあり、さらにコンパイルと検証の具体的な手順が示されているためです。API やデータベースクエリの更新
“pg から sequelize に切り替えています（https://sequelize.org/api/v6/identifiers を読んでください）。UserModel のクエリを、Sequelize のメソッドを使うように更新してください。このコードベースでの実装方法については
OrderModel を参照してください。実装後は、1) npm run test:integration UserModel.test.js を実行してすべてのインテグレーションテストが通ることを確認し、2) ユーザー 1000 件分のテストデータセットで実行時間を確認し、クエリのパフォーマンスが低下していないことを確認し、3) npm run test:e2e user-flows.test.js を実行して、すべての CRUD 操作が引き続きデータ整合性を維持していることを検証してください。”OrderModel.js）があります。また、Devin が参照できるようドキュメントへのリンクを提供しており、具体的なパフォーマンスおよび機能検証手順と正確なテストコマンドも含まれているためです。デザインからの機能実装
“この Figma ファイル（https://figma.com/file/abc123/Pricing-Page）を元に、料金ページを実装してください。「Pricing Section」フレームに注目してください。色と余白には、tailwind.config.ts にある Tailwind の設定を使用してください。
src/components/ui/ にある既存の Card コンポーネントと Button コンポーネントを再利用してください。実装後、開発サーバーを起動し、デスクトップ（1440px）とモバイル（375px）の幅でスクリーンショットを撮ってください。デザインと一致するまでは PR を作成しないでください。”本番環境のバグ調査
“ユーザーから、チェックアウトページで 500 エラーが発生しているという報告があります。Sentry MCP を使って、payments-api プロジェクトの最新のスタックトレースを取得してください。データベースを確認し、関連するデータの問題がないかチェックしてください。根本原因を特定して修正し、リグレッションテストを追加してください。PR の説明に Sentry の Issue へのリンクを追加してください。”
悪い例
オープンエンドなコードレビュー
なぜ悪い？ リクエストがあいまいでオープンエンドすぎます。成功基準がなく、Devin が完了を判断する方法もありません。代わりに: 特定の PR に対する自動コードレビューには Devin Review を使うか、「
src/services/ 内で非推奨になった oldLogger API のすべての使用箇所を見つけて修正して」のように、Devin に明確で対象を絞ったタスクを与えてください。主観的すぎるビジュアル上の依頼
なぜ悪い？ 「良く」は主観的な表現であり、Devin が目指すべき基準がありません。Devin は仕様から機能的な UI を構築したりデザインを実装したりできますが、美的な判断を自律的に行うことはできません。代わりに: Figma のデザイン、参考サイト、あるいは次のような具体的な変更内容を提示してください: 「ヒーローセクションのフォントサイズを 48px に上げて、32px のパディングを追加し、Tailwind の設定にある
indigo-500 カラーを使ってください。」極めて複雑であいまいなプロジェクト
なぜ悪い？ 非常に大きく構造化されていないタスクで、多数のアーキテクチャ上の判断やトレードオフ、そしてプロンプトには含まれていない多くのコンテキストが必要になります。代わりに、小さく分割して進める:
- Ask Devin を使ってコードベースを調査し、依存関係をマッピングする
- Devin にトレードオフも含めた具体的なアーキテクチャ案を提案させる
- 各サービスの実装用に個別のセッションを作成し、batch sessions を使って並行実行する