ご安心ください、この記事は 100% 手打ちです 
この記事の内容は筆者自身の開発スタイルに基づくものです。効果・効能には個人差があります。スキルは各自が自分のためにカスタマイズすることを推奨します!
しばらく前にコーディングエージェントに何かを実装させる前に grill-me スキルで実装内容の方針を詰める試みを始めたんだけど、不満があったので自分のためのスキルを作った話をするよ。
Grill-me はそれなりに有名なスキルなので、それがどんなものなのかの説明は省略するね。自分は本家 Matt Pocock によるスキル1をちょっと拡張したものを使ってたよ。
Grill-me のツラかったところ
とにかくこいつは時間がかかるんよ。一回 grill-me を始めてから全ての質問を消化するまで一時間以上かかることも多かった。それはただ質問が多いことだけが原因ではなくてね。一回の質問ごとに、自分が質問を読んで把握するのに一分以上、場合によってはさらにそこからソースコードやら資料やらを自分で調べる必要が出てきて数分消費、そしてあーでもないこーでもないと悩みながら回答を記入するのにまた数分以上 (特に、エージェントが提案した解をどれも採用しない場合) といった感じで、質問と回答の一往復だけでも 5 分とか 10 分とかかかることが割とあった。そして自分が回答を返した後にエージェントが次の質問を検討し始めるんだけど、そこで 30 秒位以上待たされると自分は浮気して Slack の未読メッセージを確認し始めたり別の並行作業を再開しちゃったりなんかして、その間にエージェントが次の質問をよこしてきてるのにすぐ戻れず何十分も放置しちゃってるみたいなこともあった。おいおい。
Grill-me はとにかくいろいろ聞いてくれるんだけど、「この部分はどうしますか? 推奨は○○です。なぜならそれがコーディングルールだからです」みたいな質問も多くて、いちいち回答しなきゃいけないのがウザかった。それ位は分かってくれよん!
とまあそんな悩みがあるって話を Claude に打ち明けたところ、Claude は新しいスキルを作ってくれた。それが sear-and-build2。
我が sear-and-build スキルはこんな感じ
Sear-and-build スキルは四つの段階に分かれてて、設計検討だけではなくエージェントが実装をするところまで入ってる。
第一段階では grill-me みたいにエージェントが必要な情報を調べたり検討したりして、質問リストを準備する。ただし、エージェントが自分で判断できる質問はもうこの時点で結論を出しておく。エージェントが自分で判断する条件は二つあって、
- 規格・仕様書・コーディングルール等から自動的に結論が導けるもの
- 間違っててもやり直しが簡単な、細かい内部設計の判断
前者はいちいち聞かずに自分でうまくやってほしいやつ。後者は聞いてほしい気もするけど実装開始前に細かいこと聞かれてもむしろ俺だってよくわかんないよってなるやつ。
質問が出揃ったら第二段階。Grill-me と同じくエージェントが人間に質問をする。でも質問の数は既に前の段階で絞られてるので、精々 2 問程度で済むことが多い。質問が一つもないこともあるよ (やったぜ!)。
本家の grill-me では残りの質問数が分からなくて悶々とすることが多かったので、質問前に「あと何問の見込みです」みたいに予告するルールも追加した。
質問がなくなったら第三段階に移行。エージェントはさっき質問せずに自分で決断した事柄を一覧で報告し、その後すぐ実装を開始する。エージェントが裏で実装してる間に、俺はエージェントの決断結果をレビューする。決断結果の一覧は異論があるかもしれない順に並んでるから、エージェントがこっちの意図と異なる決断をしてた場合にいち早く気付いて止められる。実際に止めて訂正しなきゃいけないケースなんて 10 回に 1 回とかの頻度でしかなくて、大抵はそのまま実装が進んでいく。なので、決断をレビューしてから実装を始めさせるよりも、決断が合ってる前提でさっさと実装させて時間を稼ぐ方が効率的なのだ。
この決断結果の項目にはそれぞれ「選ばなかった最有力の対案」が併記されるので、各項目をどれだけ真剣にレビューしなきゃいけないかがすぐにつかめる。問題外の対案は見ただけで直観的に却下できるから、どうでもいいことに「この判断の意図は何だ? もしかして変なところに罠があるんでは???」などと深入りして時間を無駄にすることはない。
第四段階。実装が完了したらエージェントはもう一度先ほどの自分で決断したことの一覧を出す。ただし今回はそれぞれの決断結果が成果物のどの部分に反映されてるのかをファイル名 & 行番号と共に示す。これで俺は「実際のコードを見て確かめたいな～」と思ったときにすぐそこに飛んでいける。数百行とか数千行とかのコード差分の中からどこに注目すべきか自分でひーこら探し出す苦労をしなくて済むわけ。
俺がやりたかったのは決断をレビューすることだったんだなぁ
振り返ってみると、この新しいスキルでは「エージェントが決断し、人間がレビューする」ことが作業の中心で、grill-me の中核だった一問一答は前座みたいな感じに成り下がってる。そしてそれこそが正に自分のやりたかったことなんだと感じる。
エージェントが書いたコードを一切レビューしないことはバイブコーディングとか呼ばれるけど、それだと設計が人間の意図と同じ方向を向いてるかどうかわからないし、設計にどんな制約や改良の余地があるのかもわからない。そんなことでは開発者は今後の開発計画の妥当性や実現可能性を正しく予測できないよね。それでは困るから、エージェントにコーディングを任せたとしても、設計上の要点は把握しておかなきゃならない。
GitHub Copilot に付いてるプルリクエストの差分の要約機能とかだと、「何が実装されたか」とそこから推論される「その機能が何の役に立つのか」はわかるけど、「なぜそんな風に設計したか」はほとんど見えてこない。設計意図は基本的に設計した人の頭の中 (エージェントの場合、コンテクスト) にしかなくて、コードがコミットされた段階でほとんど消え去る。でもそれが残ってるうちに sear-and-build で明文化すれば認識を共有できる。エージェントの判断に人間が《付いていく》ことができる。
今後の研究テーマ?
さっきまで「sear-and-build スキル、完璧すぎてもう改良の余地なくね? 笑」みたいな気分だったけど、この記事を書いてるうちにアイディアが浮かんできたよ。これがうまくいくのかはまだ全然わからないけど……。
- プルリクエストを作るときにも決断結果リストをレビューアーに提示することでレビューアーはより快適にレビュー作業ができる?
- 人間が手動で設計・コーディングした時にも同様の決断リストを出すことは役に立つ? どうやったら人間にそれが作れる?
- Sear-and-build が吐く決断結果の事柄を、設計書やコード内コメントとして残せば設計意図が消えずに済むのでは?
- どんな設計上の決断をどこにどう記録すればいいかをエージェントが正しく判断する方法は?
- その記録方法は人間がコーディングしてた頃の流儀とはどう異なる?