LLMがなくても、ソフトウェア開発は市場の需要や資金によってボトルネックになってきてたよね、コードの不足じゃなくて。 それは市場の需要だけだったと言っても信じられると思う。AIブーム前、マーク・アンドリーセンが言ってた主な不満は「良いアイデアを資金提供するよりも、もっと資本がある」ということだった。個人的には、現実とズレてると思うけど、彼はお金を持ってるけどアイデアがない人だから、信頼できる第一手の情報源だね。

ちょっと脱線するけど…この種の問題は「AIの影響」の見積もりにとても関連してると思う。効率を過大評価する傾向があるよね…それは、私たちにとって重要だったマージンでの中心的な役割のせいだと思う。でも、経済は複雑な方法でボトルネックになっている。市場の需要やお金など、100倍のコードが使えるものだとは明らかじゃない。

コードは正しいことをしているように見えるけど、実際には全く機能しなかったり、通常そのレベルの「仕上がり」ではあり得ないほど壊れていたりする。 それが理解できない。彼らが書いたコードをテストしない（手動でさえ）なら、それはLLMの問題じゃなくてプロセスの問題だよ。彼らは、レビューのためにPRが準備できているとはどういうことかを教わっていない。ここではLLMは関係ない。

中期的には、実際に機能やバグ修正を設計するために労力をかけたことを示すために、作業を上流にシフトする必要があると思う。シニアエンジニアやプロダクトマネージャーが機能をスコープしデザインし、IC開発者（簡単な作業のためのジュニアも含む）がそれを実装し、シニアエンジニアがコードレビューに参加するというメンタルモデルは、常に持っていたものだけど、変える必要があると思う。今のところ、特定の機能をどうデザインすべきか考えられないジュニアエンジニアがチームにいることの価値が見えない。以前はコードベースや新しい技術を理解しようと必死に時間を費やしていたジュニアエンジニアは、その時間を使ってその機能が全体の中でどうフィットするか、エッジケースを考え、機能のデザインを提案することに使うべきだと思う。そういう仕事を任せられないジュニアエンジニアも多いし、正直言って今は雇えるとは思えない。短期的には、プルリクエストが完全であることを確認するために、この追加の注意義務を伝える必要があると思う。そうしないと、作業の非対称性が生まれるし、そのインターンやジュニアがどれだけそれを尊重しているかで評価すべきだと思う。

これは教育の同じ問題に似ていて、評価のために書かれた資料を消費する時間を減らさなければならないという答えになると思う。効果的なコードレビューはもっと継続的になり、チェックインや説明を求めることがもっと必要になるだろう。「あなたのコードを全部読んでフィードバックをあげる」というスタート地点ではなくて。今のテキストの出力速度を考えると、それは持続可能ではない。AIは採用においても同じ問題を引き起こす。知識の見かけを生み出すからだ。私たちがその知識を評価する者として抱える問題は、知識に対する他のインターフェースが言語しかないことだ。ある意味、これは存在する最古の哲学的問題に似ている。ソクラテスは、真実ではなく言語や議論に関心を持つ人々、すなわちソフィストに対して異常なほどの時間を費やしていた。今、私たちはその同じ問題を、産業規模で抱えている。テストについてのあなたの指摘に関しては、最初は自動テストに焦点を当てず（もちろん最終的にはそれを持つべきだけど）、実際にコードを実行しながら説明してもらうことを求めるべきだと思う。それがもっと良いテストになる。「どう機能するのか見せて、説明して。」

大企業でちょっとジュニアなチームを持ってる。みんな「バイブプラン」をすることが多くて、コードを書くよりもそっちが重要だよ。 - プロダクトをもっと考え抜く必要がある。本当に明確にできているか確認して。みんなそれぞれのプロセスがあるけど、ラバーダッキングや批評、作業をフェーズに分けて、それをタスクに分ける感じ（やるべき仕事、ビジネス要件ドキュメント、ドメイン駆動設計、UXライティングのプロダクトレキシコンドキュメント、あらゆる資料） - ツールやフィードバックループの設定を優先すること（コード品質ツールは必須）。計画中に決めたことを強制するためのカスタムルールも含まれる。これに時間をかければ、みんなの生活がずっと良くなるよ。 - すごく詳細な計画を立てて、エージェントが「IVI」する（自動リンティング、単一テスト、テストスイート、手動評価）ことが多い。できるだけ多く、かつ多様な自動フィードバック信号を設定する。 —- 2〜4時間計画と文書化をしてから、「1ストーリーポイント」くらいの小さな「PRD」をたくさん印刷する。完了の明確な定義がある。こうすることで、ジムに行ったり、会議をしたり、1〜2時間手を離しても大丈夫になる。 —-

いいこと言ったね。私も同じような経験があるけど、自分でこのツールを使っている視点からだよ。確かに、今は何千行ものコードを比較的早く生成できるけど、実際にそのコードをレビューして、ちゃんと動くか確認したり、バグを直したり、セキュリティの問題を探したり、リファクタリングしたり、コードを簡素化したり削除したりするのが大変なんだ。自分でコードを書く方が、ずっと生産的だと感じることが多いし、簡単なオートコンプリートのタスクにはLLMを頼る感じかな。経験の浅い人とコミュニケーションを取らなきゃいけない場合、さらにLLMに翻訳する必要があるから、もっと難しくなると思う。こういうツールが生産性を上げてるって言ってる人の大半は、こういったタスクをまるっとスキップしてるか、最初からやる気がないんじゃないかな。そうなると、コードの品質を維持するのは、実際に気にしている少数の人たちに負担がかかることになって、今はその量がすごく増えてる。残念ながら、そういう人たちはしばしば「うるさい人」や「細かいことを気にする人」として見られて、無駄にPRをブロックすることもある。でも、実際にはユーザーに届ける製品を気にしている人たちなんだよね。これを改善する提案はないけど、状況が悪化するだけだという厳しい見通しを持ってる。業界はLLMの使い方だけを学んだソフトウェア開発者で溢れ続けるし、こういうツールを作ってる会社は、同じようなマーケティングの嘘を広め続けるだろうから、盛り上がりを作って、結果的に自分たちの評価を上げるんだ。

なんか面白いね、これが他のML駆動のツールの使い方と似てるのは。例えば、電子工学なんかでは、経験豊富なエンジニアでも理解するのがほぼ不可能な解決策があるし。

• 多くのバグは新しいタイプのもので、コードは正しいことをしているように見えるけど、実際には全く動かないか、あるいはそのレベルの「仕上げ」がされているコードよりもずっと壊れていることが多かった。これを聞いて、以前の雇用主が別の国のチームに契約した25万ドルのソフトウェアプロジェクトを思い出したよ。表面的には、特に仕様書をチェックすれば、すべて揃っているように見えたけど、実際にはまとまりがなかった。彼らは仕様書を超えて一秒もかけず、仕様から「当然に」導かれる常識的なことが全くなかった。結局、そのプロジェクトはすぐに廃棄された。今やLLMを使えば、こういう作業は基本的に無料で自動化できるようになった。