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