Devin AI 公式活用ガイド（3/3）：良い指示 vs 悪い指示【Essential Guidelines翻訳】
Devin AI を効果的に活用するための公式ドキュメント「Essential Guidelines」の最終パート、Good vs. Bad Instructions の翻訳です。具体的な指示の良い例と悪い例を比較しながら、Devin への効果的な指示方法を解説しています。
「Essential Guidelines」(原文)の他のパートはこちらです。
- When to Use Devin （第 1 パート）
- Instructing Devin Effectively （第 2 パート）
翻訳記事については以下で公開しています：
- Devin AI 公式活用ガイド（1/3）：いつ Devin を使うべきか【Essential Guidelines 翻訳】
- Devin AI 公式活用ガイド（2/3）：Devin への効果的な指示方法【Essential Guidelines 翻訳】
何が機能し、何が機能しないのか。
より重要なヒントについては、When to Use Devin と Instructing Devin Effectively を必ず読んでください。
新しい API エンドポイントの追加
良いアプローチ
「ユーザー数と平均サインアップ年齢を含む JSON オブジェクトを返す新しいエンドポイント /users/stats を作成してください。既存の 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%を超えていることを確認してください。また、有効な認証情報と無効な認証情報の両方でテストがパスし、ログアウトがセッションデータを適切にクリアすることを確認してください。」
なぜ良いのか？ 明確な成功指標（80%のカバレッジ）、Devin をガイドするための参照（UserService.test.js）、および特定の検証ステップを伴う明確に定義されたスコープ。
既存コードの移行またはリファクタリング
「logger.js を JavaScript から TypeScript に移行してください。検証のために tsconfig.json と LoggerTest.test.js スイートが既にあります。エラーなしでコンパイルされることを確認し、既存の設定を変更しないようにしてください！移行後、次の方法で検証してください：1）tsc を実行して型エラーがないことを確認する、2）npm test LoggerTest.test.js でテストスイートを実行してすべてのテストがパスすることを確認する、3）コードベース全体の既存のロガーメソッド呼び出しがすべて型エラーなしで機能することを確認する。」
なぜ良いのか？ 即時のフィードバックのための明確なテンプレート（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 は人間のように「見る」ことができず、詳細を完全に把握できません。これらのユースケースには最適化されていません。
非常に複雑で曖昧なプロジェクト
「アプリ用の新しいマイクロサービスアーキテクチャを構築してください。」
なぜ悪いのか？ これは非常に大規模で構造化されていないタスクです。アーキテクチャの決定とトレードオフが必要です。
代わりに、複雑なプロジェクトをフェーズに分割します：
- Devin にコードベースを調査させます。
- Devin に特定のアーキテクチャを提案させます。
- 各部分を実装するために個別のセッションを作成します。
この記事は、Good vs. Bad Instructions を翻訳したものです。
Discussion