Devinに最適なユースケースを見極めることは、効率と投資対効果（ROI）を最大化するうえで重要です。以下では、Devinの強みを最大限に生かせるユースケースを選定するためのベストプラクティスを示します。
| 理想的なユースケースの条件 |
|---|
| 分離可能で反復的なサブタスク に分解できる、大規模かつビジネス価値の高いプロジェクト。 |
| 手動でのエンジニアリング作業時間が 90 分未満 で完了するタスク。 |
| 個別に検証してマージできる、後方互換性を保ったタスク。 |
| 要件 |
|---|
| 反復的なサブタスク（スライス）が大量にあること |
| ジュニアエンジニア相当の難易度のタスクであること |
| 分離されていて、段階的に進められるタスクであること |
| 客観的に検証可能なサブタスクであること |
| （推奨） 他プロジェクトへの依存関係が最小限であること |
| シナリオ | 信頼性上の懸念 | タスクタイプ |
|---|
| Devinに複雑な**新規機能（net-new features）**の実装を依頼する場合（たとえ反復的でも） | 規模が大きくなるほど信頼性が低下しやすい | Tall & Deep |
| Devinにシンプルで明確に定義されたタスクを割り当てる場合 | 信頼性と効果が非常に高い | Wide & Shallow |
スライスがシンプルであればあるほど、プロジェクト全体の信頼性は高まります。
- マイグレーション
- リファクタリング
- モダナイゼーション
- テクニカルデットのバックログ
たとえば、コードマイグレーションに取り組む場合は、それを独立したスライスに分割し、それぞれを個別の Devin セッションで処理します。
スライスはプロジェクトにおける最小のアトミックな単位である必要があります。
| 要件 | 詳細 |
|---|
| 時間制限 | 各スライスは、人手によるエンジニアリング作業が90分未満で完了する必要があります。 |
| 検証 | 次のようなコード変更を検証する手段を必ず含めてください:
- テストの実行
- コードのビルド
- CI チェック
- カスタム検証スクリプト |
Devin には、明確な成功／失敗の検証メカニズムが必要です。
依存関係や外部システムが過度に多いタスクは避けてください。Devin はコーディングタスクを最も得意とします。
| 要件 | 説明 |
|---|
| 分離性 | 各スライスは互いに独立しており、かつ後方互換性を維持している必要があります。 |
| 並列実行 | Devin の並列実行機能を活用して、スライスを同時に実行します。 |
| 人によるレビュー | 各スライスが完了した後、main にマージする前に人によるレビューを行う必要があります。 |
| 原則 | 説明 |
|---|
| スライス単位の信頼性 | Devin は、個々のスライス 単位で 最大限の信頼性 を発揮するよう最適化されています。 |
| スケーリング時の考慮事項 | 数千のスライス にスケールさせる場合、高い信頼性 を維持することが重要です。 |
| エラーの影響 | 大規模に実行する場合、わずかなエラー率でも累積して大きな影響を及ぼし得ます。 |
| 要件 | 説明 |
|---|
| 明確なステップの詳細 | 各スライスごとに明示的な手順を記載します。 |
| エンドツーエンドのリファレンス | 詳細なガイドまたは動画を用意すると、一貫性を保ちやすくなります。 |
| Before/After の例 | 複数のBefore/After のコード例（入力/出力のペア）を提供します。 |
| 依存関係へのアクセス | Devin がタスク実行に必要なすべての依存関係へアクセスできるようにします。 |
マイグレーション、モダナイゼーション、リファクタリングは、段階的に対応できる場合は非常に有効なユースケースです。
たとえば、すべての変更を一度に行う必要があるリポジトリ全体のマイグレーションは、推奨されません。
