Claude Codeで劇的成果！開発効率が爆上がりするその方法とは？
引用元：https://news.ycombinator.com/item?id=44836879
Claudeで初めての成功！詳細な12ステップの仕様書を書いたら、Claudeがサクッとコードを生成してくれて、6〜10時間も節約できたんだ。やっぱ、問題の正確な理解と実装方法の明確化が超重要。これなら中堅・シニア開発者は全然安泰だね。AIが整理されたコードを自動生成してくれるのはホントにすごいよ。
AIが生成したコードのAIによるドキュメントって、何の意味があるの？AIが再分析する時にコンテキストサイズ増えるだけだし、人間が読むわけじゃないでしょ。AIに聞けば良いんだから。正直、ただの負担でしかないと思うな。
誰か、仕様書の実例をシェアしてくれないかな？アマチュアプログラマーとしてClaude Codeを試してるんだけど、どんな情報がどれくらい詳細に書かれてると役立つのか、めっちゃ知りたいんだ。すごく助かるんだけど！
俺はそんなにガチな仕様書は書かないよ。Claudeに、自分がやるみたいに少しずつコードを書かせるんだ。次のステップを指示して、すぐ変更を承認、コミット後にdiffを確認。もし変なことしてたら、直してって頼む。既存コードや使いたい関数のリファレンスも渡すし。これ、タイピングも時間も超少なくて、良い結果が出てるんだよね。
俺は複数のシステムプロンプトを使ってるよ。まずSocratic Coderでアイデアを対話して練る。次にBrainstorm Specificationで会話を仕様に変える。Brainstorm Critiqueで仕様の欠点を見つけて、最後に修正版を作るんだ。これでLLMのコード品質がかなり上がったし、自分で書くコードも良くなった。アイデアの取捨選択にも役立つよ。
[1]: https://github.com/jamesponddotco/llm-prompts/blob/trunk/dat…
[2]: https://github.com/jamesponddotco/llm-prompts/blob/trunk/dat…
[3]: https://github.com/jamesponddotco/llm-prompts/blob/trunk/dat…
Naurの”Programming as Theory Building”を読むべきだよ。LLMが間違った理論をでっち上げないためにも、問題とモデルの理論は自分で理解して作る必要があるんだ。これ、超大事だから！
[1] https://gwern.net/doc/cs/algorithm/1985-naur.pdf
「中堅・シニア開発者は安泰」って、自己満足じゃない？正直、そんな長くは続かない気がするな。AIの開発はまだ超初期段階だよ。今はシニアレベルのデザインスキルやプログラミング知識が必要だけど、それがずっと続くとは限らないからね。
数年後に、コーディング経験ない奴がAIに「ヨーロッパが舞台のGTA 6クローン作って」って言ったら、AIが完璧に動くコードを爆速で作ると思う？LLMは学習データに引っ張られて複雑化したり、賢い解決策を見つけられなかったり、変数名とか hallucinationしまくったりするんだ。AIに仕事奪われるより、CEO/マネジメントが「Claude買えば開発者が10倍速くなる！」ってマーケティングに騙される方が怖いよ。
正直、Claudeを完全に無視したとしても、自分で良い仕様書を書けるようになるってのは、それ自体が価値のある努力だと思うよ。
完全同意だよ。これは優れた開発者の核となるスキルだね。面白いのは、以前ならこのプロセスを始めてすぐにコーディングに飛びついちゃってたこと。今はエージェントを使ってるって分かってるから、もっと詳しく書くほど良い結果が出るんだ。
そうだけど、ウォーターフォール計画の教訓は忘れちゃいけないね。全部は予測できないから、実装計画の詳細は”ゴールドロックスゾーン”くらいで、詳細すぎず、でもちゃんとしたレベルで。実装とテストの段階ごとに、現状に合わせて仕様や計画を調整できるのが理想だよ。
セッションやコンテキストがよく途切れるんだよ（例えばClaudeがクラッシュしたり、ネットが落ちたり、PCが再起動したり）。Claudeは、既存コードから意図や構造を推測しようとするより、明確なドキュメントから状況を把握できると一番うまくいくね。あと、人間もコードのドキュメントはよく読むよ。Claudeが詰まったり、期待通りに動かない時でも、人間なら論理的に解決して障害を乗り越えられるからね。
これは「フルオートパイロットが可能でも、パイロットが手動で離着陸するのはなぜ？」って聞くのに似てるね。オートパイロットはパイロットを助けるもので、置き換えるものじゃないからさ。現実世界では色々な問題が起こりうる。毎日練習するスキルを持つことが、良いパイロットであり続けるために重要なんだ。同じように、毎日コードを書いてスキルを磨くのは良いことだね。1) クラウドLLMが停止しても、マネージャーは多分お前が仕事できるって思ってるはず。OpenAIがダウンしたからって帰るわけじゃないだろ。エンジニアとしての生産性はクラウドが動くかどうかに依存すべきじゃない。2) プロジェクトの特定部分、重要な関数やクラス、モジュールは手動で書きたい時もある。良い自動生成ドキュメントは、IntelliJ、WebStormみたいな従来のIDEを使うときにも役に立つよ。3) コードレビュー。お前のチームはSDLCの一部としてコードレビューしてるんだろ？ドキュメンテーションはコードレビューの時にも役立つよ。
まさにこれだね。俺からすると、みんなClaudeの使い方を考えすぎてる気がするよ。
＞エンジニアの生産性はクラウドが動くかどうかに依存すべきじゃない。
笑、どこで働いてるんだ？これは業界全体では明らかに違うだろ。GitHubやAWSやWiFi＼ISPがダウンしたら、生産性は大幅に落ちるよ。多くのSaaS企業はローカル開発しないから、クラウドが広く動いてることに依存してる。「すべき」が何年も業界の現実じゃないんだよ。
AIとして売り出されてるけど、実際はかなり限定的だって気づくのに時間がかかるんだ。俺の意見じゃ、大した「知性」は働いてないね。要求を翻訳して、求めたものの近似値を出してくれるのはすごいけど、本当に「考えてる」わけじゃないんだ。彼らが「考えてる」って宣伝する時でも、単に与えられたヒント（要求）から頭の中で一番近い「数字」を何回か繰り返してるだけだと思う。誰かがLLMは「単語計算機」だって言ってるのを見たけど、それがかなり良い表現だと感じるね。
その時点で自分でコード書いた方が早くない？
このプロセスでどんなメリットがあるの？
あなたのフローだとレビューと修正のステップが複数あって、さらに摩擦が増えるよね。
でも、親コメントが説明してる利点なら分かるよ。
なんで差分がAIダイアログの一部じゃないのか理解できないね。
この手のものがコードを実行したと主張して、幻覚的な出力を示し、その幻覚に基づいて間違った理論を展開するのを、もう何回見たことか。
GTAの例は良くないね。ゲーム開発の大部分はコーディングじゃないから。
AIを使った方が速い時もあるし、そうじゃない時もあるんだよね。俺は「このJSON用のGo structsと、使ってるNoSQL DBから保存・ロードする関数2つ作って」みたいにプロンプトしてる。これで接着剤コードを書くのがめっちゃ速くなる。
でも、ビジネスロジックは自分で書くよ。AIが書いたものをレビューするより、自分で書く方が速いからね。
ウォーターフォールの欠点は、スペックが細かすぎることじゃなかったよ。むしろ、理想的なソフトウェア開発は、しっかりした、できれば形式的なスペックに従ったウォーターフォールなんだ。
Agileが解決しようとした欠点は「柔軟性のなさ」で、これはコーディングエージェントによってかなり改善される問題だね。
CLIのコーディングツールがそんなことするの見たことないな。あれらはツールとの連携を前提に作られてるし。
もしチャットインターフェースだけで使ってるなら、そりゃ一貫性のない挙動になる可能性はあるよね。
約束するけど、トークンコンテキストの腐敗は、自然言語での説明を追加する利点よりもはるかにひどいぞ。
「このJSON用のGo structsと、使ってるNoSQL DBから保存・ロードする関数2つ作って」って、それってLLM登場前からあったツールでできるじゃん。しかもローカルで速くて、何より無料だったし。
なんでみんな、もうあるツールやワークフローをわざわざ作り直そうとするんだろうね？
もしかして、「これAI使ってるんだぜ！」って言いたいだけなのかな？
VS Codeだと、貢献ごとに差分を見せてくれるよ。
書くのは一回、見るのは100回だよね。
俺はプロンプトで、行ごとのドキュメントは禁止してるけど、将来のデベロッパーやAIコーディングエージェントに役立つ関数／クラス／モジュールレベルのドキュメントは推奨してるよ。
人間の方が大体は優れてるけど、AIがコードのコンテキストを理解できず、同じことをする新しい関数を勝手に作っちゃうのを止めるには、時々手助けが必要なんだ。
AIで「GTA 6クローン」は無理でも、ベテランエンジニアがClaudeを使えば、ジュニア社員なしで大規模プロジェクトを進める可能性はあるよ。マネージャーはコードを書けないけど、経験豊富な人が主導すれば少人数での開発は可能だ。LLMが学習データに偏るという意見もあるけど、俺の経験では実用的なコードが書ける。完璧でなくても、多くのソフトはGoogleレベルの性能は不要だし、開発期間が短縮されるならビジネス上の価値は大きい。
公平に見て、LLMの「思考モード」をオンにすると、思考や推論してるのが見えるよ。例えば、「黄色にして」ってプロンプトすると、「ユーザーは何かを黄色にしたいけど、何かわからない。前はボタンを作ると言ってたから、ボタンのことだろうけど、確認すべきだな」って考えて、「ボタンを黄色にしたいんですか？」って返してくるんだ。
リポジトリだけじゃなくてファイルにもスターをつけられたらいいのにな
もっとコメントを表示（1）
Cursorでも同じspecを送れるんじゃない？なんか見落としてる？
正直、~/.claude/CLAUDE.mdは機能しないと思う。主観的で曖昧な指示はClaudeに影響しないし、人間じゃないからLOCごとに推論しない。Context rotも問題だね（https://news.ycombinator.com/item?id=44564248 ）。現状、単一ファイルから真のルールシステムは作れないよ。みんなもこの間違いは経験済み。全てのルールを重視するなら、サブエージェントが必要でコストも爆増するだろうね。
なんでエージェントに自動で定期的にルールを与えたり、再プロンプトできないのか、いつも不思議に思うね
コストが爆増するって話だけど、ワークフローが安定したら安いLLMを使えばコストは削減できるよ。ファインチューニングやプロンプト最適化、特別な蒸留技術とか、この分野はもう研究されてるんだ。
数ヶ月前から、安価なLLMと高価なLLMを組み合わせるシステムを考えてたんだ。実装したいと思いつつも、自分より多くのリソースを持つ誰かが先にやるだろうって気がしてる。今はバニラなCCの使い方で満足してるよ。
CLAUDE.mdには、どんなことを書くのがいいの？
CursorとCCの初期ユーザーとして経験から言えば、何も書かないね。CLAUDE.mdは使ってない。期待が”魔法の黒箱”から”気の利いたオートコンプリート”に変わったんだ。つまりCCは、小さなステップで特定の意図に対するオートコンプリートで、考えるのは僕の方。ただ、良いコンテキストを作る努力はしてるよ。
（このアドバイスは聞いちゃダメ。エージェントのMarkdownはコンテキストエンジニアリングにとって大切な要素だよ）
（Markdownは）いつも無視される。経験済みさ
「明確な仕様書が大事」って言うけど、僕の経験ではClaude Codeで全然ダメだったよ。むしろCLAUDE.mdなしで適当にやった方がはるかに良い結果が出たんだ。Claudeで100件以上プロジェクトやったけど、フック以外で効果的なワークフローは見つからないな。みんな「こうすれば良い」って言うけど、結果はイマイチなんだよね。
経験談ありがとう。やっぱりね。LLMに「これしろ」「あれするな」って指示するのは変だよね。まるで人間相手みたいに。ルールセットがあるわけじゃなくて、全部コンテキストなんだから。指示がうまくいくのは偶然だよ。「パターンXでテスト書け」は訓練データにあるだろうけど、「Don’t Repeat Yourself」とか「コードベースを読め」は効果薄いだろうね。
エージェントなしでコード書くときは、UIスケッチやロジックフロー図、ビジネスルール箇条書きが一番役立つよ。コーディングは禅みたいな感じでサクサク進むんだ。エラーが出たら、それは知らないことがあるサインだから、止まって学ぶべきだね。調整フェーズでは、素早いフィードバックが超重要。エージェントはまだ必要ないって感じかな。
Claude Codeを毎日1ヶ月使ってるけど、CursorやQよりずっと良いね。記事のヒントも役立つよ。僕のやり方は、まずClaudeとウェブコンソールでアイデア出しして、それをCLAUDE.mdにまとめる。次にClaude CodeでCLAUDE.mdを読ませてプロジェクト開始。ClaudeにCLAUDE.mdを更新させて進捗を記録させるんだ。セッション終わりには要約させて、Claudeの長期記憶として使うと良いよ。Claudeは先走る傾向があるから、小さく刻んで進めるのがおすすめ。
$20のサブスクはCursorと同じくらいお得なの？毎日使うには、もっとお金がかかるのかな？
Cursorは分からないけど、$20プランだと毎日2～3時間以上使うのは厳しいね。$100プランはかなり良い感じだけど、それでも毎日長時間使うとレート制限に引っかかるよ（特にOpusは30分で使い切ることも）。
Claude Codeはペアプログラマーと組んでるみたい。CursorはIDEのすごく洗練された拡張って感じかな。どっちも良いツールで、$20/月でも十分価値あるよ。Anthropicは7日間の無料トライアルやってるはずだから、試してみる価値はあるよ。
Claude CodeはIDEと別に開いて、IDEでファイル構造とか見てるの？僕はCursorしか使ってなくて、IDEに統合されてるのがすごく気に入ってるんだ。差分をすぐ確認したり、コードベースを自由に移動できるのが本当に便利だね。
同意だね。ちなみに、Claude Codeには公式のVS Code拡張機能があるんだけど、それを使えばだいたい同じことができるよ。
いや、Claudeを本気で使うなら月額200ドルのプランが必要だよ。全部試したけど、安いプランだとOpusのトークンがすぐなくなっちゃうんだよね。
俺は逆の経験だな（Sonnetだけど）－制限使い切るには、Claudeに無駄に長いツールコールをさせなきゃいけないくらいだよ。5時間のリセットまでトークンが減らないんだ。Opusを使ってもパフォーマンスに十分な違いを感じないし、正当化できないね。
今週、月額100ドルのプランでOpusが2～3時間の利用で枯渇しちゃったよ。そんなにヘビーに使ったわけでもないのにね。
みんな、本来なら時間かける価値ないプロジェクトを始めちゃって、高優先度のタスクでClaude Codeを使うのを避けてる？古い、大規模でごちゃごちゃしたプロジェクトの機能でClaude Codeを使って成功した人はいる？
うんうん、まさにそれ！新しいプロジェクトでは自由に使えるけど、一度動き出したら慎重になるべきだね。うちは10年前のプロダクションリポジトリで毎日Claude Codeを使ってるけど、成功してるよ。
全くもってそう！Claude Codeを使い始めたばかりだけど、思いついてたけど時間なかった機能を小規模プロジェクトに追加したり、既存アプリの新機能のプロトタイプをGolangで1時間で作れたよ！開発がめちゃくちゃはかどって、まさに病みつき。汚いアーキテクチャのリファクタリングでも役立ったし、Claudeとペアプロするのに慣れそう。
まさに俺の経験と一緒だよ。いくつかプロトタイプができちゃって、それを仕上げるのに結局時間がかかるんだよね。優先度の高いタスクが早く進むどころか、かえって遅れちゃってるよ。
プロジェクトレベルで簡潔なCLAUDE.mdファイルを作るのが超おすすめだよ。詳細はサブフォルダに任せて、トップレベルをマップとして使うんだ。計画時にClaudeが適切なコンテキストを見つけて実装計画を立ててくれる。各フェーズの終わりに、Claudeに計画を更新させて次のフェーズに進むんだ。こうするとコンテキストが伝播して、新しいフェーズでクリアに始められるよ。
Claude Codeは普段から使ってて同僚にも紹介してるんだ。ここでは最高のコーディングエージェントって意見が多いけど、俺はこれしか使ってないから、CursorやCline、GitHub Copilot、Gemini CLIとかと比べて何がいいのか聞かれると、たまに説明に困るんだよね。Claude Codeのパワーユーザーたち、他のエージェントより優れてる点って何だと思う？
OpusとSonnetモデルは、コーディングやツール利用、長文コンテキストでの問題解決能力が根本的に優れてるって話が多いね。モデルの訓練方法に秘密のソースがあるみたいで、Darioもそれが会社の秘匿情報だって言ってた。この能力を測る良い評価ベンチマークはまだないけど、SWE Benchで似たスコアでも、ClaudeはGPT 5よりコーディングに優れてるってAnecdotalなコメントは多いよ。
AIをベータリーダーとして使って10万トークン超の小説をテストしてるんだけど、長文コンテキストだとClaudeはO3/GPT5やGemini 2.5より早く混乱しちゃうんだよね。俺の経験だとGemini 2.5とO3/GPT5は8万～10万トークンまで互角なんだけど、そこからGemini 2.5がリードし始めて、15万トークンくらいになると圧倒的に強いよ。Claudeも悪くないけど、明らかに3位だね。
https://fiction.live/stories/Fiction-liveBench-Mar-25-2025/o…
https://longbench2.github.io/
めちゃくちゃ役に立つコメント、ありがとう！LLMはコーディングだけじゃないってのを改めて思い出したよ。
もっとコメントを表示（2）
うん、ベンチマークがコミュニティの感覚と合わないのは同意だね。Claude Codeと、それを使ってるOpusやSonnetモデルの相性がいいからかな？ツール呼び出しにファインチューニングされてるとか。でも、マルチステップの問題に対するRLとか、何か秘密のトレーニングがあるのかもね。
俺もClaude Codeと同じくらいの精度を、Claudeデスクトップアプリとファイル+bash mcp（ツールは違うけど性能は同じ）で出してるよ。GPT5がベンチマークで高得点なのは、たぶん全部の指示が最初から明確な、よく定義されたタスクだからだと思うな。実際の仕事はマルチターンで、そこはClaudeの方が得意っぽい。
パワーユーザーじゃないけど、最近GeminiとClaudeを試したら、Claudeはコンパイルできて、少し調整するだけでほぼ動くものを作ってくれたよ。次に、もうちょっと詳しく指示したら、ほぼ完璧に仕上げてくれた。一方Geminiは、コンパイル→失敗→修正を試みる→コンパイル→失敗のループに陥って、最終的には“できません”ってギブアップしちゃった。なんか、Geminiはこういう時、自己肯定感がないみたいだね。Claudeはもっと強気だけど（いつも良いとは限らないけど）。Claudeは動くものを作るのが一番得意みたい。価格面でGeminiも強力なライバルになるだろうけど、Googleは品質をもう少し上げる必要があるね。無料で使えるAIエージェントでも、何も解決できないなら意味ないもん。
Geminiが陥るあの“ドゥームループ”は、読んでて本当に不快だよ。“俺ってバカ。恥ずかしい。負け犬。アホ、アホ。あー、最悪。”って。Googleは一体どんなRLでこのモデルを苦しめてるんだろ、マジで。
他のコメントでも言ったんだけど、俺にとって一番良かったのはモデルじゃなくて、UIの表示方法だね。最初はCursorみたいにIDEに入ってないのが嫌だった。でも、それで気づいたんだ。俺はCursorを小さいタスクにばかり使ってて（リファクタリング、小さい関数追加、オートコンプリート）、あまり役に立ってなかったって。Claudeを使う時は、立ち止まって、考えて、計画を立ててから使うようにしてる。だから、もっとインパクトのある変更ができるんだ。別の言い方をすれば、Claudeが俺にもっと求めるから、俺もそれをより尊重して、結果的にもっと多くを得られるんだ。
これは良い点だね。CLI形式だと、ただの“高度なオートコンプリート”としてIDEで使うんじゃなくて、エージェントの目を通してコーディングプロセスに取り組むように強制される感じだ。でも、今ではClaude Codeのクローンがたくさん出てるよね（Gemini CLI、Codex、Cursor CLIとか）。それでもClaudeがまだトップを走ってると思うけど？たぶん、基盤となるLLM（Sonnet 4）がエージェントのツール呼び出しにファインチューニングされてるおかげでコーディング性能が良いのと、Claudeが設定オプションとかでちょっと成熟してるからじゃないかな？
CodexやCursor-CLIはまだ試してないけど、Geminiをいくつかタスクで試した感じ、Claude Codeに比べると全然ダメだったね。Geminiはめちゃくちゃ早く変更に取り掛かるんだけど、俺が求めてるものにはほとんど届かないんだ。動かないか、テストが失敗するかで、テストや根本的な問題を直せって言っても、何も解決せずにもたもたするだけ。Claudeはかなり遅いし、いつも完璧ってわけじゃないけど、問題を段階的に解決して、うまくこなしてくれるみたい。俺が口出ししても、結果をちゃんと改善してくれるしね。
CC（Claude Code）はすごいけど、俺はrooの方が好きだな。Claudeの作業をずっと監視しやすくて、指示したり止めたりしやすいんだ。モードやどのモデルを使うかのコントロールもできるしね。ただ、hooksとかAnthropicが持ってる秘密のソースは使えないし、rooの方がバグも多いけど。
Claudeは悪くないけど、O3/GPT5/Gemini 2.5の方が多くの場合で優れてると思うよ。でも、Claudeはツール利用やエージェント的な振る舞いの訓練が他のモデルよりされてるみたいで、ベンチマークは悪くてもエージェントタスクでは高性能。混乱してめちゃくちゃにしない点が良いね。Claude Codeの強みはエージェントプロセスだ。
Codex CLIも改善されてるけど、まだClaude Codeよりは優れてないと思うな。
Gemini CLIは良いよ。Ampcodeは変更にすごく正確で優秀だね。でもCodex CLIはマジで使いづらい。使えるようになることを願うわ。
他にもさ、値段に対する利用量が重要だよね。
Claude CodeでASCII版Factorioみたいなのを作ってるよ。最初に監督なしで基本機能はできたけど、バグ修正すると別が壊れるなど問題が。Playwrightでの自動テストも質の良いものが書けず、ReactのuseEffectを使ったゲームエンジンも適切ではなかった。今はティックベースのゲームエンジンへ移行し、コードレビューしながら作り直してる。時間はかかるけど、かなり良くなってるよ。良いデモができたらShow HNに投稿するつもり。
そうそう、AIが骨格を作る前の初期段階で人間の貢献はめちゃくちゃ重要だよ。最初の数回の大規模なリファクタリングは、鷹の目みたいに厳しくレビューする必要がある。それが終われば、ちょっとは気を抜けるよ。
君はClaudeに多くの重要な設計判断を暗黙的に任せてるみたいだね？僕の経験では、最初にアーキテクチャや問題の核となる部分をClaudeと話し合うのが良いよ。それから、重要な装飾部分は指示するか、正しい判断ができるように適切な背景情報を与えるのが役立つね。
それたぶんプレイするな。ゲームの情報はまだある？
仕事用と個人用のClaudeサブスクリプション管理に困ってた人、僕みたいにエイリアスを使うといいよ。例えばalias claude-personal=\”CLAUDE_CONFIG_DIR=~/.claude-personal claude\”って感じでね。詳しい情報はここを見てね:
https://julesrosser.com/blog/Multiple-Claude-accounts.html
CLAUDE.mdは100行未満のミニマルにするのが一番良い結果を出すよ。ポイントは、プロジェクトの目的、最小限の構造、よく使うコマンド。Claude CodeはTDDじゃない書き方をするから、僕はTDD-Guardってフックを作って1度に1つのテストだけ書くように強制してるんだ。コード品質はhusky、lint-staged、commitlintで自動化してて、これが決定的な結果を出してくれるよ。この自動化に興味ある人はここを見て！
https://github.com/nizos/tdd-guard
https://github.com/typicode/husky
https://github.com/conventional-changelog/commitlinthttps://github.com/lint-staged/lint-staged
Claude codeはマジで最高だよな。俺が気付いたのは、Claudeに「ループを閉じさせる」能力を与えるべきってこと。コードを書かせたら、それについて推論しようとする。「このボタンはCSSが適切だから表示されるはず」とかね。でも、ループを閉じさせたら全てがもっと良くなるんだ。だから俺は、Puppeteerツールを使ってアプリを起動させ、テスト用認証情報で機能が動くか確認するように常に指示してる。これはウェブアプリの話だけど、ユニットテストや結合テストみたいに他のことでも応用できるのは分かるだろ？ Claudeは自分のやったことを見て、その結果の世界を観察する必要があるんだ。ただ推論させようとするだけじゃダメ。あとClaudeは得意なことに傾倒する傾向があるんだよな。繰り返しはコストがかからないから、同じものを5回実装するのも気にしない。俺が使い始めた頃は、コンポーネントを使わずに全ページにサイドバーを実装したりしてた。だからプロンプトでプレッシャーをかけるか、最後にリファクタリングを強制する必要があるぜ。
Puppeteerを使う時、例えばdivがちゃんと中央にあるかとか、どうやって確認するの？
Puppeteerでスクリーンショットを撮るんだよ。
俺は決まったスペックとか書かないけど、それでもClaudeから結構価値引き出してるぜ。基本的に、もっと低いレベルで何をしたいか細かく指示して、少しずつ進める方法だよ。いつもClaudeが何してるか見てて、変なことしたらすぐ止めて修正する。少なくとも俺には、デカいことさせるよりこのアプローチの方がずっと上手くいってるね。
全く同感。細かい作業を一つずつ頼むべき。デカいことさせようとすると、マジでガッカリするぞ。
エージェントに自分のコードをレビューさせると、驚くほど成果が出るんだ。俺は普段からClaudeの提案にこれやってるんだけど、適用する前にな。Claudeが自分で出したばかりの出力に即座にダメ出しして、俺たち両方をその気から失わせるのがいかに多いか、本当に驚くよ。しかもたいてい納得できる理由付きでね。これ、自動化したいな。
これはサブエージェントの良い使い道みたいだな。https://docs.anthropic.com/en/docs/claude-code/sub-agents
一時期、Claudeが自分のコードをレビューする時、ほぼ過剰に否定的だったことがあったんだ。よく考えたら、俺のコードレビューのプロンプトの言い回しが、ネガティブな傾向でレビューを枠付けて、本質的にClaudeに自分のものにダメ出しさせちゃってたって気付いたんだ。それ以来、そのプロンプトの表現にはかなり労力を注いでるね。
これだよな。最近、難しい問題だとセッションを2つ開くんだ。1つは仕様のドラフトをファイルに書き出して、もう1つのセッションでそれを分析・批評させたりする。その反応を最初のセッションにフィードバックすることもよくある。何回かやり取りしたら、かなり練られた計画ができるんだぜ。実行は新しいセッションでやる。
もしLaravelを使ってるなら、俺が作ったgithub.com/iambateman/speedrunがめちゃくちゃ役立つぜ。/feature [[機能の説明]]って打つだけで、あとは全部やってくれる。このシステムはまず仕様書を作ってくれて、ファイルを配置したり、ベストプラクティスをレビューしたりするのに特化したサブエージェントをいくつか使うんだ。1週間くらい使ってるけど、今ではClaude Codeの使用の約70%がこの/feature経由で動かしてるね。良い点は、たくさんのリクエストを投げて、中断なしで10～15分くらい動かしておけることだ。それに、実装する前に計画ドキュメント一式を作ってくれるから、Claudeが何をどう変更しようとしたか正確に分かるのも良いね。
