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

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

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

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

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

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

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

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

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

誰もあなたのコードの良さに基づいて購入を決めたことはない。全くの間違いだ。 > 一般の人々は、あなたの製品の能力や限界以外には何も気にしない。これも間違い。人々は、製品が好きな理由がコードの良さにあるとは知らないかもしれないけど、バグがほとんどなくて、パフォーマンスが非常に良くて、作業を迅速に助けてくれるソフトウェアが好きなんだ。明らかに、製品の品質に深く関わっている人たちによって作られたもの（バグレポートを実際に読んで、問題をすぐに修正するような人たち）だよね。製品が存在する時間が長くなるほど、コードの品質が重要になってくる。多くの人が「5秒で出せ！」という執着を持っているのは、遅くて簡単なタスクをこなすのにギガバイトのメモリを使うゴミソフトウェアの行列を続けるだけだよ。どちらかの陣営を選ぶ必要はないと思う。ユーザーのために良い製品を作りたいなら、彼らのために作るコードも自分の作品として扱うべきだよ。高品質な仕事に代わるものはないから。

誰も生まれた時からコードの品質に気を使うわけじゃない。人々は、内部の品質（結束性、モジュール性、堅牢性）が外部の品質（正確性、速度、進化可能性）につながることを理解することで、クラフトに気を使うようになるんだ。コードの品質に気を使う人たちは、会社の金で絵を描きたいアーティストじゃない。彼らは、製品を出荷することに深く関わっていて、それが自分や同僚にとって快適な体験になるように気を使う人たちなんだ。そして、次の週には考えずにより良い決定ができるように、今日少し多くのことを考える成熟さも持っている。だから、ローンチの翌日の午前4時に緊急デバッグのために呼ばれるような問題が、本来なら適切に設計されていればあり得ないはずなんだ。 > 誰もあなたのコードの良さに基づいて購入を決めたことはない。通常、彼らは製品の内部を見ることはできないけど、外部から推測することはできる。今年も「雰囲気で作られたクソ製品」と呼ばれる製品をたくさん見てきたけど、オープンソースじゃなくてもね。でも、これはただの事実じゃない。コードの品質は多くの購入決定に影響を与える要素なんだ。オープンソース製品を買うときは、自分のチームがリポジトリをチェックするのが非常に一般的だよ。最初の5分で、適当に作られた明らかな兆候があれば、売上の可能性はかなり下がる。大きな取引では、ソースコードの検査は購入のためではなく投資の決定のためだったけど、緊急のAPI設計をするために個人的に雇われたこともあるよ。そうすれば、その会社が設計したものを持っていて、その設計が良いことを示せるからね。

この考えが繰り返されているのをよく見るけど、私は「コードを作ること」にこだわる人と「製品を作ること」にこだわる人の二項対立は受け入れられないな。私にとって、良いコードを作ることの全てのポイントは、細部に気を使って製品を作ることなんだ。これは切り離せないよ。コードや技術にこだわる人が、細部やデザイン、作り上げるものに対してもすごく気を使っている人に会ったことがない。私が見てきた限りでは、両者は同じ資質の異なる表現だと思う。

AIによるコーディング革命がより良いソフトウェアを生み出していないのは明らかだと思う。実際、今のソフトウェアは以前よりも脆弱に見える。コードの品質は絶対に重要だよね。素人には見えにくい品質だけど、丁寧に作られたプログラムを使うと、その違いを感じるよ。

面白いことに、俺は両方の気持ちがある気がする。時々はコードそのものや、その書き方に夢中になってる。コードが自分のやりたいことにぴったり合うのが見えると、実現するのがすごく楽しみになる。あのものを作りたい！でも他の時は、具体的に達成したいことがあるけど、それを実現するのにかかる時間を考えると憂鬱になる。どうやって実現するかは分かってるけど、どれだけのステップが必要で、どれだけのコンポーネントを作らなきゃいけないかも分かってるから、ただそれが憂鬱なんだ。欲しいものはあるけど、それを作るために時間をかけたくない。最近は、ずっとやりたかったことをたくさん作れてすごく楽しい。時間を正当化できなかったからね。AIに「必要なものを追加して」「以前は時間がもったいなかったエッジケースを処理して」って言う時間もあるし、めちゃくちゃ楽しいよ。だけど、やりたい楽しい部分を書くために立ち止まることもある。自分が楽しいと思う部分だけをコーディングすればいいから、最高だね。

誰もあなたのコードの良さで購入を決めたことなんてないよ。俺が購入を決めるときは、支払いがすぐに正しく通って、購入したものが適切な時間内に届くことを期待してる。これらはすべて、ソフトウェアの信頼性にかかってる。もしユーザーが購入が正しく実行されない匂いを嗅ぎ取ったら、金や商品がどこかに行ってしまったら、それは会社にとって死刑宣告だよ。業界は今、エージェントがあなたの代わりにこれを行うエージェンティックウェブを推進している。でも、基盤がぐちゃぐちゃで、不安定なモデルがその上に乗っかって幻覚を見たりミスをしたりするなら、それはただの大惨事のレシピだと思う。ミッションクリティカルなソフトウェアだけを2)のカテゴリに relegating するのは、日常のサービスにどれだけの信頼性が必要かという現実から逃げてると思う。

私もこの開発を批判的に見ているけど、どうしてAIが最終的に問題を解決できないと考えるの？

これは本当に危機的な状況に向かってると思う。制約やボトルネックの不完全なシステムがあって、主要なボトルネックの一つ、新しいコードを追加するスピードを排除しちゃった。これで他の部分にすごく負担がかかると思う。業界はソフトウェアの複雑さの非線形コストについて、すぐに教訓を得ることになるだろうね。この記事の著者がシンプルさを強調しているのは嬉しい。特に彼らのビジネスの性質を考えるとね。「コードは重要じゃない」って考えを完全に受け入れる人たちは、痛い目にあうことになるよ。長期的には、これを助けるためのツールやモデルの進化がもっと出てくると思うし、すぐに大きな経済的インセンティブも生まれるだろう。でも今は、ダムが決壊したような感じで、本当の影響が現れるのを待ってる状態だね。

プロンプトの履歴も、開発者にプロセスへの信頼を与えるにはあまりにも弱いよね。もっとデザインの改善が必要だと思う。

そうだね、結局はユーザーの操縦（あるいはその欠如）に従うツールに過ぎないんだ。

AIを使わせると、一日中めちゃくちゃなものを生成するよ。良いコードを書くプレッシャーは、実際に出てきたものをレビューして反発する開発者から来なきゃダメだと思う。結局、また別の強化学習の形で車輪を再発明してるだけじゃない？俺はコーディングにLLMの助けを使わないけど、もしずっと「何をどうするか」「何をしないか」「どんな前提を持つか」を教え続けなきゃいけないなら、自分でその作業をやった方が脳を刺激できると思う。個人的には「うん、全部やってくれるよ、ただしどうやってやるか教えればね！」っていう話は根拠がない気がする。最も賢い人間を真似しても、バカを真似できるの？

このサイトのモデレーターが、YC企業の人たちとどうやってHNタイトルを工夫してインタラクションを良くするかを話し合っているなんて、全然考えたことなかった。ほんとにおめでたいな、私。

たとえお金があっても、そんな職場環境（コードベース自体や、その状態に至った文化）を我慢できる才能あるエンジニアを引きつけたり、維持したりするのは難しいかもしれない。彼らはしっかりとしたソフトウェアを作りたいけど、混乱に足を引っ張られているんだ。

特定の分野で最も成功したソフトウェアは、通常は最高のソフトウェアじゃない。この記事の著者たちは、存在しない世界に住んでいるんだ。クリーンコードは、何年も前に負けたよ。

フロー状態でのコーディングはずっと評価されてきたけど、新しい技術に取って代わられちゃったね。脳はエージェント的なコーディングでも「パッとハマる」ことができるけど、もっと高い抽象レベルでやらなきゃいけないかも。もしかしたら「ハマる感覚」が違って、調整が必要になるかもしれないね。

フロー状態でのAIプロンプトもできるんだけど、あんまり話題になってない気がする。