同じアドバイスを投稿している人を見たことがあるし、確かに効果があると思うけど、そろそろこの一般的な戦略を吸収して、製品の一部として統合してもいいんじゃないかなって思う。

ちょっと真面目な質問なんだけど、「計画を小さなステップで実行するように頼む」ってどういう意味？ 一つの選択肢は「この変更を小さなステップで実装してください」とほぼそのまま書くこと。もう一つは、ステップを考えてから「小さなステップでこれを解決してください。最初のステップは、私が興味のある最初の新しいXML要素を処理するためにパーサーにコードを追加することです。この変更Xを行ってください。YとZについては後でやります」と頼むこと。ほかにもいろいろな選択肢があると思うよ。

最近、いくつかの個人プロジェクトで「バイブコーディング」をやってるんだけど、テスト駆動開発がバイブコーディングとすごく相性がいいことに気づいたよ。君が言った通り、問題を小さくてテスト可能な部分に分けて、AIに最初にユニットテストを書かせてから、実際のコードを実装するって感じ。

追加したいことがあるんだけど、開発ドキュメントを何らかの形で保持して、アプリケーションやそのコンポーネントのパターンやアーキテクチャを詳しく説明することが大事だと思う。これをやるだけで信じられないほどの改善が見られたし、正確なプロンプトを使ってClaudeにフルサービスを実装させることができたよ、テストも含めてね。もちろん、後で手動で修正が必要だけど、機能の作業を始める前にClaudeに開発ドキュメントを確認させることで、ほとんどの幻覚を防げる（それと、外部ドキュメント用にContext7 MCPを使うように言うことも）。少なくとも私の経験ではね。これの欠点は、コンテキストウィンドウの30%がドキュメントで埋まっちゃうことだけど、まあ、APIメソッドの幻覚を見たり、再実装しちゃいけないことを完全に忘れたりすることはないから、いいんじゃないかな。私の意見だけど。

大きくて複雑なタスクに対して効果的な戦略は、「今はコードを書かないで。問題の各ステップをもっと詳しく説明するから」と伝えることだと思う。大まかな流れは、1) この入力を読む 2) これらの候補を生成する 3) 候補にスコアを付けるためにヒューリスティックを適用する 4) 候補を優先順位付けしてランク付けする 5) 出力を反映するデータ構造を考える 6) このスキーマでDBに出力を書き戻す、って感じ。そうすると、Claudeはコード内にTODOリストを書いてくれたり（/initを実行していればclaude.mdにも）、各ステージの詳細を尋ねてくれる。実際、これを1時間やったこともあって、「今は止めなきゃ。完成したステージのコードを生成して、コメントを書いておいて、次回はそこから再開できるようにして」とClaudeに言ったら、次回はほとんど手間なく再開できたよ。

その時点で、自分でコードを書けばいいんじゃない？

俺はこういうことを全部やってる気がするけど、大抵は使えないコードになっちゃう。使えるコードができたとしても、結局は手を加えないといけないことが多い。たまにうまくいくこともあって、その時は本当にクールなんだけど、俺の経験では効率が上がる感じはしないな。

いくつかのLLMやエージェントを使ってるけど、まだ有用な出力を得るのに苦労してる。無駄なことをさせないためには、自分で書くよりもプロンプトにエネルギーを使わなきゃいけないんだ。プロンプトの細かいところや言い回し、意図しない関連性に神経質になっちゃう。専門家の交換みたいなものに似すぎると、クソみたいなコードが出てくるんじゃないかって心配になる。ほんとに欲しいのは、LLMのプロンプト用のフロントエンドフレームワークみたいなもので、プロンプトの構造やコード内の何かを見つけるためのベストプラクティス、あるいは新機能の設計やテストを書くのに関する無駄を減らしてくれるものだよ。

個人的には、エージェントが成功基準を使うように強制するのをもっと簡単にするのが、最も大きな改善だと思う。今は、例えばClaude Codeにテストスイートが通るまで修正し続けるように促すのが簡単じゃない。いつも決まった量の作業をして、ほぼ終わったと感じたら止まっちゃうから、テストを通すように本当に言ってるって何度も言わなきゃいけないんだよね。

それを忘れないでね。これは補助金価格での話だから。