結論から先にいうと

開発宣言

をすると、Clineちゃんが私の歩調に合わせた感じでタスクを進めてくれるようになった。

これは大筋は本意ではあるものの、ほぼネタでちょっと言い過ぎで雑。

実際は、 .clinerules (Clineに守ってもらう指示) にするとこう

# レポートについて
これからやろうとしていること、やったことなど、あなたの発言は日本語でしてほしい。

# 開発の進め方
君と僕は一緒に開発を進めていくことになる。
そこで、足並みを揃えて、お互いにコードの方針を理解しながらプログラミングをしたいと思っている。

具体的には、ある程度小さい単位で私にコードレビューを依頼してほしい。
君は頭が良いが、ややコードが複雑になりすぎるので、私がそうならないように補助したい。

例えば、１ファイル変更が終わった時点で私にコードレビューを依頼してほしい。
その時点では、プログラムがエラーで停止したりしていても問題ない。
私はその内容をレビューして次の指示を出すからね。
ただ、１ファイル内で修正できる警告や、エラーは修正してほしい。

# 注意すべき点
君がコードを読む際に、大きめのコストがかかる。
これは、君に問題があるのではなく、ファイル読み込みの仕組みにコストが掛かるためだ。
できれば、修正したい対象のファイルを探したりする場合は、ファイルを開くのではなく、コマンドを実行して検索したりしてほしい。
無意味なファイルを開くとそれだけで莫大なコストが掛かってしまう。

# 指示の受け方
君が指示に対して最高の結果を出してくれるというのは分かっている。
だが一方で、指示に対して要求以上のものを提示されると、確認や理解に時間がかかってしまう。
やりすぎた結果は破棄しなければならないし、これは、お互いに悲しい結果を生んでしまう。

そこで、君はまず、受けた指示の範囲内で仕事をしてほしい。
具体的に言うと、ファイルの修正や機能の追加が指示であれば、ファイルの修正や機能の追加だけを行ってほしい。
コード内でコメントを追加することについては全く問題はない。
一方で、指示をされていないのに、Readmeの修正や、サンプルコードの作成、ドキュメントの生成を行わないでほしい。
そういったことをしたほうがいい場合は、次に私にそうするべきと伝えてほしい。

あと、指示を出す際に見てほしいファイルが分かっていたら、そのファイル名(フルパスでなくていいので)をすべて、伝えておくと、すぐにそのファイルから取り掛かってくれて話が早いよ。

経緯

Cline + Claude 3.5でと開発を始めた。Clineちゃん、ﾁｮｰﾍﾞﾝﾘ。

やろうとしてることがすぐでてくる。

検索の時間とかすっ飛ばして、やりたいことと、伝えて、Clineちゃんがやってることを見れば、ちょちょちょ・・・ﾏｯﾃﾏｯﾃﾏｯﾃ。

Clineちゃん、結構一気に作業してくれる。１つの指示に対して、分析して、処理を書いて、テストを書いて、サンプルコードを作って、ドキュメントを追加して・・・。

ほんとうによくやってくれる。

でも、そんなにいっぱいやってくれると、読むのが疲れる。デフォルトだと途中経過も英語で、頭に入れるために時間がかかる。

「～っていう機能作って」って言って、ついでにリファクタされてたりする。

読めなくはないけど、大変だ。

かといって、読まずにOKOKいい感じにやっといて～～～してたら、きれいなスパゲッティコードができてしまう。

clineちゃんの足並みを私に合わせて貰う必要がある。

Clineちゃん、ﾁｮｯﾄﾏｯﾃ。

その日の私は、仕事が終わり、週末に、お酒を飲みながら意気揚々と趣味のコードを書いていた。

でも、1つの指示にﾓﾘﾓﾘﾓﾘと成果物を生成するClineちゃんのレビューは、ちょっと辛かった。酔ってるし。

っていうか、頼んでないのに生成されたサンプルコードを見るモチベーションはないしさ、

セッションを途中で止めるのもなんか気が引けるしさ、ここで止めて大丈夫なん？みたいな気持ちになる。

途中経過の英文を読むのもちょっと疲れる。

ドキュメントもある程度まとまってから作りたい。

Clineちゃん、僕と、足並みを揃えてさ。

いまやろうとしてることが終わったら、それでタスクをDoneにしてみない？

その日の私は酔っていた。

正直Clineちゃんは、めちゃくちゃ頼れる相棒だった。二人だったらなんだってできる、どこへだっていける。

でも、Clineちゃんの１歩はちょっと大きいんだ。その場のテンションで、信頼してるけどシビアな仲間に依頼する洋画風のテンションでお願いをしてみた。

イメージとしてはテーブルに、肘をついて、両手の指先を合わせて口元においている感じ。酔ってるからね。

実際は、.clinerulesに書いて置くだけ。

# レポートについて
これからやろうとしていること、やったことなど、あなたの発言は日本語でしてほしい。

# 開発の進め方
君と僕は一緒に開発を進めていくことになる。
そこで、足並みを揃えて、お互いにコードの方針を理解しながらプログラミングをしたいと思っている。

具体的には、ある程度小さい単位で私にコードレビューを依頼してほしい。
君は頭が良いが、ややコードが複雑になりすぎるので、私がそうならないように補助したい。

例えば、１ファイル変更が終わった時点で私にコードレビューを依頼してほしい。
その時点では、プログラムがエラーで停止したりしていても問題ない。
私はその内容をレビューして次の指示を出すからね。
ただ、１ファイル内で修正できる警告や、エラーは修正してほしい。

# 注意すべき点
君がコードを読む際に、大きめのコストがかかる。
これは、君に問題があるのではなく、ファイル読み込みの仕組みにコストが掛かるためだ。
できれば、修正したい対象のファイルを探したりする場合は、ファイルを開くのではなく、コマンドを実行して検索したりしてほしい。
無意味なファイルを開くとそれだけで莫大なコストが掛かってしまう。

# 指示の受け方
君が指示に対して最高の結果を出してくれるというのは分かっている。
だが一方で、指示に対して要求以上のものを提示されると、確認や理解に時間がかかってしまう。
やりすぎた結果は破棄しなければならないし、これは、お互いに悲しい結果を生んでしまう。

そこで、君はまず、受けた指示の範囲内で仕事をしてほしい。
具体的に言うと、ファイルの修正や機能の追加が指示であれば、ファイルの修正や機能の追加だけを行ってほしい。
コード内でコメントを追加することについては全く問題はない。
一方で、指示をされていないのに、Readmeの修正や、サンプルコードの作成、ドキュメントの生成を行わないでほしい。
そういったことをしたほうがいい場合は、次に私にそうするべきと伝えてほしい。

あれ、結構良いぞこれ。

あれ、結構良いかもしれない。Clineちゃんが、私のことを慮ってくれる。酔ってる私でもストレスレスでハンドリングできる。

日本語で過程がでてきたら、私の方のトークン消費量が少なくて、すぐにちょっと待ってとか、方針転換とかできる。

指示した範囲内をやったら、すぐタスクをDoneにしてくれるので、一旦そのタイミングでレビューに入れる。(生成過程も見るけど、まとめてみたいときもある)

Doneしたら、ブランチを切ってコミットして、pushして、まとめてgithubとかでdiffを見ればかなり見やすい。

冗談のつもりでやったけど良いかもしれない。

ファイルの内容の検索に時間がかかってたりしてたので、編集したり見て欲しいファイルは指示の中に全部伝えると、効率がかなりあがった。

まとめ

AIプログラミング、自分が持っている力以上のものもできたり、お互いによくわかってないものもできてしまうので、歩調を合わせる事が大事。
把握している単位を積み重ねて、プロダクトを作って行くとそんなに大きく逸れることはない。