メインコンテンツへスキップ
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 によってセッションデータが正しくクリアされることも確認してください。”
なぜ良いか? 明確な成功指標（80% のカバレッジ）、Devin が参照できるガイド（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 操作が引き続きデータ整合性を維持していることを検証してください。”
なぜ良いか? Devin は既存のパターンを踏襲でき、明示的な参照（OrderModel.js）があります。また、Devin が参照できるようドキュメントへのリンクを提供しており、具体的なパフォーマンスおよび機能検証手順と正確なテストコマンドも含まれているためです。

​
よくない例

自由形式のコードレビュー

“このコードベースの問題を見つけて修正して”
なぜよくないか？ リクエストがあいまいで、1つのセッションでDevinにあまりにも多くのタスクを求めています。長時間のセッションではDevinが混乱する可能性があります。

ビジュアルデザインのタスク

“このFigmaモックとまったく同じものを作って”
なぜよくないか？ 主観的なビジュアル要件だからです。Devinは人間と同じようには「見る」ことができず、細部まで完全に再現することはできません。このようなユースケース向けには最適化されていません。

非常に複雑かつあいまいなプロジェクト

“このアプリ向けに新しいマイクロサービスアーキテクチャを構築して。”
なぜよくないか？ 規模が非常に大きく、構造化されていないタスクだからです。アーキテクチャ上の意思決定やトレードオフが必要になります。代わりに、複雑なプロジェクトはフェーズに分解してください:
  1. Devinにコードベースを調査させる
  2. Devinに具体的なアーキテクチャ案を提案させる
  3. 各パートの実装用に個別のセッションを作成する