Zenn
💭

Devin AI 公式活用ガイド（2/3）：Devinへの効果的な指示方法【Essential Guidelines翻訳】

に公開
AI
翻訳
Devin
Vibe Coding
tech

Devin AI を効果的に活用するための公式ドキュメント「Essential Guidelines」の第 2 パート、Instructing Devin Effectively の翻訳です。

「Essential Guidelines」(原文)の他のパートはこちらです。

翻訳記事については以下で公開しています：

Devin にタスクを依頼する際の具体的な指示の出し方について解説されています。

最適な結果を得るための方法。

Devin に指示を出す際に最も重要なことは、可能な限り具体的にすることです。同僚に何かをコーディングしてもらう際に詳細な仕様を提供するのと同じように、Devin に対しても同じことを行うべきです。このガイドは、Devin の有用性を最大限に高めるために、指示やプロンプトを構成するのに役立ちます。

プロンプトの例

なぜこれがうまく機能するのか

役立つコンテキストを提供

  • 詳細: Devin リポジトリとより広範な目的（リソース使用状況の監視）を指定します。
  • 利点: Devin はスコープとドメインを明確に把握します。

ステップバイステップの指示を与える

  • 詳細: 「バックグラウンドタスクを作成する」や「80% の使用量でイベントを発行する」などのタスク。
  • 利点: 作業を論理的な部分に分割します。

明確な成功基準を定義

  • 詳細: 80% の使用量で特定のイベントを発行することを「成功」と定義します。
  • 利点: Devin は達成すべきことを正確に把握します。

既存のパターンとコードを参照

  • 詳細: Kafka とコンテナの相互作用について言及します。
  • 利点: 確立されたコードや設計アプローチの再利用を奨励します。

セッションを作成する際にプロンプト改善ボタンを試してみてください（フィードバックを表示するには黄色の警告アイコンをクリックしてください）。

ベストプラクティス：すべきこととすべきでないこと

意見を持ち、具体的に

すべきこと：明確な指示を提供する

  • 理由: Devin は明確な道筋がない場合や、解釈が多すぎる場合に立ち往生する可能性があります。
  • 方法:
    • Devin のために重要な決定と判断を行います。
    • 具体的な設計の選択肢と実装戦略を提示します。
    • 明確なスコープ、境界、成功基準を定義します。
  • 例: 「orderService.js の getOrderDetails クエリを最適化するために、order_items テーブルの order_id と product_id カラムに複合インデックスを追加してください。既存の相関サブクエリを製品詳細を取得するための products テーブルへの JOIN にリファクタリングしてください。」

すべきでないこと：決定をオープンエンドにする

  • 理由: 曖昧な指示は、Devin が実際のニーズに合わないソリューションを実装することにつながる可能性があります。
  • 方法:
    • ガイダンスなしに Devin が重要な設計または実装の決定を行う必要があるような記述は避けてください。これは予期しない結果につながる可能性があります。
  • 例: すべきでないこと：「データベースのパフォーマンスを向上させてください。」

Devin の強みを活用する

すべきこと：Devin が得意なタスクを選ぶ

  • 理由:
    • 結果の最大化: Devin の能力に合ったタスクを割り当てることで、最小限の労力と ACU 消費で最良の結果を得ることができます。Devin の現在の能力をはるかに超えるタスクを依頼すると、しばしば悪い結果につながる可能性があります。
  • 方法:
    • このガイドを読む：When to use Devin
    • 特に高度なタスクについては、Devin が従うことができる例、モジュール、リソース、テンプレートを提供します。
      • Devin が API リクエストボディや知らない可能性のある機能などの詳細について読めるように、ドキュメントサイトへの直接リンクを共有します。
      • Devin に見て学んでほしい特定のファイル名を共有します。
    • 例: すべきこと：「Header コンポーネントの状態管理を、スケーラビリティと保守性を向上させるために React の useReducer フックを使用するようにリファクタリングしてください。既存のすべての機能が維持されるようにし、新しい状態ロジックをカバーするユニットテストを追加してください。」
    • 例: すべきこと：「エラー処理の一貫性を維持するために authTemplate.rs を参照として使用してください。」
    • 例: すべきこと：「移行手順については、公式 Sequelize ドキュメント https://sequelize.org/docs/v6/getting-started/ を確認してください。」

すべきでないこと：Devin のコアコンピテンシー以外のタスクを割り当てる

  • 理由: 適切なガイダンスなしに高度なドメイン知識や大規模な設計決定を必要とするタスクを割り当てると、非効率性と ACU の無駄遣いにつながる可能性があります。
  • 方法:
    • 明確な指示や参照なしに、重要な創造的または高レベルの戦略的入力を必要とするタスクは避けてください。
    • Devin はウェブページを見ることができますが、完璧な視力を持っているわけではないため、Figma デザインの実装など、強力な視覚能力を必要とするタスクは避けてください。
    • Devin は電話にアクセスできず、作業を簡単にテストできないため、モバイルアプリの作成を依頼することは避けてください。
  • 例: すべきでないこと：「私のウェブサイト用の新しい認証システムをゼロから作成してください。」
  • 例: すべきでないこと：「この Figma モックアップを React コンポーネントに変換してください。」
  • 例: すべきでないこと：「AI 搭載のショッピングアプリを構築してください。」

必要に応じて引き継ぐ

すべきこと：部分的なタスクを完了することで協力する

  • 理由: タスクの最後の 20% を自分で完了する方が速い場合があります。
  • 方法:
    • 実装の大部分を Devin に任せ、その後で調整します。
    • より重要な側面に集中しながら、反復的なワークフローの部分を迅速化するために Devin を使用します。
  • 例: すべきこと：「新しい API エンドポイントの初期ボイラープレートコードを生成してください。その後、既存の認証システムと統合します。」

すべきでないこと：複雑なプロジェクト全体を Devin にのみ依存する

  • 理由: 微妙な理解や創造的な問題解決を必要とするタスクに Devin に過度に依存すると、遅延や最適ではない結果を引き起こす可能性があります。
  • 方法:
    • 効果的に完了するために大幅な人間の介入が必要になることがわかっているタスクを Devin に割り当てることは避けてください。
  • 例: すべきでないこと：「新しい生成 AI 機能のバックエンドインフラストラクチャ全体を開発してください。」

フィードバックループを使用する

すべきこと：明確かつ頻繁なチェックを確立する

  • 理由: （あなたとテスト/チェック/リンターの両方からの）頻繁なフィードバックにより、Devin は間違いを効果的に修正できます。
  • 方法:
    • 正確性を確認するためにテスト（ユニット/統合）を使用します。
    • コード品質のためにビルド検証、lint チェック、静的分析を維持します。
  • 例: すべきこと：「各反復の後に npm test を実行してください。」
  • 例: すべきこと：「CircleCI のパイプラインが失敗しないようにしてください。」
  • 例: すべきこと：「コミットをプッシュする前に ESLint/Prettier チェックをパスしてください。」

すべきでないこと：フィードバックの提供を怠る

  • 理由: フィードバックがないと、Devin はそのソリューションがあなたの基準を満たしているかどうかを知ることができません。
  • 方法:
    • 評価方法を定義せずにタスクを割り当てることは避けてください。

チェックポイントを設定する

すべきこと：明確なチェックポイントとサブタスクを設定する

  • 理由: 複雑なタスクをより小さなチェックポイントに分割することで、Devin が集中し続け、エラーを減らすのに役立ちます。
  • 方法:
    • タスクを検証可能なサブタスクに分割し、サブタスクごとに 1 つの Devin セッションを開始します。
    • 各サブタスクの成功がどのようなものかを定義し、オプションで各サブタスク内にチェックポイントを設定します。
    • 各チェックポイントまたはサブタスクの完了後に Devin に報告するように依頼します。

例:

  • 例: すべきこと：「データセットを操作する際は、少なくとも 500 行あり、X、Y、Z 列が含まれていることを確認してください。」
  • 例: すべきこと：「API を変更する際は、エンドポイントがステータス 200 を返し、必要なすべてのフィールドが含まれていることを確認してください。」
  • 例: すべきこと：「UI を更新する際は、コンポーネントがコンソールエラーなしでレンダリングされ、設計仕様と一致することを確認してください。」

すべきでないこと：特定の検証要件を省略する

  • 理由: 定義された検証ステップがないと、Devin は自信を持ってタスクを完了できません。
  • 方法:
    • 曖昧な成功基準は避けてください。
    • 検証ステップを暗黙的または未定義のままにしないでください。
  • 例: すべきでないこと：「それが機能することを確認してください。」

プレイブックを使用する

反復的または複雑なタスクについては、プレイブックを使用して反復することをお勧めします。プレイブックを効果的に使用する方法について詳しく学んでください。プレイブックは、タスクの委任を合理化する再利用可能で共有可能なプロンプトです。たとえば、Devin に継続的な CI ビルドの失敗に対処させたい場合は、Devin が毎回従うべき一般的な手順を含むプレイブックを作成します。

まとめ

信頼性が高く満足のいく結果を得るために、十分な構造と明確さでタスクを構成してください。

この記事は、Instructing Devin Effectively を翻訳したものです。

Discussion