ここは二重人格の雰囲気があって好きだな。

クソみたいなプラットフォームに対処する時、AIは本当に最高だよ。アトラシアンのリフレッシュキーの扱いが変で、自動化を書く羽目になった不運があったけど、AIがアトラシアンがリフレッシュキーを一回使ったら無効にするっていう天才的なアイデアを指摘してくれなかったら、もっと時間を無駄にしてたと思う。この手の手作業には、AIが最高のツールだね。

同意する。トリビアルな関数のかなり包括的なユニットテストを生成するためにLLMを使うからって、それがコアの複雑なビジネスロジックと同じくらい有用だとは限らないよ。そっちの方が微妙なミスをしやすいからね。

テストフィクスチャー。気になるんだけど、AIはどうやってあなたの欲しいものを知るの？

一方で、周りの先輩たちは自分のやり方に固執して、printf()デバッグの習慣を置き換えるためにインタラクティブデバッガーを使おうとしないし、AIツールなんて論外だよ…。俺が業界に入った頃は、インタラクティブデバッグをよく使ってた。経験を積むにつれて、だんだん使わなくなったけど。printf()は意外と便利なんだよね。ちょっとアップグレードしてログレベルを意識したフレームワークにすれば、デバッグ用の行をコードに残しておいて、loglevel = TRACEやINFOでオンオフできるから。

インタラクティブデバッガーとprintf()はどちらも完全に有効で、いくつかの重複はあるけど別々のユースケースがあるよね。もしどちらか一方だけを使おうとしてるなら、考えるべきことがいくつかあるよ。

ちょっと細かいことを言うけど、printfデバッグには何の問題もないよ。並行プログラムをデバッグするのにすごく役立つし、一部を止めると状態が崩れちゃったり、再現しようとしてたバグを回避できたりすることもある。ツールについて言えば、AIコーディングが本当に好きなんだ。私のワークフローは、ChatGPTにインターフェースを貼り付けて、そこからコピー＆ペーストする感じ。接着コードは手で書くことが多いかな。テストケースも定義して、面倒な部分はAIに任せる。問題を解決するのが好きだし、タイピングが本当に嫌いなんだよね :)

インタラクティブデバッガーを試してみたけど、印刷よりも良い結果が出た状況にはまだ出会ってないな。インタラクティブコンソールを使って何がどう動くかテストするけど、アプリ内では印刷が一番簡単で早い解決策だった。

古い連中はデバッガーが使えないからprintfに頼ってるわけじゃなくて、デバッガーはプログラム全体を止めちゃうし、一歩一歩進めなきゃいけないからなんだよね。printfだと、全体のトレースやログを一目で見れるから、全体の流れが把握しやすいんだ。

面白いね。90年代にはインタラクティブデバッガーをいつも使ってたけど、最近は全然使ってないな。ログを取って、読んで、考える方が…楽だし。

適材適所ってやつだね。もし誰かがprintf()で仕事を終わらせられるなら、それで十分だよ。インタラクティブデバッガーは時間を無駄にするだけで、全然進まないことが多い。使い道はあるけど、そんなに一般的じゃない。GDBの一番の使い道はスタックトレースを調べることかな。自分が作業してるソフトウェアの良いメンタルモデルがあれば、どこで何が間違ったかがわかることが多いし。多くの人がコードをデバッグするのに時間をかけすぎて、書く前に考えることをしないんだよね。あ、テストはデバッグよりも大事だよ。

うん、全然信じてないよ。この調査の方法論は怪しいと思う。

まだ半分も進んでないよ（うちの企業のコードベースがめちゃくちゃで、AIに向いてないから）。でも君のアプローチはなんとなく分かるな。AIを使うと、時々遅くて質が低いこともあるけど、頭の負担が少なくて済むから、時にはそれが価値あるトレードオフになるんだよね。

うん、まだあんまり生産的にはなってないかな。せいぜい10%くらい。でも、精神的なエネルギーがかなり楽になるから、40歳になった今はそれがすごくありがたい。

調査やここでのコメントではタブ補完についてあまり言及されてない気がする。私にとっては、AIがやってる究極のコーディングがそれなんだよね。最近はあまり注目されてないけど。大量のLOC（とコメント！）があって、そこでAIがすごく生産的だと感じる。

100%だね。私の指示はいつも結構具体的で、「X秒ごとにデータを取得して、新しいデータがあればYを更新するジェネレーターが欲しい」って感じ。

具体的に何を書いてほしいのか教えてもらえる？ウェブブラウザで要素を実装するのは無理だと思う。C++でWebKitやChromiumの話をしてるんだ。例えば、ブラウザが新しいデータテーブル要素を欲しがっていて、スクロールウィンドウをネイティブに実装して、要素を供給するためのイベントを登録するようなものだとする。そういうコードベースはLLMには複雑すぎる気がする（間違ってるかもしれないけど）。とにかく、もっと具体的な例があると議論が進むと思う。具体的な例を挙げると、最近ChatGPTにMP4ファイルからメタデータを直接パースするJavaScriptを頼んだんだけど（もっとエディタに統合されたものを聞けばよかった）、TypeScriptをくれて、mp4boxを見てみるべきだって言われた。15〜20分かけてmp4boxの例を設定したけど（それも聞けばよかった）、結局mp4boxでは欲しいデータが取れなかった。だからChatGPTに戻って、JavaScriptを頼んだら、jsfiddleみたいなところでハッキングしてたから、それがうまくいった！その後、タイトルとコメントのメタデータが欠けてたから、それも欲しいって言ったら、最初の試みでそれも成功したよ。

AIを使うと、入力が少なくなるから、結果的には良いことだと思う。

彼らがやるもう一つのことは、元の記事が言及しているAIのネガティブな部分を便利に無視して、ポジティブな部分だけを報道することだよね。もちろん、これは一つの会社の調査に基づいた元の記事に基づく記事で、元の記事は「コンテンツマーケティングマネージャー」が書いたものだし、調査の生データは公開されてない。結果のマーケティングサマリーだけがあるだけ。信頼性高いね。

コパイロットのオートコンプリートは、ただのオートコンプリートとして見るべきだと思うよ。確か、あれにはもっと劣るけど速いモデルを使ってるみたいだし。AIにはあまり詳しくないけど、コパイロットのチャットやエージェントモード、あとクロード・ソネット4はたまに使ってる。

提案は積極的に生成され、受け入れられなくてもアカウントのクレジットにカウントされる

それはもう違うよ。受け入れた場合にだけカウントされるんだ。個人的には彼らのモデルはあまり良くないけど、コパイロットよりはマシだと思う（コパイロットは遅すぎて使いづらいし）。それと、タブ補完のオプションは、私の知る限りでは、zed/zeta、GitHub Copilot、Supermaven、ローカルモデルがあるね。今のところ他のプロバイダーはないと思うけど、もし間違ってたら嬉しいな。

200ドルのClaude Codeアカウントを使ってみたけど、確かにすごいんだけど、「火をつけて忘れる」ってわけにはいかないね。結構違うスキルが必要になることが多い。エージェントが自動でできることと、追加の指示が必要なことを見極める感覚を養わないといけないよ。完璧な投資を求めるなら、個人的にはSupermavenをおすすめする。オートコンプリートが99%完璧だから。

やあ！代わりに私たちのClaudeコードを試してみることをおすすめするよ。これも君のサブスクリプションに含まれてるからね。これはCLIで、君が遭遇した多くの問題を解決してくれるんだ。ディレクトリ内のコードファイルに直接アクセスするから、もうコピー＆ペーストや結果を解読する必要がないよ。それに、自分でコマンドを実行して、例えばコードをコンパイルしたりテストしたりもできるんだ。

「あなたがそれを間違って持っている」と言いたくはないけど、私も最初は似たような経験をしたよ。最終的には、より良い結果を得るために、どうやって話しかけるかを学んでいくんだ。私がClaude Codeで役立つと思ったのは、大きなことを一気に投げるんじゃなくて、いくつかの小さなタスクを与えると、ずっと良い結果が出るってこと。インタラクティブに（プロンプト、出力、プロンプト、出力…）やってもいいし、ステップをまとめた大きなマークダウンファイルを書くのもアリだよ。

あなたの投稿は、HNで見るAIコーディングに関する投稿の90%を要約していると思うよ。ツールを理解していないし、強みや弱みも分かってない。プロンプトやコンテキスト管理も上手くないのに、強い意見を持っている感じだね。何が得意で、どう使えばいいのか分からなければ、当然混乱した結果になるし、時間を無駄にすることもあるよね。これはAIに夢中な人たちへの批判でもあるんだ（特に「バイブコーダー」と呼ばれる人たちには多いけど、ここではあまり見かけないね）。彼らは、LLMが80%の解決策を一発で出せることと、LLMが80%完成しているという考えを混同しがちなんだよね。実際、パレートの法則はソフトウェア開発にも当てはまるから、難しいのはその20%なんだよ。

俺は30年の経験にちょっと足りないくらいだ。これらのツールを使うことに費やした時間は、他の技術を学ぶよりも多いと思うし、まだ最適な使い方が分からない。最初は時間を節約できなかったけど、しばらく本気で使ってみたら、時間を節約できるようになった。小さなプロジェクトで自分の限界とツールの限界を試して、プロジェクト全体をどうやって進めるか、いつから動かなくなるのか、その理由、どの技術と相性が良いのか、どのくらいのサイズの問題を与えるのが適切か、彼らにできないことを頼んでしまったときにどう認識するか、などを考えた。去年の12月にCursorのエージェントモードを始めて、3月か4月からはClaude Codeを使ってる。サイドプロジェクトにはずっと大きな助けになってるけど、大きなコードベースで成功を収められるようになったのはここ数ヶ月のことだ。これだけの経験があっても、チャットインターフェースから本当に価値を引き出せるかは分からない。彼らには、俺がそのまま受け入れるか拒否するかできる変更を提案してもらう必要がある（ちなみに、これがClaude CodeとCursorの動作方法だよ。書き込みたくないファイルに書き込ませたり、実行したくないコマンドを実行させたりする必要はない）。

これをそこそこ機能させるには、PMやテックリードの役割を担わなきゃいけないから、もはやシニアエンジニアじゃなくなる。でも、半分は機能するって言ってるの？問題は、HNのコメント者の約75%が、自分のアイデンティティを（お辞儀）シニアエンジニアであることに強く結びつけていて、PMやテックリード的な役割を見下していることだ。彼らはそのアイデンティティを失うのを避けるために、AIコードがどれだけ悪いかを延々と書くこともいとわない。状況にぴったりのアップトン・シンクレアの名言があるよ。

似たようなことにたどり着いたよ：* すべてのアイデアをブレインストーミングして、Claudeにそれらのためのドキュメントとコードを書かせる、そしてコードは捨てる * そのドキュメントの内容に基づいて、アーキテクチャとデザイン原則を開発するように頼む * すべての機能を取り入れ、適切にアーキテクチャとデザインを尊重した簡潔な設定仕様書を作成させる * それをしばらく反復して、気に入る状態に持っていく * 設定仕様書の実装計画を書かせる * 設定仕様書に従って実装計画の各フェーズを実装するように頼みながら見守る もともと期待していたよりは少し遅いけど、最終結果の面ではずっと良くなって、テストの確認や実装の微調整、ちょっとした脱線や改善の探求の機会が増えたよ。