私たちは Sherlock という専用のバグ修正エージェントを構築しました。Slack からバグを受け取り、Sharkly.ai の構造化されたタスクとして処理します。
最近の15日間で、Sherlock は会社全体のタスクの13%を完了しました。直近で割り当てられた100件のタスクのうち、90件が正常に完了しました。
重要だったのは、単にモデルを改善することではなく、エージェントの実行プロセスを制御することでした。
1.ロールプロンプトではなく、10段階のステートマシン
「あなたは優秀なエンジニアです」というプロンプトだけに依存せず、Sherlock は固定された10段階のステージに従います。ステージを飛ばすことはできず、診断段階では製品コードを変更できません。
2.明示的な2つの承認トークン
最初のワークフローには7つの承認ポイントがあり、エンジニアがボトルネックになりました。そのため、次の2つに減らしました。
[START DEVELOPMENT] — コード変更を許可
[SUBMIT FOR TESTING] — push/merge を許可
「Looks good」や「continue」は承認として扱いません。
3.各ステージで成果物を必須にする
必要なファイルは diagnosis.md、idea.md、plan.md、review-report.md です。「diagnosis complete」というチャットメッセージだけでは完了と認めません。
4.チャット履歴ではなく、state.json から復旧
すべての状態を state.json に保存します。セッションが中断された場合、次の実行はディスクから状態を読み込みます。会話履歴から進捗を再構築した際には、エージェントが進捗を誤って生成する問題がありました。
5.最大6回のセルフレビュー
実装後、Sherlock は独立したレビュー担当者のように diff を確認します。重大な問題があれば修正して再レビューしますが、最大6回で停止し、人間にエスカレーションします。
6.UI変更の前後スクリーンショット
UI変更では、スクリーンショットをファイルパスだけで渡すのではなく、会話内に直接表示します。
実際の例
「リストがスクロールできない」というバグは、Slack → 構造化タスク → 14分間の自律診断 → 人間による3つの判断 → 承認 → 37分間の実装 → PR、プレビューURL、スクリーンショットという流れで処理されました。
人間による判断は合計2回でした。
なお、90/100という結果は Sherlock に割り当てられたタスクに限定されます。すべてのバグに対する成功率ではありません。また、再オープン率のデータはまだ公開していません。
詳しい記事：
https://dev.to/yukioikeda/how-to-build-an-ai-agent-that-fixes-bugs-reliably-practice-in-sharkly-o63