メインコンテンツへスキップTLDR: Devin はジュニアエンジニアとして扱ってください。十分に明確な指示があれば、ジュニアエンジニアやインターンでも対応できるタスクを Devin に任せましょう。人間の同僚に指示するときと同じレベルの詳細さで Devin に伝えるようにしてください。コーディングエージェントを効果的に活用するための、より包括的なガイドラインについては、Coding Agents 101 guide を参照してください。
1日の始めに、複数の
Devin を並行して動かしましょう：
- 自分の TODO を整理し、インターンのチーム（Devin たち）が手伝えるような小さなタスクに分割します。
- お昼前後に、レビュー待ちのドラフト PR に戻りましょう。
素早い修正がほしいときは、
Slack スレッドで Devin をメンションしましょう：
- Devin は、実作業時間は 30 分のタスクをさばくのに最適です。多くの場合、それらは数週間バックログにたまってしまいます。
検証しやすいタスクに
集中しましょう：
- 理想的には、CI が通るか、あるいは自動デプロイをテストするだけで確認できるタスクです。タスクが一見正しく完了しているように見えても、実際には別のことが起きているような曖昧なタスクは避けてください。
小さく始めましょう：
- 使い始めのうちは、小さな実行をたくさん試して、Devin の最適なユースケースを見つけてください。
- 1 回の実行にあまり多くの ACU（10 超）を使わないようにしましょう。長時間のセッションでは Devin のパフォーマンスが低下します。
タスクが Devin に適しているかを判断するとき、まず自問すべきなのは次の問いです：十分な時間とコンテキストがあれば、ジュニアエンジニアでもこれを解決できるだろうか？
タスクの複雑さ
- どのような判断や難しい意思決定が必要になるか検討する
- インターンが直面しそうな潜在的な失敗パターンを洗い出す
- 高度なドメイン知識を要するタスクは、さらに分解するか、関連するコンテキストを提供する
タスクの定義とスコープ
- 良いタスクには、明確な開始・終了と成功基準（例: テストが通る、既存パターンに一致する）がある
利用可能な参照情報
- Devin が参考にできるサンプルやパターンはありますか？
- プロトタイプ、部分的なコード、コードベースやドキュメント内の既存パターンを提供できますか？
- Devin が参照できるリンクやファイル名を渡しておくと非常に役立ちます。
成功の検証方法
- テストスイート、lint チェック、コンパイル工程があるタスクの方が、より良い結果になりやすい
- 主観的な基準が多いタスクは、難易度が上がる可能性がある
レビュー工数
- 理想的には、CI が通っていることを確認するか、自動デプロイをすぐにテストできる程度で済むのが望ましい
タスクの規模
- 大きなタスクは、サブタスクや複数のセッションに分割することを検討する
- 大きなリクエストを小さく扱いやすいまとまりに分けることで、Devin が軌道に乗り続けやすくなる
セッション時間を確認する
- Devin がセッション使用上限に繰り返し達してしまう場合、そのタスクは Devin にとって複雑すぎる可能性があります
- さらに詳細な手順や制約・ルール（ガードレール）を提供する必要があるかもしれません
- Devin がどこに時間を費やしているかを確認・調査することを検討してください
- Devin が開発環境でつまずいている場合は、Workspace setup を見直してください
- 場合によっては、Devin を立て直そうとするより、自分でタスクを完了してしまうほうが早いこともあります
Devin のミスから学ぶ
- 次回以降のセッションでは、以前の障害を乗り越えられるよう、より多くの前提情報や指示を Devin に与えてください
- Devin が過去のセッションで学んだことを保持できるように、Knowledge を追加または承認することを検討してください
