こんにちは！虎の穴ラボ nagaです。

以前お伝えした通り、虎の穴ラボではAIエージェント「Devin」を導入しています。今回は導入から約3ヶ月経った今、Devinにうまく開発を進めてもらうために意識していることを3つ紹介します。 toranoana-lab.hatenablog.com

1. プロンプトを改善する

Devinが想定した実装をしてくれない・・・と感じた時は、セッションの詳細画面から消費したACUとプロンプト改善の提案を確認するのがおすすめです。

まずは先日磯部さんが紹介していた節約Tipsにもある通り、10ACU以内の作業になっているかを確認してみましょう。もし10ACUを超えている場合は、指示内容の粒度が荒いか実装規模が大きい可能性があります。 toranoana-lab.hatenablog.com

10ACUを超えていない場合でもDevinが想定通りの実装をしないことがあります。そんな時はActionable Feedbackタブからプロンプトのフィードバックを確認してみましょう。この画面では最初のプロンプトをどのように改善するのが良いかフィードバックを受けられます。
下記の例では「このPRを確認して」と指示しましたが、青下線のように指示するのが良いとフィードバックを受けました。この内容を次のプロンプトに活かすことでDevinを効率的に使えるようになっていきます。

またチームでDevinを使った開発を行っている場合、Devinの品質を均一にするためにプロンプトテンプレートを用意するのがおすすめです。テンプレートにこれまで指摘を受けた一般的な内容を記載しておくことで、各メンバーは指示の抜け漏れや品質のばらつきを気にすることなく、本当に依頼したい開発タスクの内容に集中することができます。結果として、Devinとのやり取りの効率が上がり、開発全体のスピードアップにも繋がります。

参考までに私のチームでは、下記のテンプレートを使って指示を出しています。

`xxx` サービスについて
# 仕様

# ブランチ
developからブランチを切って作業して

# 参考パターン・コード

# 完了基準
- 今回追加したテストも含めて、全ての自動テストが完了しているかチェックして

# PR作成について
- !pull-request-rules

仕様

「仕様」には実装する内容を細かく記載します。例えば、「xxテーブルから全データを取得して〇〇Entityにマッピングして」や「リクエストパラメータとしてxxを受け取って」などどういうことをしたいかを記載していきます。

ブランチ

作業ブランチを明確に指示します。特定名称のブランチを作成して欲しい場合は、「developからfeature/123/add-sampleブランチを切って作業して」のように指示できます。ブランチ名の規約がある場合は、Knowledgeへ命名規約を設定しておくことで、上記テンプレートでも意図したブランチが作成されやすくなります。

参考パターン・コード

参考パターン・コードには、今回の実装で参考になる既存コードのリンクや、特定メソッドへのパスを記載します。既存で参考にできるコードがない場合でも、「〇〇Entityへのマッピング処理は、下記のイメージで実装してください。」といったコードの断片や設計思想を記載するのも有効です。

完了基準

完了基準には、Devinがプルリクエストを作成するための条件を記載します。基本的には「全ての自動テストが完了すること」が完了基準になるかと思います。しかし、自動でのテストが難しい機能の実装の場合は、「実装ができたらPRを作成すること」のように指示することもあります。

PR作成について

PR作成方法について、特定のKnowledgeを参照するように記載しています。これは少し特殊で、私たちのDevinではPR作成に関するKnowledgeが守られることが少なかったため、プロンプトで毎回指示を書くようにしています。

2. チェックポイントを用意する

複雑なタスクを処理させたい、いきなりプロンプトに実装を落とし込むのが難しい・・・そんな時はDevinだけに開発を任せず、チェックポイントを設けて協力してタスクを進めるのがおすすめです。

下記にも記載がありますが、フィードバックループを回しながらタスクを処理することで複雑なタスクも進めていくことができます。 devin.ai

例えば下記のような形で一つ一つレビューをしながら進めることで、複雑なタスクも進めていくことができます。

「あるステータス表示に関わる全ての処理を変更したい。まずは影響箇所を列挙したら教えて」
↓
「影響箇所の1,2,3を修正したい。まずは1について〇〇のように対応ができたら教えて」
↓
「1の内容はOKなので、次は2の修正をxxみたいに実施して。終わったら教えて」
・・・

また影響範囲の調査や設計から始める場合は、新しいセッションを開始せずAsk Devinで検討を進めてからセッションに移るのも有効です。 Ask Devinでは、一度何か質問などをした後、追加の入力ボックスでCmd+Enterを入力すると、それまでの質問や検討内容に基づいたDevinセッションに受け渡すためのプロンプトを自動生成できます。これにより、設計した内容をDevinに正確かつ効率的に受け渡すことができ、手動で長いプロンプトを作成する手間を省けます。

ここで「プロンプトを作って」と入力してCmd+Enter

するとプロンプトが生成される

3. Knowledgeは細かく分割する

DevinにKnowledgeを共有したのに、意図した通りに動いてくれない、規約を守ってくれない・・・そんな時は利用されるタイミングごとに細かくKnowledgeを分割するのがおすすめです。

私たちのチームでは、以前はCLAUDE.mdや.clinerulesのように、1つのKnowledgeに知識を集約していました。しかし、その結果、ブランチの命名規約や実装規約などが守られないことが多々ありました。この課題を解決するために私たちがたどり着いたのが、利用されるタイミングごとにKnowledgeを細かく分割するという方法です。例えば、ブランチ命名規約Knowledge、実装規約Knowledgeのように分割してKnowledgeを作っています。

細かく分割するメリットは、Devinに「このKnowledgeを使うべきタイミング」を指示できることです。 Knowledgeの編集画面を見ると分かりますが、Devin uses this when...という欄があります。ここに使うタイミングを記載しておくことで、指示通りの行動を促しやすくなり、追加の指摘を減らすことができます。新規でKnowledgeを作成する際は、この欄が表示されずデフォルトで「when working in repo 〇〇」になります。特定のタイミングで利用するのであれば変更することをおすすめします。

Knowledge作成画面ではいつ使うかを編集できない。