得られる効果は指示の質やインタラクションの構造、出力に対する注意の払う量に比例して指数関数的に増える。 俺もそう思う。多くの人が良い結果が出ないと落胆するけど、良い結果を得るためにはAIエージェントとのインタラクションの仕方を学ぶ必要があるんだよね。これは使えば使うほど上達するスキルだと思う。それに、AIツールの中には特定のユースケースに対して優れているものもあるから、自分のやっていることに合ったものを見つける必要があるよ。やっと理解できたとき、これらのツールからどれだけの価値を引き出せるかに気づくと、もう戻れなくなるよ。

さらに、学習曲線やスキルの限界が人々が思っているよりもずっと高いってこともあるよね。それに、Claude Opusを厳密なエージェントの枠組みで動かすのと、ブラウザでGPT-4oに聞いてコピペするのでは、結果が全然違うからね。

前にもコメントしたけど、俺はHN基準では比較的懐疑的な立場にいる「意見のアービトラージ」みたいな感じで、実際には職場での利用をもっと推進してるんだ。実際、Claudeが終わるのを待ちながらこれを打ってるし。俺が懐疑的なのは、彼らが売り込まれているものと実際にやっていることとの間にギャップがあるからなんだ。すべてのAIソリューション、特にエージェントは、経験豊富な人の指導がなければ実質的に無価値なんだよね。実際には「自律的」なものなんてほとんどない。あの「バイブコーディング」という言葉を作った人が、舞台で「馬車を馬の前に置いている」って言ったのもその通りだよ！彼らが素晴らしいツールであることは間違いないけど、かなり制約が必要だってことを省略するのは、実質的に嘘だと思う。

この数ヶ月で、俺も同じ結論に強く至ったよ。実は以前はAIに関してネガティブなコメントをしてたんだ。AIが限界に達するって話があるけど、最新のツールは大幅に改善されてる。今では、以前は数週間かかってたことを数時間でこなせるようになったよ。もちろん、プロンプトを考えたり、細かく分解したり、AIをIDEと上手く統合したりする必要があるけどね。一番の成果は、新しいフレームワークやライブラリに出会ったときだよ。従来は「新しいライブラリや言語、フレームワークの使い方のコードサンプルを探して、それを自分のタスクに合わせて加工する」ってサイクルを経てたけど、AIはこれが得意で、時には本当に驚かされる。「あれ、ライブラリにはXを達成するもっと簡単な方法があったんだ！」まだ懐疑的な人には、もう一度試してみる時だと思う。

俺たちの仲間の多く（ほとんど？）がAIコーディングに対してすごく懐疑的なんだよね（それともただ無関心なのかな）。 俺はほとんどの開発者がコーディングの際にAIを積極的に使っていることを願ってるよ。ここ6ヶ月は生のプログラミングスキルが中堅か上級レベルに達したように見えるし、才能と愚かさの間には面白いほどのばらつきがある。声高に主張するプログラマーたちは、将来の見通しに恐れを抱いているかもしれないし、彼らと話し合う余地はあまりないから、放っておくしかないんじゃないかな。

この投稿は俺にとって興味深かった。俺もプログラミングの経験が豊富だけど、高校の「ハント・ザ・ワンプス」以外はゲームをプログラムしたことがないし、最近新しいゲームのためにAIを使い始めたんだ。AIは俺にとって三つのことになった。(1) 学習ツール。実際に素晴らしいのは、正しい用語がわからないときに俺の質問を理解してくれること。これのおかげで、答えの出発点を得られるんだ。それに、未知の未知を明らかにしてくれるのが本当に素晴らしい。これが俺にとって一番重要なことかもしれない。(2) 面倒なことや退屈なことをやるためのツール。俺ができるけど時間がかかることをやってくれる。コードのコメントや、通常は自分で編集する設定ファイル、他のテキストベースの冒険など、いろんなことに対して十分に役立つことがわかった。(3) 検索。これも(1)と同じで、俺が本当に求めていることを理解しているから、実際に何と呼ばれているかは関係ない。俺はそれにフィルタリングさせたり、提案をさせたりしてる。考えさせることもできるけど…なんでそうするの？君の方が賢いから。単に速くて、より多くのことを知っているだけなんだ。君の脳のCPUに対するFPUみたいなもんだね。

特定のレバレッジの違いは、今まで出会ったどの「10倍」ツールよりも10倍だよ。だから、どのツールもそうだけど、特にね。私にとっての一番の比較は言語かな。昔の「lisp [または他の言語]はもっと早く、もっと多くのことができる」ってアイデアだけど、面白いひねりがあって、書くコードを減らせるけど、生成されたコードは速くて高性能な言語で、SBCLのために型注釈をあちこちに追加する余分な作業なしで済む。だけど、生成されたコードの中には、特定の作業のために確認が難しい部分があって、そこをしっかりダブルチェックしないといけないっていう落とし穴もある。もちろん、表現力豊かな言語は、計画がしっかりしていない人たちによって、メンテナンスが難しいコードベースがたくさん作られる結果にもなってるから、そういうのはまだまだたくさん出てくると思う。でも、私にとっての本当の、さらに大きな勝利は、100%新しいコードを書く時間が少なくて、古いコードと新しいコードを統合したり、古いコードを改善したりするのに時間をかけるよりも、デバッグが超強化されること。デバッガーは、いろんなことに対してprint文を使うよりも大きな改善だよ。コードのブロックをコピー＆ペーストして、「出力が[これ]じゃなくて[あれ]みたいに見えるんだけど、何が起こってるの？」って言えるマシンがあって、すぐに一般的に良い提案をくれる新しい目を持ってるのは、他の多くのことにとっても大きな改善だよ。特にデバッガーをつけにくいタイプのもの（SQLや「コードとしてのインフラ」、ビルドスクリプトなど）に関してはね。

AndroidでChromeを動かしてるけど、バブルがポップしないんだ。カウントはゼロのまま。PRは受け付けてる？

これについても聞きたいな—OPはCursorでAugment Code使ったの？それってどうやって機能するの？何が得られるの？両方にお金払ってるの？

ボードゲーム「Just One」のためにシンプルな静的HTMLゲームを作ろうとしたんだけど、テキストボックスに単語を入力すると、スマホの全画面に表示される仕組みなんだ。でも、入力中にテキストボックスが動き回るバグがあって、試した4つのLLMではどれも直せなかった。どれだけプロンプトを出してもダメだったよ。みんながどうやって一発でゲームを作れるのか、テキストボックスが画面で動き回るのすら止められないのに :(

AIコーディングでうまくいくのは、やりたいことをしっかり考えて、数百の小さな問題に分けることだよ。 私に合ってるテクニックは、AIに基本的な機能やゲームプレイを一発で作らせて、それを基に何度も改良していくこと。最初の一発はすぐに印象的であるべきで、そうじゃなければ捨てて、プロンプトを修正して再挑戦するまで。

偶然にも、それは昔ながらのアプリ開発の成功とも強く関連しているみたいだね。

「バイブコーディングの成功ストーリー」についての投稿がたくさんあるけど、どこでその「たくさんの投稿」を見たの？そんな具体的な主張をする真剣な人を見たことがないよ。 > 何をしたいのかをしっかり理解して、それを数百の小さな問題に分けて、重要な部分に具体的なアーキテクチャの指針を持つこと。これが、CGPTプレビュー以来LLMボットを使ってきた方法で、すごく役立っていて、生産性が100倍になった。問題は、実際に構築する方法を知らない人たちの間にあるみたいで、完璧なオラクルを求めてランプの精霊のような存在を期待して、実際の作業に対して怒っている。ここ数年で学んだのは、ほとんどのエンジニアが実際には機能的に悪いエンジニアで、成功するプロジェクトを一から終わらせるために必要な知識の1/1000しか知らないってこと。私の仮定は、実際に一緒に働いた悪いエンジニアたちが、実際には良いエンジニアの大きなグループの偶然のサンプルだと思っていたんだ（実際に数年の間に良いエンジニアとも働いてきたけど）。でも、実際にはそれはほんの少数派で（他の分野と同じように）、ほとんどの人は自分のやっていることがあまり得意じゃないんだ。

AIコーディングで最も効果的なのは、何をしたいのかをしっかり理解し、それを数百の小さな問題に分け、重要な部分に具体的なアーキテクチャの指針を持つこと。 テックリードとして、時々プロダクトオーナーの役割もやっているけど、これは人間でも同じようにやるべきだよ。私の仕事の少なくとも70%は、経営者の「タイムトラベルタワーゲーム。バグなし。」を、みんながチームで作業できるように、強いアーキテクチャのビジョンを持った長いプロンプトのシリーズに翻訳することなんだ。お互いの足を引っ張らないように、適切な抽象度でね。

一番うまくいくのは、最初の機能を手動でコーディングして、コードベース自体が自己文書化された存在になることだね。そしたら、残りは雰囲気でコーディングできる。未来の機能は最初の機能から十分なパターンが定義されるから（スキーマ、フォルダ構造、モジュール、ビュー、コンポーネントなど）、明示的な雰囲気コーディングのルールをほとんど定義する必要がなくなるよ。

これはゲームジャムのエントリーで、締切が1週間だったから、最初の2〜3日はかなり急いで作業してたんだ。だから、最初のコミットがめっちゃ大きくなっちゃった。プロンプトもその場でメモしてなかったし、ゲームが完成した後に使ったツールのチャット履歴を遡って、全てのプロンプトをPROMPTS.mdファイルにコピーしたんだ。プロジェクトの進行を追いたいなら、プロンプトファイルを上から下まで読むのが一番いいよ。例えば、EnergySystem.tsファイルは、敵の経路探索やスポーン、タワーの射撃が終わった直後に作成されたもので、AIが「エネルギーサブシステムを実装したい」というプロンプトを使ってゼロから作ったんだ。

私の経験では、Claude SonnetはClaude Opusよりもずっと冗長で、その結果としてコードも悪くなる。両方を同じタスクで使ってみると、その違いはかなり明確だよ。