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

ちょっと真面目な質問なんだけど、「計画を小さなステップで実行するように頼む」ってどういう意味？ 一つの選択肢は「この変更を小さなステップで実装してください」とほぼそのまま書くこと。もう一つは、ステップを考えてから「小さなステップでこれを解決してください。最初のステップは、私が興味のある最初の新しい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にテストスイートが通るまで修正し続けるように促すのが簡単じゃない。いつも決まった量の作業をして、ほぼ終わったと感じたら止まっちゃうから、テストを通すように本当に言ってるって何度も言わなきゃいけないんだよね。

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

今は月に20ドルのクレジット（IntelliJのプロAIサブスクリプションを通じたgpt-5の思考）を使えないから、1000ドルって数字には驚いてる。Claudeってそんなに高いの？（ググったら、実際そうみたい）。とはいえ、ある程度のAIへの支出は新しい現実だよね。職場はインターネット代払ってるよね？多分、すごく高い法人向けの速い接続だよね？それに加えて、AIのサブスクリプション代も払わなきゃいけないってことだよ。これが今の現実だね。

今後数年でビジネスがどう進化するか見るのは面白そうだね。確実に言えるのは、君（社員）は測定されるってこと。今後、開発者は何で測定されるのか気になるな。AIにもっとお金を使ったら、解雇や昇進のリスクが高くなるのかな？開発者として、君自身が称賛されるべきだってどう証明するの？

ハードウェア企業は、開発者の給与よりも高い個別のEDAツールのライセンスを日常的に取得してるよ。生産性が測定可能な程度で向上するなら、$1k/年なんて何でもないよ。

実際にAIに与えられた具体的なタスクの例とその結果を示すと、幻想が壊れて、みんながその過剰な期待を疑う機会ができちゃうよね。それは避けたいから、実際の例ゼロでClaude Codeがどれだけすごいかっていう投稿が続くんだろうね。

なんか、営業っぽくなっちゃって、「教訓」じゃなくて「これらの学び」とか書いちゃうエンジニアっているよね。技術的なオーディエンスを対象にした記事なのにさ。面白いのは、俺が開発者として成長するにつれて、彼の進化を逆に辿ってる感じ。経験が少なかった頃はGoogleに頼ってたけど、今はドキュメントを読むだけで済むようになった。

そうだね、LLMはメンテナブルなアーキテクチャを計画するのが苦手だよ。コードが進化してもリファクタリングしないし、コンテキストの制限でそれができないんだと思う。

同意だね。このAnthropicの記事は、プロトタイピングに焦点を当てていて、現実的な見方だと思うよ。

うん、$1k-1.5kは異常に高い気がする。$200/月の20倍プランは、めちゃくちゃ使える量をカバーしてるし、レート制限も5時間ごとにリセットされるからね。毎日何度もそのレート制限を超えるほど必要になるなんて、ちょっと想像できないよ… もしそうなら、トークンごとの支払いに切り替えた方が、$1k以上かかりそうだね。