LLMがなくても、ソフトウェア開発は市場の需要や資金によってボトルネックになってきてたよね。コードの不足じゃなくて。今のツールはすごくパワフルで、プログラミングそのものは二の次になってる。業界が始まった頃とは全然違うよ。ビル・ゲイツの話で、彼がコードを書く能力がすごく貴重だった頃のことがあるんだけど、ある会社がプログラマーを切実に探してて、彼とポール・アレンをティーンエイジャーの時に雇ったんだ。「だから、彼らはペナルティを払ってた…彼らは『子供だから気にしない』って言ってたんだよね。で、僕はそこに行ったんだけど、16歳だけど見た目は13歳くらいだった。彼らは僕たちを雇って、給料も払ってくれた。すごく面白いプロジェクトだったよ…僕がどれだけ早くコードを書けるかに彼らは驚いてた。」この話は、どれだけ変わったかを思い出させてくれるね。昔はコードを書くことがボトルネックだったけど、今は「どう作るか？」から「何を作るべきか、ビジネスになるのか？」に問題が移ってるんだ。

そうだよね、みんな知ってることだよ。LLMは現実的にレビューできないような悪いコードをたくさん書くし、ジュニアから提出されたコードが全然意味不明なこともあった。なんでそうしたのか聞くと、「わからない、LLMがやったから」とか言うし。新しいトレンドは、メンテナンスにたくさんのノイズとオーバーヘッドを生んでるだけだよ。LLMを受け入れるなら、レビューやメンテナンスにもLLMを使うしかないけど、そうするとややこしいスパゲッティになるだろうね。でも、重要なのはほとんどのビジネスにとって、品質はあまり重要じゃないってこと。使い捨てのLLMコードで十分だし、もしそれがダメなら、必要だと思うまでLLMを追加すればいいんだ。

最近の例としては、若くて野心的だけど経験のないインターンを指導していることがある。彼らは、以前は1週間（または2週間）で書いていたのと同じ量のコードを1日で作り出したんだ。でも、いくつかのことが僕の仕事を以前よりも難しくした。 - レビュー中、彼らは自分のコードについて深く考えていなかったから、僕のコメントがしばしば彼らの頭を超えてしまった。議論の代わりに「いい指摘、直すね」みたいな返事が来ることが多かった（これもLLMを思い出させる）。 - 些細な問題にかける時間がほとんどゼロに近くなって、残りの問題はもっと微妙で、見つけて説明するのに時間がかかるものになった。 - 多くのバグは新しい種類のもので、コードは正しいことをしているように見えるけど、実際には全く機能しなかったり、通常そのレベルの「仕上がり」ではあり得ないほど壊れていたりする。パターンマッチングの崩壊が「オーガニック」なコードと比べて、オーバーヘッドを大きくした。何十年もコードをレビューしたり、Stack Overflowの質問に答えたりしてきた経験があれば、バグだけでなく、著者がどうやってそこにたどり着いたのか、そして今後同じことを避けるためにどう助けるかを特定することができる。 - 簡単だけど悪い（非効率的、間違ってる、違法、見た目が悪い…）解決策は話し合うのに良いけど、LLMを使ったジュニア開発者は、もっと複雑なものを作り出すことが多くて、いろんな面で悪いことになることがある。少し壊れたPRを徐々に成長させて、デザインや他の考慮事項を考えながら、最終レビューの準備が整うまで高品質にするという文化は、同じようには機能しない。 - 元のPRの問題を直す代わりに、最初のレビューに対する返事として全く異なるアプローチが来ることが多かった。また、しばしば新しく微妙な方法で壊れていた。これが、シニア開発者がジュニアの著者よりもこれらのPRにずっと多くの時間を費やすような努力の逆転を引き起こした。ジュニア開発者は（おそらく）もっと生産的で有能だと感じるだろうけど、彼らの仕事に対する反応は、最終的にはシニア開発者からの通常の熱意や励ましが欠けてしまうことが多い。こういう問題にどう対処すればいいんだろう？最初にうまくいったのは、常に多くの（合格する）テストを要求することだったけど、結局これらのテストも同じような問題に悩まされることになる。

プロの環境では、100%同意するよ、ノートもいらない。LLMが私を最も助けてくれたのは、実はサイドプロジェクトなんだ。そこでは、コードを書くことが絶対的なボトルネックで、ちょっとしたアプリを作るために必要な時間を確保できない（いや、実際にはやりたくないのが本音だけど）んだ。

著者には反対だな。ビッグテックや企業の視点から見ると、コードはボトルネックではなかったかもしれない。でも、スタートアップの視点から見ると、厳密な計画が必要だった。リソースが限られているから、機能を生み出すのがボトルネックになっていたんだ。小さなチームでは調整のオーバーヘッドがないし、アイデアやビジョンが明確だから、すでに話し合って合意したものを作るのが簡単なんだ。私の考えとしては、AIやLLMの有用性のような広いテーマを議論する時は、一般化しない方がいいと思う。コードはある人にとってはボトルネックだったけど、他の人にはそうじゃなかった。

コーディングを学んだとき、何かを動かすためにはすごく努力が必要だった。スペルミスを直した後にすぐに動くコードを書くことができるようになるまで、何年もかかったよ。今は、何をやっているのか全く分からない同僚がいるけど、AIが動くコードを提供してくれる…その間に、コーディングの基準や言語、フレームワークが私が追いつく暇もないほど早く変わっていく。私はいつもシンプルで、理解しやすく、変更や削除、書き直しが簡単なコードが好きだった。そういうコードを書くことや扱うことは本当に満足感がある。でも、誰もコードなんて気にしないよね。むしろ、ほとんどの人が評価しない残酷な抽象芸術のようなものだ。

CSSを書くのとプロっぽいデザインを考えるのが大きなボトルネックだったんだ。今はそのタスクをLLMに任せてる。最近、クライアントのプロジェクトに取り組み始めたんだけど、フロントエンドのUIを作るためにデザイナーを雇う予定だったんだ。そしたら、GeminiがすごくいいUIを生成できることがわかった。デザイナーにデザインを提供してもらうのを待たなくて済むから、時間をかなり節約できてる。コスト削減も嬉しいしね。コーディングはまだボトルネックだけど、クライアントはコードを書くのにまだ私の助けが必要なんだ。将来的には、プログラマーじゃない人も自分でプロダクトを作れるようになるはず。

ちょっと興味深いのは、これとは逆のこと。次の10年で何が勝つのか？私の意見では、ユーザーの期待が今やすごく高いから、ウェブサイトやアプリ、認証、決済統合、カスタマーサポートのフォーラムやチャットを作る必要があるんだ。これはビジネスを前に進めるための足がかりを作るため。技術的じゃない人にとっては、これが問題になるのがわかる。誰もそんなことをやるために人を雇おうとは思わないし、すごく高くつくからね。AIはエンジニアのためのものじゃなくて、コードを理解していない人たちにとっての「十分良い」ものなんだ。お金がどこに投資されるか、消費者が何を好むかにも大きく依存する。今のAIコーディングの波は、効率を改善しようと他の領域に変わっていくと思うよ。

今朝、この問題について「いやだ」と枕に向かって何度も言って目が覚めた。進む道は二つある。 - 私たちのようにLLMにコードを小分けに生成させて、それを脳が速く分析して処理できるようにするけど、LLMはますます良いコードを生成するように最適化されてきてるから、時間の無駄に思える。「LLMは数ヶ月後にそれを書き直すだけだし。」 - それとも、私たちの中には仕事を失う人もいて、コードはよく考えられているように見えるけど、実際はそうじゃないという悪い状況に陥る。ここ数ヶ月、成功したケースもあれば、重要なものでは美しいクソに頭を抱えたこともあって、私の態度は揺れ動いてきた。経験は（多すぎるくらい）あるし、未来を考慮した「十分良い」明確なコードの組み合わせでやってきた。人を信じることとシナリオを疑うことも大事だと思ってる。でも、この状況は私を疲弊させてる。開発者たちは、指導できないものに指導されていて、でもそれが実際には必要ない。私が解雇されたら、二つの道のうちの一つか両方を選ぶことになるだろう。1. LLMを使い続けて、家族を養って bills を払う何かを作り出せることを願う。そしてまた別の仕事に就いて解雇される。2. 理由を必要としない手作業の仕事をする。遅くて信頼できない神経発達の人を受け入れてくれる仕事があればいいけど、実際にはそんなのはないと思う。私は以前に #2 に近いところまで行ったことがある。大切なものはほとんどが自分の機能に依存していることを学んだ。神様に頼ることはできるけど、それ以上は自分次第なんだ。そして、これらのLLMやその後に続くものは同じことをするけど、他の人の人生の穴を埋めることはできない。たとえ私がクソみたいな人間でもね。だから、LLMは私たちの無意味な欲望やニーズを解き明かしながら、謎めいたコードを書いているのかもしれない。私たちが仕事を失うかもしれないし、ゆっくりとそれなりのコードを作り続けるかもしれない。それはどうでもいいことだ。大事なのは、自分自身でいること、そしてベストを尽くすこと。

私はビジネスソフトウェアの開発に携わってる。すごく重要な側面は要件の収集と定義だと思う。これには、ビジネスユーザーとのコミュニケーションが含まれていて、彼らの問題やニーズを理解することが求められる。そして、実際のソフトウェアがそれを解決しているかどうかを確認することもね。これらすべてには、ドメイン知識、コミュニケーション、調整スキルが必要なんだ。