https://docs.devin.ai/essential-guidelines/when-to-use-devin

devin.md

Devinをいつ使うか

要約:
Devinをジュニアエンジニアのように扱ってください。十分で明確な指示があれば、ジュニアエンジニアやインターンでも解決できるタスクをDevinに任せられます。人間の同僚に与えるのと同じレベルの詳細な指示を与えることを忘れないでください。

ベストプラクティス

1日の始まりに複数のDevinを並行して動かす

• TODOリストの整理:
  自分のTODOを考え、インターン（Devin）が手伝える小さなタスクに分割する。

• ドラフトPRのレビュー:
  昼食時にレビュー待ちのドラフトPRに戻る。

SlackスレッドでDevinをタグ付けして迅速な修正を

• 迅速なタスク:
  30分で終わるタスクでも、数週間にわたる大きなバックログになりがちなものにDevinは適しています。

VSCode拡張機能を利用して小さなリファクタリングを

• 作業の引き渡し:
  Devin VSCode拡張機能 を使用することで、主要なタスクに集中しながら作業を引き渡すのが容易になります。

• コード共有:
  Cmd+GでDevinにコードスニペットをすばやく共有できます。

容易に検証できるタスクに注力する

• 検証の容易さ:
  CIがパスするか、または自動デプロイが正常に動作することを確認できるタスクが理想です。タスクが正しく完了したように見えても、実際には問題があるような曖昧なタスクは避けましょう。

小さく始める

• 試行:
  最初は、Devinの最適な使用例を見つけるために、多くの小さな実行を試してみてください。

• セッション管理:
  一回の実行に10 ACU以上を使わないように注意しましょう。長いセッションではDevinのパフォーマンスが低下します。

Devinへのタスクの評価

タスクがDevinに適しているかどうかを判断する際、最初に自問すべき質問は：

「十分な時間と文脈があれば、ジュニアエンジニアでも解決できるか？」

です。

タスク前のチェックリスト

タスクの複雑さ

• 必要な判断や難しい決断事項を考慮する
• インターンが直面しうる失敗のルートを特定する
• 高度な専門知識が必要なタスクの場合、タスクをさらに細分化するか、関連する文脈を提供する

タスクの定義と範囲

• 良いタスクは、明確な開始点と終了点があり、成功基準（例: テストに合格、既存パターンとの一致）が設定されています。

利用可能なリファレンス

• Devinが従うべき例やパターンが存在するか
• コードベースやドキュメントから、プロトタイプ、部分的なコード、または既存パターンを提供できるか
• Devinが参照できるリンクやファイル名を提供することは非常に有用です

成功の検証

• テストスイート、lintチェック、またはコンパイル手順があるタスクは、より良い結果を生み出します
• 主観的な基準を持つタスクは、検証が難しい場合があります

レビューの労力

• 理想的には、CIがパスするかどうかを確認するだけで済む、または自動デプロイのテストを迅速に実施できるタスクが望ましいです

タスクの規模

• 大きなタスクは、サブタスクや複数のセッションに分割することを検討してください
• 大きなリクエストを小さく管理しやすい部分に分割することで、Devinが正しい方向に進みやすくなります

タスク後のレビュー

セッション時間の監視

• Devinが繰り返しセッション使用制限に達する場合、そのタスクは複雑すぎる可能性があります
• より詳細な指示やガードレールを提供する必要があるかもしれません
• Devinがどこに時間を費やしているかを調査することを検討してください
• Devinが開発環境で苦戦している場合は、Workspaceの設定を再確認してください
• Devinを再び軌道に乗せるより、自分でタスクを完了する方が早い場合もあります

Devinのミスから学ぶ

• 今後のセッションでは、Devinが以前の障害を乗り越えられるように、より多くの文脈や指示を提供してください
• Devinが以前のセッションで学んだことを記憶できるように、Knowledgeの追加または承認を検討してください

Devinを効果的に指示する方法

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

Devinに指示を与える際に最も重要なのは、できるだけ具体的であることです。ちょうど同僚にコードを書いてもらうときに詳細な仕様を伝えるように、Devinに対しても同様に詳細な指示を与えてください。このガイドでは、Devinの有用性を最大限に引き出すために、指示やプロンプトをどのように構造化すべきかを説明します。

ベストプラクティス: やるべきことと避けるべきこと

意見を持ち、具体的にする

やるべきこと: 明確な指示を与える

• 理由:
  明確な道筋がないと、または解釈の幅が広すぎると、Devinは進むべき方向を見失ってしまいます。
• 方法:
  • Devinのために重要な決定や判断を行う。
  • 具体的なデザインの選択や実装戦略を提示する。
  • 明確な範囲、境界、および成功基準を定義する。
• 例:
  「orderService.js 内の getOrderDetails クエリを最適化してください。具体的には、order_items テーブルの order_id と product_id カラムに複合インデックスを追加し、既存の相関サブクエリを、製品詳細を取得するための products テーブルとの JOIN に置き換えてください。」

避けるべきこと: 判断を委ねすぎる

• 理由:
  曖昧な指示は、Devinが実際のニーズに沿わない解決策を実装してしまう原因となります。
• 方法:
  • 十分なガイダンスなしに、Devinに大きなデザインや実装上の決定を任せない。
• 例:
  「データベースのパフォーマンスを改善する。」（は避けるべき）

Devinの強みを活かす

やるべきこと: Devinが得意なタスクを選ぶ

• 理由:
  Devinの能力に沿ったタスクを割り当てることで、最小の労力とACUで最大の結果を得ることができます。Devinの能力を大きく超えるタスクは、望ましくない結果につながる可能性があります。
• 方法:
  • このガイド「Devinをいつ使うか」を参考にする。
  • 特に高度なタスクの場合、Devinが従える例、モジュール、リソース、テンプレートを提供する。
    • APIリクエストボディや機能の詳細を理解するためのドキュメントサイトへの直接リンクを共有する。
    • Devinに学習させたい特定のファイル名を提示する。
• 例:
  • 「Headerコンポーネントの状態管理を、Reactの useReducer フックを使うようにリファクタリングしてください。既存の機能は保持し、新しい状態ロジックに対してユニットテストを追加してください。」
  • 「一貫性のために、authTemplate.rs を参考にしてください。」
  • 「移行手順については、公式Sequelizeドキュメント（https://sequelize.org/docs/v6/getting-started/）を確認してください。」

避けるべきこと: Devinのコア能力外のタスクを割り当てる

• 理由:
  高度な専門知識や大きなデザインの決定を必要とするタスクを十分なガイダンスなしに任せると、効率が低下し、ACUの無駄遣いになります。
• 方法:
  • 明確な指示や参照がないまま、創造的または高レベルな戦略的入力が必要なタスクを避ける。
  • 強い視覚能力が必要なタスク（例: Figmaのデザインの実装）は避ける。Devinはウェブページを閲覧できますが、完璧な視覚能力はありません。
  • 携帯電話にアクセスできず、テストが困難なため、モバイルアプリの作成は避ける。
• 例:
  • 「新しい認証システムをゼロから作成してください。」（は避けるべき）
  • 「このFigmaモックアップをReactコンポーネントに変換してください。」（は避けるべき）
  • 「AI搭載のショッピングアプリを作ってください。」（は避けるべき）

必要に応じて引き継ぐ

やるべきこと: 部分的なタスクを共同で完了する

• 理由:
  最後の20%をあなたが仕上げる方が、全体として早い場合があります。
• 方法:
  • Devinに大部分の実装を任せ、最後にあなたが仕上げる。
  • 繰り返しの作業部分はDevinに任せ、より重要な部分に集中する。
• 例:
  「新しいAPIエンドポイントの初期ボイラープレートコードを生成してください。その後、私が既存の認証システムと統合します。」

避けるべきこと: 複雑なプロジェクト全体をDevinに丸投げする

• 理由:
  微妙な理解や創造的な問題解決が必要なタスクをDevinに任せすぎると、遅延や期待外れの結果につながります。
• 方法:
  • 大規模で人間の介入が必要なタスクは、Devinに依存しない。
• 例:
  • 「新世代AI機能のためのバックエンドインフラ全体を開発してください。」（は避けるべき）

フィードバックループの活用

やるべきこと: 明確かつ頻繁なチェックを設ける

• 理由:
  あなた自身やテスト、チェック、リンターからの頻繁なフィードバックにより、Devinはミスを効果的に修正できます。
• 方法:
  • 単体テストや統合テストを実施して正確性を確認する。
  • ビルド検証、リンター、静的解析を維持し、コード品質を確保する。
  • 進捗をWorklogで追跡する。
• 例:
  • 「各イテレーション後に npm test を実行してください。」
  • 「CircleCIのパイプラインが失敗しないことを確認してください。」
  • 「コミット前にESLint/Prettierチェックをパスしてください。」

避けるべきこと: フィードバックを提供しない

• 理由:
  フィードバックがなければ、Devinはその解決策があなたの基準に合致しているか判断できません。
• 方法:
  • 評価方法を明示せずにタスクを割り当てない。

チェックポイントの設定

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

• 理由:
  複雑なタスクを小さなチェックポイントに分割することで、Devinは集中しやすくなり、エラーを減らすことができます。
• 方法:
  • タスクを検証可能なサブタスクに分割し、各サブタスクごとにDevinセッションを開始する。
  • 各サブタスクの成功基準を定義し、必要に応じて内部のチェックポイントも設定する。
  • 各チェックポイントやサブタスク完了後に、Devinに報告させる。
• 例:
  • 「データセットを扱う際は、少なくとも500行があり、カラムX、Y、Zが含まれていることを確認してください。」
  • 「API修正時は、エンドポイントがステータス200を返し、必要なフィールドがすべて含まれていることを確認してください。」
  • 「UI更新時は、コンポーネントがコンソールエラーなくレンダリングされ、デザイン仕様に沿っていることを確認してください。」

避けるべきこと: 明確な検証要件を省略する

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

プレイブックの利用

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

例: 効果的なプロンプトの作成

具体的な例を示すことで、ベストプラクティスの適用方法を明確に説明します。以下は、Devin向けの適切なプロンプト例と、その効果についての説明です。さらに例やヒントについては、Prompting Adviceガイドも参照してください。

In the Devin repo, I want you to build a tool that monitors the RAM and CPU usage of the remote machines that Devin runs on. To do that, please perform the following tasks:

  * Create a background task that launches automatically when devin.rs starts.
  * The task should open a connection to all forked remote machines used in this Devin session and monitor their RAM and CPU usage.
  * If usage exceeds 80% of the available resource, emit a new type of Devin event to signal this (check how we use Kafka).
  * Architect this in a smart way that doesn’t block other operations. You should understand how all the containers for the Devin sub-agents interact with each other.

日本語訳：

Devinリポジトリで、Devinが実行されるリモートマシンのRAMとCPU使用率を監視するツールを構築してほしいと思います。そのために、以下のタスクを実行してください：

  * devin.rsが起動したときに自動的に起動するバックグラウンドタスクを作成してください。
  * このタスクは、このDevinセッションで使用されるすべてのフォークされたリモートマシンへの接続を開き、それらのRAMとCPU使用率を監視する必要があります。
  * 使用率が利用可能なリソースの80%を超える場合、これを通知するための新しいタイプのDevinイベントを発行してください（Kafkaの使用方法を確認してください）。
  * 他の操作をブロックしない賢い方法でこれを設計してください。Devinのサブエージェント用のすべてのコンテナがどのように相互作用するかを理解する必要があります。

なぜこのプロンプトが効果的なのか

有益な文脈を提供している

• 詳細:
  Devinリポジトリと、リソース使用量の監視という全体的な目的が明示されています。
• 効果:
  Devinはタスクの範囲とドメインを明確に理解できます。

段階的な指示を与えている

• 詳細:
  「背景タスクの作成」や「80%使用時のイベント発火」など、具体的なタスクに分割されています。
• 効果:
  作業が論理的に分割され、進めやすくなります。

明確な成功基準を定義している

• 詳細:
  80%使用時に特定のイベントを発火することを「成功」と定義しています。
• 効果:
  Devinは達成すべき目標を正確に把握できます。

既存のパターンやコードを参照している

• 詳細:
  Kafkaやコンテナの相互作用について言及しています。
• 効果:
  既存のコードや設計手法の再利用が促進されます。

プロンプト改善ボタンの利用

セッション作成時に、黄色い警告サークル（プロンプト改善ボタン）をクリックしてフィードバックを確認してください。

結論

十分な構造と明確な指示により、信頼性が高く満足のいく成果を得ることができます。

良い指示 vs 悪い指示

Devin にタスクを依頼する際、指示の質が最終的な成果物に大きく影響します。以下は、効果的な指示（良い指示）と、避けるべき指示（悪い指示）の例を示しています。

悪い指示の例

• 抽象的すぎる指示

  • 例: 「コードを改善してください。」
  • 問題点: 何をどのように改善すべきかが不明確で、Devin が適切な判断を下しにくくなります。

• 曖昧な要求

  • 例: 「もっと良い設計にして。」
  • 問題点: 「良い設計」が何を意味するのか、評価基準が示されておらず、解釈の幅が広すぎます。

• 不十分な情報提供

  • 例: 「エラーハンドリングを追加してください。」
  • 問題点: 対象となるエラーや具体的な処理方法、または文脈が不足しているため、Devin が正しい実装方針を判断できません。

良い指示の例

• 具体的で詳細な指示

  • 例: 「orderService.js 内の getOrderDetails クエリを最適化してください。具体的には、order_items テーブルの order_id と product_id カラムに複合インデックスを追加し、既存の相関サブクエリを、製品詳細を取得するための JOIN に置き換えてください。」
  • メリット: タスク内容と成功基準が明確に定義されているため、Devin が実装すべき内容を正確に理解できます。

• 段階的なアプローチ

  • 例: 「まず、現状のコードの問題点を洗い出してください。その後、改善策を 3 つ提示し、最適と思われるものを実装してください。」
  • メリット: 問題の分析と解決策の提示というステップが明確に分かれており、タスク全体の流れが整理されます。

• 具体的な参照と文脈の提供

  • 例: 「公式ドキュメント（例: Sequelize のドキュメント）を参考にして、エラーハンドリングの実装を修正してください。既存のコードは authTemplate.rs を参照してください。」
  • メリット: 必要なリソースや文脈が提供されることで、Devin が期待される実装の方向性を正確に把握できます。

なぜ良い指示が重要なのか

• 正確な成果物の獲得:
  明確な指示があることで、Devin はタスクの目的や成功基準を正確に理解し、望む結果を返しやすくなります。

• 作業効率の向上:
  具体的な指示により、フィードバックや修正の回数が減少し、全体の作業効率が向上します。

• 期待値の一致:
  成果物に対する評価基準が明確なため、タスク完了後の認識のずれを防ぐことができます。