うん、この記事はちょっと単純化しすぎだと思った。私は共有所有のコードベースで働いてるけど、時には自分のブランチで作業してるときに元の著者に連絡できないこともある。少なくともパートナーがいろんなことを説明してくれるのはすごく助かる。もしかしたらOPは人間がいない世界を想像してるのかもしれないけど、人間がいないっていうのは、私たちのチームが時々直面する現実の問題だよ。

なんで100%の正確さが常に必要なんだろう？前にも言ったけど、もう一度言うね：反AI派の人たち、AIユーザーじゃなくて、AIが魔法の万能薬だと思ってる人たちが多い。なんか、論理エラーを捕まえられないから静的型付けに反対する人たちを思い出す。

こんにちは、著者です。コメントありがとう。最初のポイントには同意するよ。AIが将来的にそのギャップを埋めるかもしれないけど、その頃にはかなりのダメージがすでに発生してると思う。LLMの推論の記憶についてだけど、将来的に解決できたとしても、元の生成に関連するアーティファクトを失ったコードがすでにあるんだ。全体的に、AIが「常に学習している」とか言われてるけど、新しいモデルがリリースされるまで実際には何も新しいことを学んでないと思う。> なんで100%の正確さが常に必要なんだろう？人間は常に100%正確じゃないのに、私たちは彼らにコードを任せてるよね。確かにそうだけど、人間がコードを書くことはバスファクターが0になるわけじゃないから、問題が何かを理解して対処するのが簡単だよね。もし上記の他のギャップが解決されれば、これも部分的に解消されると思う。

過去にレガシーコードベースを掘り下げているときに、AIツールがあればよかったな。「そのperlファイルの著者に聞けばいいじゃん」。確かに、最後に編集されたのは97年で、著者は今や地域マネージャーだし、会議を予約すればいいのかな…？

私の予想？AI企業は、開発者やそのマネージャーを引きつけるために無料プランと月額20ドルプランを維持すると思う。月額200ドルのプランも用意して、より大きなコンテキストウィンドウで、より大きなコードベースで効果的に作業できるようにするんじゃないかな。でも、大規模なプロジェクトを持つ企業は、いずれもっと大きなコンテキストウィンドウが必要になるから、それが突然年間20万ドル/開発者のサブスクリプションになると思う。「組織的知識」とコンテキストウィンドウの間には、かなりの相関関係があると思う。

この記事はコードだけからどれだけ意図を読み取れるかを過小評価してると思う。それはスケールに関係してるね。私はArduinoのコードを読むのにほとんど困ったことがない。でも、一般的なArduinoの限界は32kBの（コンパイルされた）コードだから、数週間から数ヶ月の努力が必要だったり、場合によっては不可能だったりする。数カ国語で書かれた100以上の相互依存するマイクロサービスがあるプラットフォームを理解するのは、私にはかなり大変だ。もしかしたら、そのすべてに非常に熟練した経験豊富なアーキテクトがいて、包括的なAPIスタイルやドキュメントを要求していたのかもしれない。でも、もしそれが全部バイブコーディングで、私に責任を押し付けられたら？私はやめるよ。

記事は、コードだけからどれだけ意図を読み取れるかを過小評価してると思う。コメントがなくてもね。確かに、人間の思考プロセスは、どのように物事を進めるかのいくつかの可能性に埋め込まれるけど、それでもプロセスだし、知識のある人がいるのとは比べ物にならないくらい劣ってる。リバースエンジニアリングは、これまで必要な時にしか行われてこなかった。（まあ、特にレガシーコードベースではみんなやってるけど、生産性には全然良くない。） > 人間（そしてLLMも、統計的に人間の成果を合成してるから、強くそう思う）って結構予測可能だよね。括弧内には同意できないな。それがLLMコードの一番の特徴だと思う：コードには確かに意図が埋め込まれてるけど、それは色んな意図がごちゃ混ぜになってる。小さなスニペットからはあまり推測できないよ。そのスニペットの意図は、全く別の元のコードベースに関連してた可能性が高いから。それがLLMを育てるための堆肥の山になってるんだ。LLMのコードベースを理解するのは実際には難しい。意図が読者を混乱させるから。テキストと同じように、生成されたものが人間が書いたものと同じ意味だと暗黙のうちに思い込んじゃうけど、そうじゃないんだよね。

中間的なアプローチもあって、AIにPRレビューを生成させて、それを手動でレビューするっていう方法もあるよね。だから、君が出した2分のコード（実際にはCCを使うと5〜10分くらいかかるけど）をレビューするのにさらに1時間か3時間かかるし、マージする前に5〜10回のコミットが必要になるかもしれない。私は10,000〜20,000行、約100ファイルのプロジェクトでこれを成功させたことがあるけど、完全にLLM生成で、私のフィードバックもたくさん入れてて、うまくいってるよ。実装する機能の4/5は、私が提供した仕様にかなり近い形で実現できてるし、作業の大部分はリファクタリングだね。でも、うまくいかない時は、一日がかりになることもある。全体的には、たぶん3〜5倍のスピードアップにはなってると思う。ただ、もっと大きなプロジェクトでやるのはちょっと自信がないかな…そうなると、モジュールに分ける方が魅力的に見えてくる。

LLMを使って未レビューのコードを大量に出力してるなら、それは間違ってるよ。 > ばむ、数日分の作業が2分で終わった。 これはちょっと誤解を招く表現だね。なぜなら、その2分にはレビューにかかる時間が含まれてないし（実際にはその時間を大幅に超える）、そうなると最初の段落で言ってる「間違ってる」状況に陥ることになるから。

• 複雑すぎて賢い正規表現では対応できない大規模なコードベースに対して、繰り返しの変更を適用したいなら、ばむ、今まで絶対にやろうとしなかった作業が2分で終わると思う。 君は無邪気にそう思うかもしれないし、私もそう思ったけど、いくつかの有名なモデルでテストした結果、最終的にはどれも「怠惰」になって、時には無関係な変更を加えたり、コンテキストが溜まるにつれて悪化していく。小さなトイ例では完璧にこなすけど、より多くのコードにスケールアップして繰り返しの変更が必要になると、エラーが積み重なっていく。エージェンティックループは状況を改善するけど、そうなると2分で終わるわけじゃなくて、何ができてないかを見つけるためにレビューしなきゃいけないし、終わるまでN回やり直しを指示しなきゃいけない。LLMに変更を加えるプログラムを書かせる方が、ずっと信頼性が高いよ。

スキャフォールディングは、LLMが素晴らしく機能するもう一つの分野だね。フレームワークXYZを使って新しいプロジェクトを作りたいんだけど、どうやってセットアップするかは覚えてない。だって、一度しかやったことないから。クラスをフレームワークから継承する方法も分からないし、通常は同じプロジェクト内の別のクラスからコピーするだけだから。ボットにスタートコードを書いてもらって、そこから進めればいいだけなんだ。悲しいことに、多くのユースケースではLLMは全く必要ない。こんなことにLLMが必要なの？コード例のデータベースをダウンロードして、サイドバーに表示される検索エンジンに接続して、「新しいプロジェクトXYZ」や「新しいクラスXYZ.foo」と入力すれば必要なスニペットが見つかるのに。多くのNPMフレームワークには新しいプロジェクトを始めるためのセットアップスクリプトがあるけど、その後はほぼGoogleを使わざるを得ない。ローカルファイル検索で簡単に解決できる問題がこれほど長い間無視されていて、唯一の解決策が非効率的なものになっているのは本当におかしいよね。

私のお気に入りの一つ - データAPIを切り替えたいけど、2つの異なるサービスを移植する時間がないから、ここのドキュメントを見て。バン！終わり。

このアイデアの精神は好きだけど、もっとたくさんあるよね。プロのコーダーやスキルのある人たちが他に選択肢があるって言ってるけど、「技術的に未熟」な人から「初心者コーダー」までのサブ例もたくさんあるじゃん。彼らは今、私たちなしでもできることがいっぱいあるんだよ。「誰かに$100/h払って試してもらう必要がある頭の中のアイデア」から、「ユーザーが3分で使えるものに変わって、仮想だけど存在しない$100/hの人を泣かせる」みたいに。あなたのコメントが言ってるより、役割のテクスチャーはもっと豊かなんだよ。今、何が可能かを知ってしまったら、メンテナンスがどうかなんて誰も気にしないし、それは未来のメンテナンスの心配より1000倍大事だよ。人々はこのステップに到達するまでに何年もかけてきたのに、今は誰かが3分で簡単にやっちゃうんだから。

面白いのは、あなたが挙げたものをソフトウェア開発とはあまり呼べないってこと。 「テストの出発点」を除けば、ほとんどが一つのプログラミング言語やAPIから別のものに翻訳するだけだよ。確かに役に立つけど、「プログラミングの未来」って感じではないね。それに、ほとんどの「基本的な」モデルが得意そうなことばかりだから、「考える」モデルはお金の無駄だと思う。プログラマーの視点から見ると生産性の向上はかなり大きいけど、雇用者の視点からはどれくらいの影響があるのかは分からないな。これって市場投入までの時間を大幅に短縮するのかな？

まだこのアイデアを練ってるところだけど、最近LLMが「最初のものを捨てるのを手伝ってくれてる」感じがするんだ。LLMを使って何かの初動を得て、ほぼ動くまで繰り返し改善して、最後に変なLLM的な部分を容赦なく取り除くって感じ。特に、何もデザインされていない単調な作業では、ただの変換やボイラープレートだからね。

あなたのコメントには賛成だけど、最近私を笑わせてくれたことをシェアしたいな。クラウドにユニットテストを書いてもらったんだけど、レビューしたらちゃんとしてて、実際に私が書いたテスト対象のコードにバグを見つけてくれたんだ。これを指摘したら、クラウドはユニットテストを通すためにバグを修正するんじゃなくて、単に失敗するユニットテストを実行しないことにしたんだよ、笑えるよね！でも、そうだね、LLMは要件やアーキテクチャを定義したり、要件に基づいて仕様を書くのは得意じゃない。コードの外にあまり影響を持たない、コンパクトで小さな要求には強いけどね。

人工知能って、全然賢くないけど、単調で繰り返しのある非クリエイティブなタスクには半分役立つって感じだね。誰がそんなことを思ったんだろう。

著者は、バスファクターが0ということが実際にはどういう意味なのか、そしてそれに至る過程を無視しているように思う。定義の説明は最初にあるけど、知識が失われるだけだよね。バスファクターがゼロでも問題ない会社って、必要な専門知識に対して経済的なメリットを支払う気がないってこと。人間がAIと競争する経済的な需要はゼロだし、AIは得意なことを圧倒的なコスト差でやるから、マーケティングの欺瞞やコミュニケーションの混乱が予測可能な結果を招くんだ。需要と経済的利益がゼロになったらどうなる？最初に知識に投資してもリターンがない。誰もその分野に入らず、誰も学ばない。これはお金を印刷して成り立つ経済にとってかなり危険だよね。今は問題がないかもしれないけど、次の四半期には間違いなく問題が出てくる。キャリア開発のパイプラインは何年もかかるから、ゼロから始めると、時間差を考えるとゼロになるんだ（それは何年もかかる）。経済的なインセンティブがない状態が約2年続くと、優秀な人材を失うことになる。そこからは、10年のデッドラインに向かってゆっくりと進むことになり、その後は壊滅的な損失が発生する。地元のコミュニティカレッジの学長と面白い話をする機会があったんだけど、需要がないからコンピュータサイエンス関連のプログラムのセクション数を減らさざるを得なかったらしい。入門コースでは、18セクションに対して専攻を宣言したのは13人で、ほとんどの学生がAIの懸念やキャリア開発のパイプラインの欠如を理由に挙げていた。プロセスを修正するために、どんなに高い値段を払っても専門知識がないとどうなる？すべてをビジネスから追い出して、半分考える非知覚的な奴隷を使った結果だよ。供給がなければ需要もない。外部の要因で供給が無限になると、需要も生まれない。必要はあっても、需要ではない。これが2022年に始まったことなんだ。優秀な人材が再スキルをしているけど、低い能力の人材も溢れている。経済の基盤をいじると悪いことが起こるし、それは時間差で現れるから、後から反応するのが難しい。何が必要なんだろう？いつかは、戦場でトリアージをしなければならない危機が訪れるだろう。責任者たちは、変化をもたらす可能性があったときにこの話を聞きたがらなかったんだ。

ここには本当に重要なポイントがあって、それを意識することが大事なんだけど、私たちはこのツールやワークフローの終わりにいるわけで、これらの問題は解決できない。

そう、これはまさに金魚の問題だね。必要な仕事が可能な範囲に広がっていくけど、勧められることや良いことではない。私が見た「解決策」は、プロセスにスピードバンプをたくさん置くことだけど、結局みんな怠けて、最後の瞬間に何かを届けるだけで、追加の時間を使って何かを磨くことはない。

バスファクターは確かにLLMの前から問題だったし、実際、これはずっと使われてきた専門用語だよ。TFAが主張しているのは、これまでバスファクターがゼロに向かう傾向がなかったということ。以前は、最悪でも1だったけど（もちろん時にはゼロもあったけど）、今はTFAが言うには、意識しているかどうかに関わらずゼロを目指しているということだね。

マネージャーとして、チームにルールを設けようと思ってるんだ。どのリポジトリのREADMEも、二度と古くなってはいけないっていうルール。すべての開発者がClaude Codeに既存のREADMEを読ませて、現在のコードを理解させて、PRでの変更を読んで、必要に応じてREADMEを更新するのがほぼ trivial であるべきだと思う。これが完璧だとは言わないし、エンジニアがその要約が意味を持つか確認する必要があるのは確かだけど（それは必要だし、最終的には人間が変更に責任を持つからね）、でも、私たち全員がよくやる典型的な怠惰さが、READMEが古くなる理由として排除されるべきだと思う。