いや、LLMはコンパイラみたいな「抽象」じゃないよ。これはクソみたいな話だ。LLMは確率的なトークン生成器に過ぎない。現実で、LLMを使って作ったものでゴミ箱に捨てないものを作った人に会ったことなんて一度もないし、LLMのレシピで焼いたクッキーを食べたことがあるけど、それは本当に不快だった。いや、LLMは良くならないよ。シンギュラリティのクソみたいな話は2010年代から続いてる。LLMはインターネット全体を消費して、まだ役に立たない。残りのデータはどこから来るんだ？高品質なデータを求める人たちからのメールは詐欺ばっかり。人々は、質が高いのは高いから、簡単に盗めるゴミでこれらを訓練したがってるだけなんだよ。ちょっと考えればわかることだ。この楽観的なクソみたいな宣伝は恥ずかしい。

これは間違ったアナロジーだね。LLMは、コンパイラやインタプリタが高水準プログラミング言語を機械命令に実装するのと同じように、自然言語を高水準コードに「コンパイル」するわけじゃない。プログラミング言語や機械言語は、正確であいまいさのない意味論を目指しているから、意味論が実際に正確かどうかや、コンパイラが仕様を実装できていないバグがあるかどうかを話すのが意味を持つんだ。自然言語は、既存のスタックの上にある単なる高いレベルの抽象じゃない。新しいモデルが出たり、既存のモデルを新しいシードで実行したりすると、異なるコードが出てきて、動作も異なることがある。これがコンパイラの動作じゃないんだよ。

これらのツールが大いに役立つのはわかるけど、記事に挙げられている例（「バイブコーディングの匂い」の下）を防ぐことはできないと思うよ。

これじゃ問題を隠すだけだよね。

それは、コミットメッセージが正しく実装されていると仮定しているけど、「このファイルを更新しました」や「バグ修正」みたいなものじゃないってことだね。

具体的にどうやってこれやあれをやるのか、いくつかの例を交えて教えた方がいいね。

これね… 以前、20年の間に何度も買収や名前変更、合併を経た大規模なコードベースに関わったことがあるんだ。辞める頃には、ついにフォーチュン500のグローバル企業の手に渡ってた。必要なAPIコールに合致するコードが見つかることもあったけど、それが2000年代中頃に最後に更新されたもので、実際にはそのタスクの最新のコードじゃない可能性が高かった。でも、特定のクライアントが使うために必要だったから残ってたんだよね。ドキュメントがない似たようなAPIコールもあって、欲しいデータフィールドを返すやつを選ばなきゃいけなかった。

ちゃんとしたCLAUDE.mdを作って、「この部分みたいにコードを書いて、あのレガシー部分みたいなコードは避けて」って書くことができるよ。

でも、その意識が「雰囲気コーダー」に欠けてることが多いんだよね。多くの人は以前はあまりコードを書いてなかったから。

これだね。あらゆる機会に車輪を再発明したり、何かをするための期待される方法を忘れたり無視したり、パターンを混ぜたり、何でもありだね。著者はこれを「バイブコーディング」と呼んでるけど、それはLLMとはあまり関係ないよ。このツールは、急いで何かを終わらせようとしている人や、自分でプロジェクトを構築していない人、経験が足りない人と同じくらいの注意を払っていると思う。特定のチームの特定の人に対するあまりにも微妙でない不満だとしか思えない。「チームの誰もが書かないような方法で書かれている」というのは示唆的だね。この考え方を他の場所に適用するのは非常に注意が必要だ。学術界やアートの世界では、根拠のない指摘がすでに十分あるから。

そういうチームで働いたことあるよ。むしろ、ほとんどそうだった。人間でも機械でも、そういうことをするコードのPRは受け入れないかな。小規模から中規模のプロジェクトで、2～4人の開発者がいる小さめのチームが理想だと思う。クリティカルなソリューションだけど、そういう小さめのプロジェクトが一番いいんだよね。そうすると、開発チームの文化やコンセンサスを築くことができて、品質と納期のバランスが取れる気がする。

誰も、別のモジュールに既にあるユーティリティ関数を実装しようとはしない。これに関しては公平に言うと、私は全く反対するわけじゃないけど、多くの人がユーティリティ関数を再発明するのは、他に存在することを知らないからなんだよね。特に巨大なコードベースでは。これに関しては、PRの中でシニア開発者がコメントすることで大体解決されるけど、その場合、知っている人が1人増えるだけなんだよね。

こういうことは、スピードを重視する職場ではよく起こるんじゃないかな。

彼らはそうだけど、チームにしばらくいるなら、確立されたパターンを見つけて使う方法をもう知っているはずだよ。もし通常なら出さないようなものを提出したら、それは問題だね。

正直言って、こういうことはドキュメントが不十分な大規模なコードベースではよく起こるよね。私は学術研究プロジェクトに関わっていて、ドキュメントには基本的に「コードは自己文書化されている」って書いてあるだけ。CMakeの設定やプロジェクトのビルドについては1、2ページ説明があるけど、内部のクセや期待される規約は自分で理解しないといけない。新しい人が参加すると、よくあることだけど、いろいろと再発明しちゃって、既存の設定を知らないからグローバル設定を変えたりするんだよね。皮肉なことに、コードベースをインデックス化して、特定のことについてLLMに質問するのが一番いい方法だと思う。なぜなら、聞ける人はプロジェクトを去ったか、忙しくて、返事が来るのは1週間後だから。

有能な人はそんなことしないよ。コードはちゃんとしてるのに行動がそうじゃないなら、それはヒントだね。

あなたは著者の主張を見落としてると思う。>「スピードが最も重要な美徳なのか？」もしスピードが最も重要な美徳なら、そういうことが起こるだろう。でもそうじゃないなら、そういうことはずっと少ない頻度で起こる。だって、挙げられた問題は全部技術的負債だから。負債は消えないし、利子がつく。スピードだけが重要なら、出力は指数的に必要だし、その出力で負債を相殺しないといけない。スピードが要素の一つだけど唯一の要素じゃないなら、他の要素と天秤にかける必要がある。負債を賢く引き受けて、払えるときに返すべきだ。でも、ただ負債を抱えて最善を期待する傾向があるように見える。最後に確認したとき、大半の人は負債の扱いがあまり得意じゃなかった。

それで、いつそれを見ることができるのか考えてたんだけど…私の経験から言うと、平凡な開発者がすぐに悪化することもあるよ。理由は、偽の自信を持つことが多いからだけど、主に生産される量が多すぎるから。もっと正確に言うと、AIが生成するコードには明確なアーキテクチャが欠けてると思う。全体の情報フローや単一責任の原則をほとんど無視してるんだ。AIは「安全な」コードを求めるから、問題をキャッチして、結果を返さないことが多い。実際には、呼び出しコードは結果を確認して、プレースホルダーかどうかを見極める必要があるんだ。そうじゃないと例外が発生するから自信を持てない。似たように、問題を避けるためにAIがパラメータを調整することもある。例えば、AIを使って何かを処理するプログラムを設計するとしたら、gather_parameters -> call -> process_resultsの流れになるべきなんだ。呼び出しはパラメータで変なことをしちゃいけない、集める段階で固定されるべきだから。でもAIは「このパラメータが良くないなら、静かに入れ替えて通過させる」みたいな提案をするんだよね。テストも問題が多くて、もっと長い説明が必要になる…

エージェントが利用可能なグローバル関数を説明するクリーンで関連性のあるコンテキストを持っていれば、適切に使う傾向がある。ストップ！エージェントなんて存在しない。エージェントはなくて、入力を受け取って出力を生成する数学的な関数だけだ。LLMを擬人化するのはやめよう。彼らは人間じゃないし、何もできない。重要じゃないように思えるかもしれないけど、私の見解ではそれは根本的なことなんだ。人間は機械じゃないし、その逆も然り。

同意するよ。でも、経験の少ないチームメンバーがLLMを使っている場合、どう対処するかっていう問題があるね。コードレビューは、こういう原則を教えるためにもっと手間がかかる。ほとんどの人はそれを面倒がって、ただ動くソリューションにハンコを押すだけなんだよね。

LLMと非常にジュニアなプログラマーの違いは、ジュニアプログラマーは学んで変わるけど、LLMは変わらないってことだね！プロンプトに指示を多く入れれば入れるほど、忘れられることが増えて、結局「一般的な世界平均」に戻っちゃう。次のプロンプトではまた最初からやり直し…ジュニアプログラマーとは違うよね。

ある程度まで、そんなに手間をかけてクリーンアップしているなら、まだ最適に使えていないかもしれないね。例えば、私たちはLLMにコードベースの共通パターンを分析させて、AIエージェントがコードベースでより良い仕事をするためのドキュメントを書かせたんだ。それを編集して、何度か通してもらった。で、そのドキュメントを要件の一部として提供している。それが大きな違いを生んだよ。テストの構造の仕方や、共通のユーティリティを見つける場所について具体的な指示を書いたりもした。作業をダブルチェックするためのプリコミットフックも書いたしね。何かおかしなことをしているのを見つけたら、それを指示に追加する。今では、85～90%の品質で作業してくれるようになった。人間のレビューと少しの変更は必要だけどね。作ったものがどう動くかは分からないけど、コードをレビューする前に、マーメイドシーケンスダイアグラムを描かせるといいよ。コンテキストが汚染されすぎると、指示をほとんど無視し始めることが分かった。サブエージェントは、すべてのファイルの内容でトップコンテキストを埋めないから、それに対処するのに役立つよ。もう一つのヒントは、PRコメントとしてフィードバックを与えて、gh CLIでそれを読ませること。これ、手動でコードを編集するよりも早いことが多いから。自分が何か別のことをしている間に、彼らは自分の作業をクリーンアップしてくれるよ。

個人的には、LLMはStackOverflowの（かなり良い）代替だと思ってる。質問を投げると、すぐにその質問に対する答えが返ってくる。大抵は、その答えを基に自分のコードを書くことが多い。時々、LLMに関数を生成させて、それを自分のコードで使うこともあるけど、コピー＆ペーストする前にその動作を完全に理解するようにしてる。でも、理解できないプログラミング言語のオープンソースプロジェクトに+400,000行のPRを押し込むことが、自分のキャリアにとって正直で質を重視することよりも有益なのか、時々考えちゃう。多くの会社では、実際のスキルよりも経験年数が優先されるのと同じように。

確かにそうだね。正直言うと、LLMはネットでコードをググってコピーするのと大して変わらないと思う。結局、開発者がそのコードを取って、見直して、ちゃんと動いているか確認するのは自分次第だしね。最後の部分についてだけど、最近50歳に近づいてきて、目が昔ほど良くない。目の疲れを防ぐために、今はやることを20分ごとに区切って、適切な休憩を取らなきゃいけなくなった。そのせいで、時間が一番の要素になってる。LLMは人間の1000倍速くコードを出力できるから、なんとか基本的なことをやらせられれば大きなプラスになる。今は、入力のAoS構造からSIMD用の適切な配列構造を生成するのに忙しくて、Unity C#とLINQを使ってテキストを出力してる（誰でも編集できるようにしたいから、RoslynやT4のルートには行きたくなかった）。クエリは比較的シンプルで、データ要素のリストから正しいエントリーを選んで、必要なフィールドを使って文字列を構築するだけ。でも、それをコピーしたり編集したりするのは、GPTに「これを選んで、あれを除外して、文字列をABCみたいにして」って言うよりもずっと時間がかかる。昨日、AIをHUDとして使うという投稿があったけど、それはすごく納得できる。全能のモデルがプログラム全体を書く必要はなくて、必要なのは小さなスケールで書いたりリファクタリングしたりできるスーパーパワーを持ったアシスタントなんだ。

それに、私はデータモデルを考え出してから「動く」ようになるまで、どんな「コード」を書く前にもそれをやる。やっぱり、明確な指示が必要だよね。でも、それだとバイブコーディングじゃなくなる :)

「ジュニアプログラマー」や「コパイロット」って、場合によってはAIを過大評価しているし、他のケースでは過小評価していると思う。AIは普通の人なら忘れないことを忘れたり、基本的なコーディングミスをすることもある。でも同時に、あることに関しては私よりも優れている（配列を扱うアルゴリズムでのオフバイワンエラーとか）。それに、インターネット上のほとんどのことについて百科事典のような知識を持っている。赤黒木？もちろん。ゲームプログラミングのECSシステム？問題なし、よく使われるライブラリを教えるよ。私はそれを「猟犬」のように考えるようになった。私よりも上手くできることもあるし、小さな隙間や茂みに入るのも得意だ。濡れたり汚れたりするのも気にしないし、獲物の匂いを嗅ぎ分けるのも私より上手い。でも、獲物を仕留めるのは私の役目だし、狩りをリードするのも私であるべきだ。

問題はツールじゃなくて、「コーダー」の雰囲気だよ。彼らはコードを書くように、あまり気にしないんだ。

真剣な質問なんだけど、今Cursorが私の日常業務をスピードアップできるか再評価してるところなんだ。今のところ、微妙なエラー（例えば「:」を「,」に変えるとか）が多くて、あまり効果的じゃない。でも、私が直面している主な問題は、コードベースが大きくて、完全に古くなっている部分や、ひどく書かれた部分があることなんだ。だからAIは最も一般的なパターンを優先するんだけど、それが悪いパターンなんだよね。「からインスピレーションを得る」みたいな基本的な指示を出しても、結局は全体のコードベースから取ってくる（ちなみに、急いでマージされた雰囲気コーディングの出力が悪化させた）。私の理解では、ルールは基本的にプロンプトに直接入れた場合と同じことをするべきなんだけど、それに対する解決策はあるのかな？

CCは、CLAUDE.mdの非常に明確な内容を無視することがよくあるし、私だけじゃないって知ってる。コンパクトにしたり新しい会話を始めたりするサイクルは、同じ望ましくない行動のシシフォス的なスパイラルのように感じるし、その解決策を見つけるのにかなりの努力をしても、満足のいくものはまだ見つかってない。この記事を表面的な反AIの反応として片付けるのはフェアじゃないと思う。あなたが説明している解決策は、決して完璧じゃないよ。