毎日Claudeを使ってるけど、同じような経験をしてるよ。面白いエピソードとして、知り合いがエージェントを使って新機能のコードとユニットテストを書いたんだけど、コードが微妙に間違ってたんだ。まあ、そういうこともあるよね。でも、追加した30個くらいのテストがテストの実行時間を10分も延ばして、結局「expect(true).to.be(true)」みたいな内容になっちゃった。LLMがテストでコードが動かないのを回避してたからね。

自分が試してみて、そこそこうまくいったアプローチはこれだよ。まずコミットを作る。Claudeに特にオープンエンドじゃないタスクを与えるんだ。純粋な「単純作業」みたいなものに近いほどいい（自分が扱いたくないタイプのコードね）。できれば、コードベースのファイルを1、2個触るだけのものが理想。 trivialなリファクタリング（同じメソッド呼び出しをあちこちで変更するみたいな）じゃない限りね。計画モードに設定して、計画を立てさせる。計画をレビューして、実行させる。うまくいけばラッキー、次はレビューだ。結構面倒なタスク、例えばコードをあるプラットフォームから別のプラットフォームに移植するみたいなのを一発でやってくれたこともある。明らかなミス（プログラムがビルドできない、テストが通らないなど）があれば、数回のイテレーションで解決できることが多い。微妙なミスがあれば、ブランチを作って再挑戦させる。失敗したら、これはもう無理だってことで、そのブランチを中止して自分で解決する。書いたコードをレビューしてクリーンアップするけど、だいたい必要以上にごちゃごちゃしてることが多い。これでコードのオーナーシップを持てるし、何をしているのか、どう動いているのかも分かるようになる。ガイドラインや制約を与えるのはやめた。あいつはそれを信頼して守れないからね。「このプロジェクトはCMakeを使うから、こうやってビルドして」って言っても、何度も無視されて、makefileを直接間違ったフォルダで呼び出そうとする。これであまり時間が節約できるわけじゃないけど、レビューとクリーンアップに時間がかかるから、いいブロッカーにはなる。あとは、話せるラバーダックとして使ったり、ドキュメントのソースとしても役立ってる。これには結構助かってる。このエージェントたちがコードベースで一緒に働くってアイデアは、俺には面白い。これを「fiverrで雇った前向き健忘症のジュニアたち」に置き換えたら、どれだけうまくいくかって感じだね。

Googleの主任エンジニアがTwitterに投稿してたけど、Claude Codeはチームが1年かけてもできなかったことを1時間でやったらしい。2日後、みんなが騒いだ後に、コンテキストが追加されたんだ。チームはその年にいくつかのバージョンを作って、それぞれにトレードオフがあったみたい。それらの情報がAIに与えられて、AIは「おもちゃ」バージョンを作れたんだと思う。おそらく、似たようなトレードオフがあったんだろうね。私の経験もあなたと似ていて、こういうGoogleのエンジニアみたいな人たちが盛り上げて、コンテキストを省いてるから、期待が現実とかけ離れちゃって、フラストレーションや失望につながると思う。

毎日、仕事でClaud Opus 4.5を使ってるよ。手でコードを書くことはほとんどなくなった。AIが書いたコードをそのまま受け入れるわけじゃなくて、一緒に改善してる。うちの職場ではコードレビューもあるし、ツールからはかなりのメリットを感じてる。手動で1〜2週間かかると思ってた中規模プロジェクトを、エージェントツールを使って1日くらいで終わらせたこともある。具体的な利点をいくつか挙げると、* 複数のエージェントを並行して立ち上げて、交互に使える。* 自分が得意じゃない言語でも能力が大幅に向上した。例えば、10年くらい維持してるChrome拡張を作ったんだけど、JavaScriptが苦手で。Antigravityにその拡張を指示して、「この拡張を改善して」ってオープンエンドなプロンプトを与えたら、5分くらいで質が大幅に向上したんだ（UIが良くなったり、パフォーマンスが上がったり、依存関係が減ったり）。JSの専門家なら簡単だったかもしれないけど、私はそうじゃない。私がうまくいってるアプローチはこんな感じだよ：1. エージェントに仕様をできるだけ明確に伝える。コードを分析して、仕様に基づいて計画を立てるように指示する。エージェントには、相談なしに変更を加えないように言う。2. エージェントと計画を繰り返し見直して、良いアイデアだと思うまで続ける。3. エージェントに計画をステップバイステップで実行させる。各ステップの間に一時停止して、フィードバックをもらうようにする。4. 各ステップの間に、エージェントが何をしたかを見て、気づいた修正点や計画の変更を指示する。（全体の計画を思い出させると、時々忘れちゃうから、助けになるよ）。5. コードが完成したら（または各ステップの間でも）、ロジックを維持しつつスタイルを改善するコードクリーンアップのサブエージェントを実行するのが好き。これが私にはうまくいってる。テキストベースのインターフェースだから、文章の明確さが大事だと思う。エージェントに提供する仕様を慎重に明確にすることが重要だね。

AI支援のコーディングを誤解してるよ。AIが自分の代わりに仕事をしてくれると思ってるなら、それは違う。AIはアシスタントであって、チームメイトじゃない。もしAIの「失敗」として、間違いやバグ、誤解、コードの消失、方向性の誤りを考えてるなら、価値を理解できないと思う。ポイントは、良いAI支援開発者はそういうことをうまく乗り越えて、AIが持ってくる混沌とした材料から素晴らしいソフトウェアを作るスキルを持っていること。だから、こういう記事は「全然わかってない」ってことになる。AIに自分の仕事をさせようとして、チームメイトの基準で評価してるから、うまくいかないんだ。

一つの致命的な欠陥は、エージェントにアプリをゼロから作らせることだと思う。私はエージェントで大成功を収めたけど、それは人間が設計した既存のアプリに対してだけだった。エージェントはアーキテクチャが苦手だけど、既存のものに従うのは得意なんだ。他にエージェントの成功に寄与する要素は、 - スタティック型システム（Typescriptみたいに後付けじゃないもの） - テストスイートが大規模なコードをカバーしていること（つまり、個々の関数の単体テストだけじゃなくて、e2eスタイルのテストが必要だけど、フラッキーなブラウザテストはダメ） これらの条件を満たせば、私は「サンプル」レビューだけで済むんだ。つまり、すべての変更をレビューするわけじゃなくて、一部をレビューするだけ。もし前の変更で見逃した変なところを見つけたら、それを直すように指示して、修正をフルレビューする。アーキテクチャの変更については、自分で計画して作業を始めてから、エージェントに仕上げてもらう。

私にとって、唯一重要な指標は、最初のアイデアからそれがしっかりして考えなくても良くなるまでの壁時間だよ。エージェントによるコーディングは、この点でフレームワークに似てるね： 1. アライメントが合ってれば、時間を節約できる。 2. 合ってなければ、もっと時間がかかるかも。 3. どちらのケースが当てはまるかは、方向転換が高くつくまで明確な証拠は得られない。 4. ただし、場合によってはこれが当てはまらず、明らかになることもある - 少なくともあなたはそう信じてる。

機能を始めたり、バグを直したりするのには役立ってるけど、機能によるかな。僕はクロードソネット4.5を使ってて、ウェブソケットの設定やドラッグ＆ドロップのUIみたいなよく知られた問題には結構いい仕事をしてくれる。手作業だともっと時間がかかるからね。それに、僕のコードベースの既存のパターンに従うのも上手い。ルーターやサービス、リポジトリの実装とかね。だけど、テキストを構造化されたオブジェクトにパースするような、複雑でごちゃごちゃした問題にはうまく機能しないことが多い。エッジケースが何千もあって、気をつけないとすぐに複雑になっちゃうから、その場合はほとんど手作業でコードを書くよ。あと、一度だけ実行する必要があるアドホックなスクリプトを書くのにも使ってるけど、その時はざっと確認して正しいと判断したら、そのまま使ってる。手作業だと試すのが怖くてできない機能を作ることもあるし、テストを書くのにも使うけど、スタイルがあんまり好きじゃないから、かなりシンプルにしちゃうことが多い。自分に合う使い方を洗練させていくうちに、使い方も変わっていくと思う。

LLMにお金がかかってるのは、コスト削減につながるからだし、開発（高コストで共通のボトルネックと見なされてる）は大きなチャンスだってことを忘れないでね。マイクロインフルエンサーの有料キャンペーンもあったりするし。あと、多くの人が最前線にいるように見られたいと思ってることも忘れないで。著名人も含めてね。彼らはコースやコンサルティングの予約や、本や商品を買ってもらうことでお金を得てるから、「パーソナルブランド」はかなりの価値があるんだ。彼らは時代遅れには見られたくないから、今のことよりも、何ができるか、何が起こるかについて話すことが多い。お金が全ての動機じゃないけど、役に立ちたいって気持ちもあるし、実際に試してみたいって思ってる人も多いよね。そういうわけで、君のアプローチはいいと思うよ。エージェントが何をしてるかを見ないと、信じるしかなくなるからね。何かを動かす最速の方法なのか？たぶん違うだろうね。能力や落とし穴を理解するための最良の方法なのか？そうだと思う。この分野は比較的新しいから、LLMを使った開発のベストアプローチを本当に理解してる人はいないと思う。多くの人が取り組んでるけど、科学的な方法に従ってるわけじゃないことが多い。いずれ証拠が出てくるだろうね。

プログラミングを20年やってきて、いつも物事にかかる時間を過小評価してるんだ（誰かに厳密な見積もりを求められたわけじゃなくて、仕事の優先順位を決めるときにざっくり話してるだけ）。この前、同僚に見積もりを出したら、「でも本当にどれくらいかかるの？いつも言ってるより早く終わるじゃん。2週間って言って、実際には2日で終わるし」と言われた。LLMのおかげで、物事をもっと早く終わらせられるようになるし、どれくらい時間がかかるかの直感的な見積もりもまだそのことを考慮してないんだ。（タイピング速度について話す人もいるけど、それは全然関係ないよ。僕はいつも周りの同僚の中で一番速くタイピングするし、一番早い開発者なんだ。）そう、コードをレビューしたり、エージェントとやり取りしたりする必要があるけど、これまで一緒に働いてきた多くの開発者よりもずっと良い仕事をしてくれてる。もしコードのスタイルが気に入らなければ、ほんの少しの言葉でLLMが「理解」してくれて、改善してくれるんだ。一部のコメントでは、LLMをジュニアと比較してるけど、ある意味ではその通りだと思う。仕事の関係は（驚くほど速い）ジュニアに対するのと同じかもしれないけど、コミュニケーションスタイルや知識の範囲、何かを説明するのに使う言葉の少なさは、むしろシニアと話してる感じがする。（最近10年間のキャリアでは、他の人のコードをレビューしたり、タスクを委任したり、コードベースを一番よく知ってる人として他の人を助けたりするのが大きな仕事だったから、委任することには慣れてるんだ。最近仕事を変えて、今はAIと一緒に一人でコーディングしてるけどね。）