面白い話だけど、ソフトウェアの比喩としてはあまり良くないね。もし、誰でもすぐに安く飛行機を作れる技術があったら、航空工学の経験がない人でも飛ぶのは今よりずっと怖いことになるよ。航空業界の厳しい安全基準やメンテナンス基準には、ちゃんとした理由があるんだ。それを守らなかった場合に何が起こるか、私たちは見てきた。ソフトウェア業界に同じようなガードレールがないのは祝うべきことじゃない。良い開発プラクティスや規範を理解せず、あるいは気にせずに誰でもソフトウェアを作れる技術を解き放つのは、根本的に悪いアイデアだよ。

それから、ソフトウェアにおける「贅沢」が何かについて、みんなが意見が違うんだよね。

ソ連のエンジニアリングは雑じゃなかったよ。頑丈さ、ゆるい公差、シンプルさを考えて設計されてた。よく考えられたデザインだったんだ。同じように、安い目覚まし時計にもロレックスの時計と同じくらいの思考が入ってるか、むしろそれ以上かもしれない。エンジニアたちはただ異なる要求があっただけ。安くて精度の低い部品を信頼性を持って組み合わせるのは大変なんだ。ロレックスは楽だよ、すべての部品が高精度で作られていて、完璧にフィットするから。安い目覚まし時計は、何が出てくるかわからないから、あらゆる可能性の欠陥を考慮しなきゃいけない。予算内でそれ以上のものは得られないし、時計は時間を教えてくれなきゃいけないからね。ソフトウェアにおける平行線は、防御的プログラミングやフォールトトレランスなどだね。皮肉なことに、これはクリティカルなソフトウェアでは一般的な手法で、開発するのが最も高価なソフトウェアなんだ。雑とは真逆だよ。

パフォーマンスは重要じゃないの？もしあなたのAIがO(n)のアルゴリズムを使っているときに、O(log n)の実装があるとしたら？出力は「正しい」ままだよ。

「私に反対する人は、感情的に欠陥があるからだ。」

あなたの意見、特にその正直さには敬意を表するよ。そして同時に、いつかその考え方を持った誰かが書いたプロジェクトを維持しなければならない状況に追い込まれることを願っている。残酷だけど、残念ながら「他人の不幸は蜜の味」って本当にあるから、私も正直でいたい。もう「船を出してから質問する」プロジェクトには年を取りすぎたよ。

だいたい同意だな。AIに関する議論で混乱が生じるのは、「ソフトウェアエンジニアリング」がいろんなことを指すからだと思う。Next.jsのアプリとKubernetesのオペレーター、コンパイラなんかは全然違うしね。僕は、LLMコーディングが存在する前に複雑さの崖を越えたプロジェクトに関わったことがある。すでに長期的なユースケースを持つ顧客がいて、それを壊すわけにはいかないときは、かなり厄介になる。ユースケースは、実質的に改善できない技術的負債のゴルディアスの結び目に支えられているからね。一つのバグの問題じゃなくて、速度や信頼性の完全な崩壊が問題なんだけど、製品は成熟していて、まだ利益を上げているから、放棄して最初からやり直すのは現実的じゃない。技術的負債を急いで取り入れたことで、製品の人気が上がったけど、結局は行き止まりになっちゃった。バランスを取るのは難しいよね。多くのLLM生成プラットフォームも最終的にはこの罠にハマると思うけど、それには何年もかかるだろうね。

雑な技術設計は、バグや体験の不具合、そして不安定さとして現れることが多い。特にウェブサイトみたいなソフトウェアでは、少しの不具合は許容されることがある。セッションは比較的短いし、ユーザーはページをリロードすればいいからね。こういうコードベースの技術的厳密さはあまり高くないけど、まあ大丈夫だよね。でも、マルチプレイヤーゲームのサーバーやドライバーのように、問題に非常に敏感なソフトウェアもある。ここでは技術的厳密さが非常に重要で、一つのミスが壊滅的な結果を招くこともある。こういうソフトウェアには、自分のコードに誇りを持ちたい人が集まるんだ。なぜなら、品質が本当に大事だから。彼らはLLMに脅威を感じていると思う。LLMが彼らを上回るからではなく、LLMが（今のところ）悪い技術設計の決定を下すことで、高い厳密さのソフトウェアが最終的に壊れてしまうから。

これは、人々が「内向的」か「外向的」かで全てを決めるようになった時の話に似てるね。みんながこの極端に単純化された二分法に基づいて人生をどう生きるか決め始めた。コードが良ければ製品も良くなるものがある。ほとんどの製品は信頼性が求められるから、信頼性のあるコードがより良い製品を作るのは理にかなってると思う。それはコード職人であることではなく、良いプロダクトデザイナーであり、業界によっては良いビジネスマンであることでもある。あるいは、業界によっては、悪いコードが人々の生活を壊すことに無頓着でないことでもある。