6週間のClaude Code体験！ベテラン開発者も驚いたAIコードの実力
引用元：https://news.ycombinator.com/item?id=44746621
Claude Codeを2週間使ったけど、vibe coding懐疑派の俺も驚いたよ。使いこなすには適切な文脈やタスク分割を学ぶ必要があり、プログラミング知識は必須だ。25年の経験があるから、レビューや修正も容易。昔夢見た“コードを書かないプログラミング”が実現した感じ。Gemini CLIはClaude Codeに及ばないね。開発ツールに月＞100ドルなんて考えなかったけど、Maxプランへのアップグレードを真剣に検討中さ。
AIツールは、ジュニアを指導するシニア開発者向けだね。シニアからは、ジュニアがAIで遅くて不安定なコードを生成し、理解しないままPRすると聞く。俺にとっては、ボイラープレート生成やJSON変換、コードの問題点指摘が最適解。手書きコードのバグをデバッグ前に見つけられたこともあるよ。
＞vibe coding懐疑派が驚くのは、多くの人がAIツールの期待値を極端に低く設定してるからだね。彼らはツールがゴミしか作らないと思ってるけど、実際に使ってみると低い期待値をはるかに超えるから驚くんだ。Claude Codeが100億ドルのSaaSを自動生成するわけじゃないけど、世間が評価するよりずっとパワフルなツールだよ。
Claude Codeは良いけど、限界もある。もし全部自分で書いてたら簡単な修正や機能追加が、AI生成された理解不能なvibe codedのアーキテクチャのせいで不可能になる時が来るだろうね。
俺はvibe code懐疑派だよ。だって、それをコーディングだとは思わないからね。ちゃんとしたコードは書けるかもしれないけど、それはコーディングじゃないんだ。
シニア開発者によると、ジュニアはAIで遅く不安定なコードを生成し、理解せずPRするらしい。もしこれが事実なら、10年以内に完全にAIがコード生成すべきだ。そうでなければ、深い経験を要するAIツールに頼るのはプログラミング業界にとって大きな間違いだよ。
コーディングは、炭素から生まれたレプリケーターしかできないってことなのかな？
いや、コーディングはマシンもできるよ。でも、マシンにプログラムを指示してるなら、君はコーディングしてない。マシンがしてるんだ。君はプログラマーじゃなく、ただのユーザーだよ。
IT教育やコンピュータサイエンス（一部はね）は、AI開発ツールを制御する方法を開発者に教えるため、ソフトウェアエンジニアリングやソフトウェアアーキテクチャのスキルにもっと注力すべきだね。
AIコードの実力について、俺は長年機械にプログラムを教え続けてきたよ。
俺たちのCとかGoとかPythonのコードは、結局ASMとか機械語に翻訳されてるわけだし、AIがやってることも本質的には同じじゃないか？って思うんだけどな。
AIとコンパイラは全然違うでしょ。
コンパイラはCとかアセンブラとかJavaみたいな形式言語と状態機械のモデルを理解して使うけど、AIはもっと曖昧な英語で結果を引き出すんだから。そこが決定的に違うんだよ。
いや、全然そんなことないだろ。
どっちも機械にアイデアをアクションに変えさせるって点では同じだよ。
コンパイラの制限された言語はハンディキャップでしかないし、スキルでもない。昔から「自然言語」コンパイラがゲームチェンジャーだって言われてきたけど、AIってまさにそれじゃん！
「コーディング」って何かって話になってくるな。
脳はPCじゃないし、抽象的なルールで学ばないよ。
実際にやってみないとダメなんだ。
AIはテキスト上のコミュニケーションで動くけど、脳は現実世界からのセンサーデータで動くんだから、そこが全然違うだろ。
脳は言語で考えてるわけじゃないし、抽象化は苦手なんだ。
結局、一番の学びは「実生活で実際にやること」だよ。
参考になるリンクはこれ→ http://howthebrainworks.science/how_the_brain_works_/the_bra…
シニア開発者として、オフショアのジュニアが書いたコードのレビューにめちゃくちゃ時間かけてきたんだけど、Claude CodeみたいなLLMコーディングツールはマジで神様からの贈り物って感じ！
ただ、ジュニアがこれを使うのは心配だな。適切な文脈を与えられないと、動くけどひどいコードを大量生産しちゃうからさ。
AI使うなら、もっとちゃんと境界線を決めて、やったことをしっかりレビューしろよ。
明確な指示を出して、作業終わったら「お前がスタッフエンジニアかチームリーダーのつもりで、自分のgit diffをジュニアのコードだと思って厳しくレビューしろ」ってプロンプト出すんだよ。
あー、「お前が間違った使い方してる」ってやつね。
問題はさ、AIは学習しないってことだよ。だから、ずっと監視し続けなきゃいけないんだ。
それなら、道端で捕まえた人をソフトウェアエンジニアに育てた方がマシだろ。
AIの最高なところは、限られた時間でめちゃくちゃ多くのことを試せるってことだよ。
アイデアがあればAIでサッと作って、テストして、どこがダメか確認できるんだ。
AIは教育にもすげー役立つぜ。もっと実験や実践ができるようになるからな。
数ヶ月前まで月20ドル超えのサブスクなんてありえないって思ってたのに、今じゃMax 20プランに月200ドルも払ってるなんて驚きだよ！
経験豊富な開発者として、他のツールは使い物にならなかったけど、Claude Codeはマジでレベルが違うね。
手作業は多いけど、こいつに要求を完全に理解させてからやらせてレビューするんだ。
「ちょっと間抜けだけどめちゃくちゃ知識があって、超高速で文句言わないジュニアエンジニア」って感じかな。これがソフト開発の未来だね！
最近のClaudeモデルは、SQLの記述や編集では信用できないって感じてるよ。
例えば、条件は正しく書いても、ANDとかORの周りにカッコを追加しないんだ。
（Gemini Proはちゃんとそれをバグだって指摘したけどね）。
AIを使ったらAIの使い方を学ぶだけで、ちゃんとしたアーキテクチャでメンテナブルなソフトを作る方法は学べないよ。限られた時間で多くをこなせても、知識は表面的なパターン認識に過ぎない。本当にプロジェクトの本質を理解するには、やっぱ自分で手を動かして何かを作る経験と組み合わせるのが大事だね。
ふと思ったんだけどさ。もしシニア開発者はClaude Codeから恩恵を受けるけど、ジュニア開発者はそうじゃないってのが本当なら、どうなるんだろ？新しく登場する”10x”エンジニアが、ジュニアデベロッパーが手伝ってた仕事を全部やっちゃって、誰も新しいジュニアデベロッパーを育てなくなるんじゃないか？だって雇えないんだから。これって正しいのかな？
前々からそうだっただろ？1人のシニアデベロッパーなら1週間でできることが、ジュニアのチームだと4週間かかって、しかも質が悪くなるって。なのに、なぜか企業はいつも後者を選んでたよな。人員数が多い方がステータスになる、とかそういう関係あんのかな？
オフショアの話、マジで同意するわ。俺も前から、マルチタイムゾーンで何日もかけてやり取りするのを避けるために、タスクをめちゃくちゃ細かく分解して、予想される問題は全部自分で潰してたんだ。そのおかげで、もはやオフショアの価値は全然感じないね。
Cursorでも同じような体験ができるのに、わざわざターミナルを使う必要ないと思うんだけどな。Claude Codeがそこまで優れてるとは思えないんだよな。
自然な人間の言葉を使うなら、それはもはやコーディングじゃないだろ。
いや、俺の経験とは違うんだよな。CursorとClaude Codeをめちゃくちゃ使おうと頑張ったんだけど。20～30回くらい、色んなプロジェクトでCodeを試したけど、ほとんど全部ダメだったよ。Python、Rust、Bashで使ったり、情報収集や整理、デバッグにも使ったけど、全部失敗。どうやったらみんな生産性上げられてるのかマジで分からん。めちゃくちゃ時間食って、何も成果なし。唯一成功したのはSQLクエリの最適化を頼んだ時だけだね。まあ、めげずにこれからも試してみるけど、何か「コツ」みたいなのが掴めてないのかもな。
インドの失業率、壊滅的なことになるだろうな。これって地政学的な問題に発展するぞ。
コンパイルされるコードは決定的だけど、LLMにコードを作らせるのは非決定論的な当てずっぽうゲームだろ。コンパイラを疑う奴なんて誰もいないのに、なんでLLMは疑われるんだ？
多くの懐疑論者が、ちょっと言い方がアレだけど不誠実なのも困るんだよな。数日前、ここで誰かが「ごちゃごちゃしたデバッグログを挿入するのは『ちゃんとしたプログラミング』で、人間がやるべき重要な仕事だ」って言ってたけど、違うだろ。Claudeなら俺がやるよりずっと速く、もっといいフォーマットでコードベース全体にログを作ってくれるから、俺はマジの問題解決に集中できるんだよ。イライラするけど、このフォーラムではよくあることさ。ごめん、正直「不誠実」は言葉が過ぎたね。意見が違うだけだ。謝るよ。
Claudeはミスを見つけたりコミットメッセージを書くのが得意だよ。
たまにメッセージを代わりに書かせるけど、主観的な意見とか誇張を避けるように指示しないといけないんだ。「変更点を簡潔にまとめて。形容詞や最上級は使わないで。命令形を使ってね」ってね。
もっとコメントを表示（1）
Claudeが書いたコードをちゃんとレビューすれば、理解できないコードにはならないはずだよ。
プロジェクトのアーキテクチャから外れないように気を付けてる。昔、ジュニア開発者がプロジェクトを変えようとしすぎて困ったけど、Claude Codeならそういう問題はないね。
Claude Codeは他のAIよりすごく優れてるよ。(2023年からAIコード生成のCLIツールを自作してて、いろんなオプションを試してきたからわかるんだ)。
筆者のやり方にはめちゃくちゃ同意。
1.モノレポは時間節約になる
2.良い仕様から始める
3.最初からテストが重要
4.型とリンターが助けになる
5.外部ドキュメントをプロジェクトに入れる
6.ツール習得には時間がかかるけど、Claude Codeなら楽。今週はPermisoっていうGraphQL RBACサーバーを開発したよ。
https://github.com/codespin-ai/permiso
コメント3への返信だよ。
仕様書のアウトラインって具体的にどうやってるの？Markdownファイル？どれくらい詳細なの？
テストの件だけど、Claudeはテストフックがあると、テスト前にバグ検証する能力を失って、自動修正に入っちゃって変になることがあるんだ。テストの挙動を有効/無効にできるフラグを作ってるよ。
コメント4への返信。
仕様書のアウトラインはMarkdownで書いて、AIに肉付けさせてるんだ。
その後、API署名とかDBスキーマも含む詳細なレベルになるまで洗練していく。
テストはまず基本的なプロトタイプを作って、そこからテストとコードを継続的に改善してるよ。型とリンティングもすごく役立つね。
アウトラインすら自分で書かないよ。CCに計画を立てさせて、CCと一緒に反復するんだ。
たまにGeminiにレビューさせて、CCにGeminiの提案を適用させることもあるね。
このワークフローのためにツールを作ったよ。MCPとバージョン管理が含まれてて、CursorとかClaude desktopとか、どんなプラットフォームでもファイルを簡単に追跡・編集できるんだ。
https://github.com/jerpint/context-llemur
どんなプロジェクトがこのアプローチにもっと向いてるのかな？
僕のワークフローだと、LLMエージェントなしでフレームワークに頼ってて、一番難しいのはビジネスドメインの把握なんだよね。コーディングはそれに比べたらすごく楽なのに。
コメント8への返信だよ。
LLMを使ったプログラミングで節約できる時間って、使う人のドメイン知識と問題がどれだけ一般的かによって全然違うんだよね。
ドメイン知識が豊富で問題が一般的だと100倍も効率が上がるけど、そうじゃないと0.1倍から10倍くらいに幅があるよ。
このためにツールを作ったよ。LLMと一緒にコンテキストリポジトリを作成・維持できるんだ。
CLIは人間向け、MCPはLLM向け。コンテキストリポジトリにあるものは何でもLLMの次のステップに使われるべきで、タスクが進むにつれて両方が維持していく責任があるんだ。
https://github.com/jerpint/context-llemur
俺のフローもこれと似てるんだけど、リポジトリの一部であるファイルを使ってるんだよね。おまえのツールについて質問なんだけど、Gitでバージョン管理してるのにコードじゃないコンテキストも書いてるって、何でそうしたの？例えばバックログが複数バージョンになっちゃうけど、それってどんなメリットがあるの？
俺が思うに、コンテキストってコードとは多少独立して進化するんだよね。でも、コードと同じように追跡したいじゃん？裏でGitを使えば、その進化を追跡したり、LLMが変更したものを元に戻したり、差分を見たりするのが簡単になるんだ。それに、ToDoや新機能のアイデアがコードベースを汚さないで追跡できるメリットもあるんだぜ。
俺はまず基本的なMarkdownでアウトラインを書いて、次にシステムを流れるように（でもまとまった）思考でプロンプトに詳しく説明するんだ。そして、一番重要なのは「LLMが一番理解して使えるように仕様を整理して」ってモデルに頼むことだね。結果として、全部の重要な部分が入った、ずっと簡潔なドキュメントができるんだ。（あるいは、人間向けにもっと詳細な仕様を書いて、マネージャーに提出する必要があるなら、LLMにLLM向けに調整された別の仕様書を書かせることもできるよ）。
ClaudeでPlaywrightを使うのは本当に面倒なんだよね、でもなしでは生きられない気がする。全ての機能の約70%は、Playwright周りの厄介な問題を直すのに費やされてるみたい。テストの実行、基本的なデータ設定とクリーンアップ、認証、そしてごく基本的なベストプラクティスで苦労してるんだ。俺はこれ全部をまとめたテストガイドを持ってるんだけど、何でも中途半端なんだよ…。
モノレポは時間を節約できるって言うけど、Claudeの時間と、必要なものを探すためにツールを呼び出す大量のトークンを犠牲にしてるんだよね。Aiderの方がずっといいよ。必要なファイルを教えて、作業させられるから。Aiderはほぼ全ての点でより良いツールで、タスクに最適なLLMを使えるのに、なんでClaudeの方が人気なのか、俺にはまだ理解できないな。
Aiderは必要なファイルを教えてあげれば、うまくやってくれるって言うけど、ユーザーとしては15〜30個ものファイルをいちいち指定して、漏れがあったら全部台無しになるのは嫌なんだ。コードベースをツールに指し示して「Xをやって。現在の実装やパターン、テスト、ドキュメントを見て、必要に応じて更新して。テストの実行方法はこれだよ…」って言いたいんだよね。コードベース全体をQdrantにインデックスするのも少しは役立つかもね。
そうしたい気持ちは分かるけど、少なくとも個人的にはAiderで手動でコンテキストを管理する方が、Claude Codeに自分で必要なものを判断させるよりもはるかに良い結果が得られたんだ。面倒だけど、何が変更されるかより意識できるし（しばらくして大きな差分を見るのに比べて）、初めからうまくいく可能性が高い小さなサブタスクに取り組むのに向いてると思うよ。
Claude Codeでも、関連ファイルを起点として与えられれば、ずっと良い結果が出るんだよ。その点では、この2つのツールはそんなに変わらないんだぜ。
Aiderはリポジトリ全体のツリーを知ってるんだ（Gitインデックスをスキャンするからね）。ただ、指示しないとファイルは読まないだけなんだ。もしファイルへのアクセスが必要だと判断したら、追加するように促してくるよ。俺はこれがかなり良いモデルだと思うな。もちろん、オフラインでは動かないけどね。
だって、動くからだよ。正直、これに尽きるね。「fooモーダルのバーボタンがsplorkエラーで壊れてる」って一文プロンプトで、Claude Codeはfoo.tsを探し出して、それがquery.tsへのAPI呼び出しだと追跡して、関連するリンクされたモデルを取り込んで、api/slork.goまで追跡して、たいていの場合「問題を見つけました！」って直してくれるんだ。初めてこれが動くのを見た時は「Oh fuck」って瞬間だったと思うよ。驚くほど信頼性高く動くんだぜ。［ただし、LLMはバカとか、注意点は色々あるけどね］
モノレポの代わりに、別のリポジトリをワークスペースに追加する方法があるよ。Claudeにパスを教えれば、セッション中にそのコードをワークスペースに入れてくれるらしい。
Aiderってやつはもっと良いよ、必要なファイルを教えて放っておけばいいから。Claudeなら/add-dirを使えばいいんじゃない？
CCは構造が大事ってマジ同意。Djangoプロジェクトでは結構役立つけど、たまに指示は必要だね。ローカルモデルでCCを使おうとしたら、肝心な問題を避けて、新しいファイルをバンバン作るだけで困っちゃったよ。
構造って本当に重要だよね、思考の垂れ流しを信用するより。ユニットテストでは、俺は事前にテストを書いて構造を学ばせたり、モックやテストクラスで制約を設けてる。制約があると、一からやるよりずっと良い結果が出るんだ。LLMは巨大な関数評価器で、探索空間がデカい。うまく誘導すればするほど、最適解に収束するよ。
外部のドキュメントをプロジェクトのドキュメントに入れるって話だけどさ、ほとんどのプロジェクトのドキュメントってウェブサイトにあるじゃん？それ、わざわざ綺麗なMarkdownファイルに整形するのに時間かけるの？
Claude Codeの本当の力ってコード書くだけじゃないんだぜ。実はPC全体をコントロールできるんだ。CLIツールがあれば使えるし、なくてもClaudeに聞けば意外とできるかもよ。俺は画像のクロップやリサイズ、YouTubeからMP3抽出、音声ファイルの無音部分カットなんかにも使ってる。マジで時間が節約できるし、もうこれなしの生活なんて考えられないわ。
「PRやコミット、マージされたコード行数に大きな変化はない」って記事の主張、その通りだよな。Claudeを使っても結局アウトプットは同じ。生産的だと”感じる”だけ。モデルの”子守り”に時間を食われて、結局帳消し。それに、きつい部分を丸投げするから思考の筋肉が衰えるし、スキルも落ちる。長い目で見れば、コードベースも劣化して、むしろマイナスになるかもな。
最近ヴァイブコーディングを試してるんだけど、一番のメリットはマジで精神的な負担がないこと。コード全体を覚える必要もないし、頑固なバグに悩まされながら次の実装を考える必要もないんだ。Mr.スマートボットに聞けば、校正からドキュメンテーションまで何でもやってくれる。たまにちょっとしたミスはあるけどね。
「CLIツールがなくてもClaudeが使える」って言うけどさ、そんなのClaude Codeいらないよ！r/unixpornとか見てみろよ。主流のOSがPCを有用なツールじゃなくて、ただの消費者向けオモチャにしちゃったって気づくはずだから。
これって、自動化したい人にとっては夢が叶ったようなもんだよな。何でも自動化できるし、スクリプトも書けるし、ドキュメントも作れる。将来ローカルモデルを使うことになったとしても、俺はこのインターフェースを使い続けるだろうな。それくらいパワフルだよ。
tarで解凍するのって結構複雑だし、Unixスクリプトを適当に集めるのは2025年には誰もやりたがらないだろうね。
もっとコメントを表示（2）
「精神的負担」ってのは筋肉の負担と一緒で、使わないとすぐ衰えちゃうもんだよ。
精神的な負担がないことと脳機能の低下に確たる証拠なんてないよ。せいぜい漠然とした研究結果が出てるだけじゃん。
スクリプトって？俺はもう10年も”tar xzf file”より複雑なものなんて使ってないぜ。
LLMが直せないバグにぶち当たったら、自分でコードをいじらなきゃいけなくなる。そしたらLLMが作ったコードがマジでひどいってわかるよ。
長い間人間は、継続的な練習が必要な難しいことをしてきたんだよ。ピアノみたいに、ごまかせないことをする人に数ヶ月休んだらどうなるか聞いてみなよ。一度身につけたスキルは取り戻しやすいけど、使わなきゃ絶対衰えるからね。
「パソコン全体を制御できる」ってさ。それ、マルウェアみたいじゃん。
一つを覚えるのは簡単だけど、全部覚えるのは大変だよね。エージェント型のCLIがあれば、安全かどうか確認する以外何も覚える必要ないんだ。
俺のアセンブリのスキルはひどく衰えちゃったけど、それでいいんだよ。
ちょっとした自動化のために大量のGPUをフル稼働させるなんて、夢じゃないよ。企業はそれで大損してるし、さらにコンピューターの内容まで監視に晒されちゃうんだからね。
https://www.wheresyoured.at/the-haters-gui/
うん、ClaudeはXKCD 1319：https://xkcd.com/1319/を終わらせたね。自動化がめっちゃ簡単になった。面倒な繰り返し作業をshell scriptで自動化しようって思ったら、Claudeが一発でやってくれる。Productivity gainsがProductivity gainsを生むループだね。
LLMを使うのは抽象度を上げてるんじゃなくて、君の脳みそをその抽象化から完全に外しちゃうってことだよ。
君はコードの品質にすごく厳しいのかもだけど、俺はLLMが汚いコードを作るって思わないな。むしろ、人間よりずっと丁寧にコードを構造化して、論理的で分かりやすくしてくれるよ。例えば、変数名を最初にちょっと間違えて、後から気付いても直すのが面倒で放置したりするけど、LLMはそういう心配がない。automated refactoring toolsがあっても面倒な作業だからね。
まだそんなバグには遭遇してないな。もし2回目のデバッグでうまくいかなかったら、俺は別のモデルに切り替えるか、コードをconsole logsで埋め尽くさせたり、test scriptsを書かせたり、web searchさせたりするよ。これらのモデルの強み（でもあり弱み）は、無限の忍耐力があることだね。
まあ、俺と年間1200ドルのサブスクリプション代を足しても、俺2人分よりはるかに安いよ。
違うね、だってコントロールするのは君自身だからさ。AIじゃないよ。
俺の場合は違うな。デバイスのBluetooth protocolをreverse engineerしたんだ。wiresharkでデータストリームをcaptureするのに数日かかるところを、LLMにdumpを丸ごと投げたら、正しいoffsetを見つけるのがずっと簡単になった。たった1日で済んだよ。
tarコマンドは覚えるまでは意味不明だけど、学んでみれば難しくないよ。tar xzvf ＜filename＞は”tar eXtract Zipped Verbose File ＜filename＞”で、tar czvf ＜filename＞ ＜files＞は”tar Compress Zipped Verbose File ＜filename＞ ＜files＞”だ。解凍ならx、作成ならcを使う。.gzファイルを扱うならzを足す。vはファイル名をstdoutに出すoptionで、fはファイルからの読み書きを指定するんだ。それからファイル名を指定する。別に難しくないって。
俺はLinux PCがcrashする原因のdiagnosisにLLMを使わせたよ。俺の代わりにjournalctlでたくさんgreppingしてくれて、助かった。多分直ったと思うけど、様子見だね。
Claudeは1200ドル以上かかるってのがポイントだよ。その費用を全部払うのはお前じゃないってだけ。HNには、いつかきっと破綻するであろうツールに完全に依存することに、めちゃくちゃ興奮してる奴らがゴロゴロいるみたいだね。プログラミングっていう技術が、基本的なことすらクラウドに頼るようになるなんて、マジで残念なことだよ。
それってさ、「車なんていらない、この自転車屋に十分長くいれば、運動して町中を移動できるって気づくさ！」って言うようなもんじゃん。
CLIコマンドを実行するだけじゃなくて、Claude Codeはそれらと連携できるんだよ。例えば、俺が作ったこのちっちゃなツールを使えば、Claude CodeにTmux-cliコマンド（Tmuxの便利なラッパー）を与えて、CLIアプリケーションとやり取りしたり監視したりできるんだ（https://github.com/pchalasani/claude-code-tools）。これで、Claude Codeが別のClaude Codeインスタンスを起動させてタスクを与えたり（組み込みの黒箱よりずっと良い）、ユーザー入力を必要とするCLIスクリプトとやり取りしたり、Pdbみたいなデバッガーを使ってトークン効率の良いデバッグやコード理解ができるようになるぜ。
モデルは構造化も論理的なシーケンスもめちゃくちゃ丁寧なんだけど、それは最初だけ。3〜4回やり取りすると、元のアーキテクチャを忘れちゃって、必要なデータ構造を重複させたり、アムネシアレベルの繰り返しや、「ほとんど同じ」ことをする重複コードができあがって、どんどん進歩の毒になるんだ。人間が介入しないと、どんどんひどくなるよ。厳密な型、明確なパターン、明確な構造を設定して、介入して説明・指示する、シニアエンジニアがジュニアのPRで「なんでこの既存のデータ構造を拡張して、XYZの自明な拡張にその呼び出しをファクタリングしなかったの？」って突き返すようなことね。「まったくその通りです！」ってな。
開発者の生産性が上がると、ソフトウェアの需要も増えて、その生産性向上が給料アップにつながることを期待してるぜ。
まあ、俺には正しい解決策を見つけるまで待つ忍耐力がないんだよね、あはは。
俺はClaude Codeを使い始めて2週間、毎日12〜16時間使ってるぜ。
見つけたコツはこれだ！
1. すぐにSonnetに変えること（CLIは最大ユーザー向けにOpusがデフォルトだけど、Opusでコーディングを広範囲に試したけどSonnetの品質には全然及ばなかった）。
2. 圧縮（Compacting）はよく進行を止めるよ。圧縮後に元のコード品質に戻すのは難しい。
3. 最初のプロンプトはめちゃくちゃ重要で、全体の雰囲気（vibe）を決める。Claudeのインスタンスが躊躇したり、疑ったり、時には失礼だったりするなら、セッションを終了してやり直した方がいつも良いね。
4. より効果的なフレーズがある。「ごめんなさい、これは悪い提案かもしれませんが、XとYを実装したいです」って試してみて。なぜかClaudeはもっと手伝おうと積極的になるんだ。
5. Dockerオーケストレーションを使ったモノリシック化：Claude自身にDockerコンテナを管理させたり、エラーログをチェックさせたり、削除させたり、再構築させたりし始めたら、実質10倍速くなったよ。今じゃ、まったく新しいサービスをゼロからDockerコンテナで運用可能にするまで、一つのClaudeプロンプトでできるぜ。
- Dockerだけじゃない、Playwright MCPサーバーを使えばUIでの実装が見えるようにできるよ。
6. プランモードで始めて、満足するまでプランを繰り返すんだ。
7. スラッシュコマンドを使おう。それらは、開始コンテキストを提供したり、Githubとやり取りするためにghのようなツールを使えることを思い出させたりできる、時間とともに改善できるミニプロンプトだよ。
1.については同意できないな。2.良いキリがいいところで圧縮するべきだよ、0%に追い込まれてからじゃなくてね。
Playwright MCPサーバーじゃなくて、ただの$ playwrightでいいんだよ。MCPの面倒な手続き（と無駄なトークン）をスキップして、Claude CodeにCLIツールを使わせればいい。驚くほどうまくいくぜ。
エージェントを使ってコードを検証するんだ。過剰設計されてないか、規約や仕様に合ってるか、実際に実装されてるか、それとも半分デタラメか。俺は機能やタスクの終わりに3つのエージェントを走らせるんだけど、ほとんどいつもOpusをワークベンチに戻して色々直させてるよ。それに、エージェントは独自のコンテキストを持ってるから、メインのコンテキストを汚さずに長く使えるんだ。
