Roo Code を試してみた感想
10時間くらいでマジックのデッキビルダー風のアプリを作った。 途中で飽きてやめたので雰囲気だけ。
repository: https://github.com/sekai013/magic-deckbuilder
戦略
なるべく自動Approve
逐一Approveを求めると、Roo Codeが意図と違うことをやり始める段階で止められる一方、手間も増える。
個人的にはなるべく自動Approveして.clineruleなどで内容をうまくコントロールするのが目指したいかなと思う。
devcontainerで作業
devcontainerはもうずっと使っているけど、こういうツールを使うなら特に使いたいと思う。
さすがにdevcontainer外でcommandを自動approveする勇気はない。
英語で指示
英語のほうが精度いいかなと思ってやってみたけど、細かいニュアンスを伝えるのが難しくて結果意図しない変更になることもあったかも。
次やるときは日本語で細かいプロンプトを書いてみる。
テスト（仕様）を書かせる
自分がRoo Codeを触る前のイメージとしては
- テストを人間が書く
- それを通るように実装を自動生成させる
という感じだったけど、生成速度があまりに早いので、すぐに
- Roo Codeに適当にドメイン知識と指示を与えてテストを書かせる
- 人間はそれを見て問題ないか判断し、問題あれば修正させる
- 問題なければ実装を自動生成させる
という感じになった。
この流れはすごく良いと思ったけど、実装するときにテストを変更したり、テストが落ちてるのにタスク完了することがよくあったので徹底させたい。
ちょっと油断してimplement <feature>とか指示するとテストを書かないので.clineruleにTDDに従えと書いてみたけどあまり効果はなかった。
もう少し細かく書かないといけなかった気はする。
コスト
バックエンドはClaude3.7で、今回のコードを書くのにかかったのがだいたい90ドル。
まあまあ高いけど差分をresetしてやり直しが何回もあったのでかなり無駄はありそうで、散々書いた通りこの辺は.clineruleとプロンプトにかかっている。
他にコストを抑えられそうなところとしては
- 適当にファイルを分割して読み込み/書き込みコストを抑える
- 人間がやるより効率がよさそうなことをやってもらう
- ファイルの移動とかクラスのリネームとかしょうもないことは頼まず人間がやる
- いちいちdevコマンドを実行しようとするのを止める（hot reloadで起動しておく）
あたりは思い浮かんだ。
全体の感想
- 時代は変わっている
- コスト的にも効率的にももっとうまく使いたい
- （Roo Codeとの組み合わせのせいかもしれないが）Claude3.7でもそこまで賢くはない
- UIを書かせるのにはめちゃくちゃ良い