それに、バグだらけのソフトウェアの方がもっとお金を稼ぐんだ。顧客はサブスクリプションを買う理由があるからね。

「完璧なソフトウェアのプラトン的理想」と「32GBのメモリが漏れる」の間には、私たちが目指すべき広いギャップがあるよね。

記事は好きだけど、渋々同意するよ。だからこそ著者がエネルギーの物理的制約を、企業が対処しなければならない未来の壁として挙げてるんだと思う。実際にそれが起こると思う？個人的にはそうなったら嬉しいけど、そうなればこの投稿が最後に勝つことになる（私もね）。でも、企業はこのエネルギー問題をすでに認識してると思うよ。大手テックの資金調達や原子炉、電力網のアップグレードを支持する見出しを検索してみて。

プラトニックな理想なんてないし、常にトレードオフがあるのは完全に同意するけど、利益を最優先するのは良くないってことも無視しちゃダメだよね。

「現実世界」で劣悪な計算機がどれだけの金を稼いだんだろう？

昔なら「重要なものが壊れて顧客やビジネスを失うまで、反対するよ」と言ってたと思うけど、結局みんなCrowdstrikeの事件から普通に過ごしてるよね。あれだけ世界中の重要なサービスを止めて、推定100億ドルの経済的影響があったのに、考え方が変わらないなら、何が変わるんだろうね。

LLMはセキュリティに関する問題、つまり重要なバグを見つけるのが結構得意だから、活用の余地はあると思う。近い将来、コードをLLMでチェックしないのは怠慢だと見なされてもおかしくないよ。今週、状況に迫られて、めちゃくちゃなnginxの設定を整理しなきゃいけなかったんだけど、私の仕事の中心ではないけど、LLMがセキュリティに関連するベストプラクティスに従ってない設定の問題を2つ指摘してくれたんだ（チームが古いリリースを使ってたことも分かったし、ペンテストのフィードバックで1つの問題はすでに修正されてた）。LLMは分析が本当に得意みたい。あまり多くを信じてはいないけど、いくつかのファイルや断片を持ってきて、特定の方向性で反応を求める能力だけでも、私の仕事にとっては革命的だったよ。

冗談でしょ？「商業ソフトウェアエンジニアリング」をどうやって分類するの？$100M以上のARRの会社はカウントされる？生産データベースを削除することがビジネスに与える影響を理解できるでしょ？それに対する答えが「LLMが私たちのランチを奪う」とか「バグは関係ない」って、信じられない。

人々は70年代からニューラルネットワークを開発してきたけど、ソフトウェア開発において役立つための大きな障害が2つあるんだ。1つ目は、ギガバイトからテラバイトのトレーニングデータが必要なこと。2つ目は、出力データのかなりの割合が信頼性が低いこと。この最初の問題は、数十から数百ギガバイトのトレーニングデータを必要とするんだ。この問題は、最近まで達成できなかった遅いけど予測可能な処理能力とデータストレージの増加を必要とするだけでなく、オープンソースソフトウェアが大きく普及したからこそ可能になったんだ。これはAI開発の初期には期待されていたけど、確実なものではなかった。2つ目の問題は、出力がエラーを含む可能性が高いことを意味していて、出力データの重要な手続き処理が必要だけど、それを開発するのはかなりの労力がかかる。ニューラルネットワークによるソフトウェア作成が競争力を持つとは思わなかったよ。効果的なエラー管理のためじゃなくて、ソフトウェア開発の全分野が自分たちの仕事がそんなに下手だってことが理由なんだ（https://xkcd.com/2030/）。

なんで？ソフトウェアの品質が私たちにとって重要じゃないなら、LLMにとっても重要じゃないでしょ。私たちのコードで訓練されてるなら、どうやってそれを理解するの？私たちが与えるプロンプトで動いてるなら、どうしてもっと良いことをするように促すの？

バグは重要だよ。LLMが勝手に私たちの仕事を奪うことはない。バグを利用するために使ってる人間のために働くんだ。

ユーザーベースを確保したら、バグはあんまり重要じゃなくなる。でもそれまではめっちゃ重要。ユーザーを囲い込むための「堀」を作るのがどれだけ簡単かっていうのも考えなきゃいけない。成功すればビジネス的には素晴らしいけど、イノベーションを殺して、ユーザーが技術に対してフラストレーションを感じたり無関心になったりしてる。

一つの顕著な違いは、通常、抽象化レイヤーはパフォーマンス（たいていは記事の著者が考えてるほど悪くはないけど）を、開発者の効率、安全性、一般性、反復速度の向上と引き換えにするってことだね。今のツールは、バグの数や安全性、場合によっては開発者の効率において、逆に悪い結果を出してるように見える。前のツール採用のサイクルと同じように、これらのツールを取り入れることになるかもしれないけど、その違いは注目に値すると思う。

これに関してもう一つ思うのは、テクノロジー業界は自分たちをまだ乗り越えてない唯一の業界かもしれないってこと。コードを書くことは、配管工事と同じようにアートだし、家の配線もアートだし、HVACもアートなんだよね。つまり、満足感はあるけど、企業は長期的な問題が少ない限り、仕事ができればそれでいいと思ってるし、そこを超えては気にしないんだよね。私たちがテクニカルデットって呼ぶものを、電気工はアルミ配線って呼ぶし、配管工は鉛はんだって呼ぶ。いつか、正しいやり方が定まった時（電気や配管、飛行、散髪、他の職業でもそうだったように）、私たちもライセンスが必要な分野になると思う。どの業界も最初は無茶な実験をして、そういう時期は終わるんだよね。

グラフを描くと、たぶんまだ上向きにカーブしてると思うけど、どの時点で（もしそうなら）反対方向に曲がり始めるのかは分からない。ムーアの法則が終わって、これ以上速いマシンが作れなくなった時だと思う。

平均的なソフトウェアの品質が劇的に低下してるのに気づいてないなら、注意を払ってないか、意図的に無視してるよ。この記事は正しい。これは新しい開発者が業界に大量に入ってきたことと、「速く動いて壊す」っていう古典的な考え方が絡んでて、今の「AI」ブームでさらに悪化してる。ジュニア開発者は、もうシニア開発者になるための明確な道がない。ほとんどの人は市場のプレッシャーで「AI」ツールに頼りすぎて、成長が妨げられてる。トラブルシューティングや問題を解決する方法を学ぶことができなくなってるし、最初から問題を起こさない方法も学べない。彼らは「AI」ツールを回すことで得られる以上の洞察や直感、理解、経験を得ることはないだろう。もちろん、中にはこれらのツールを使って本当に学んで、より良い開発者になる人もいるだろうけど、ほとんどの人はそうならないと思う。だから、品質の低下は続く一方で、業界の状態に不満を持つ人が増えて、1983年のようなクラッシュを引き起こすかもしれない。これが「AI」バブルの崩壊と同時に起こるか、別の出来事になるかは分からないけど。

ソフトウェアのアップデートが悪いと思う。ソフトウェアがリリース時に普通に動いていたのが、全く動かなくなった時期だよ。アジャイル管理手法は、実際には存在しない「ウォーターフォール」というリリース方法を作り上げて、ソフトウェアが動くまでリリースしないようにして、技術的負債をほぼゼロにしてしまった。誰かがこれを本当の管理手法に発展させてくれることを願ってる。カニンガムの法則の作者がアジャイルマニフェストの共同署名者だったことを考えると、最初からそういう計画だったんじゃないかと疑ってる。最初は大変だろうけど、業界全体で技術的負債があるから（参考に：https://xkcd.com/2030/）、一度解決すれば、リリースして忘れられる品質のソフトウェアはゲームチェンジャーになるだろう。

人々が払う意志のあるソフトウェアの質は、常に存在してきたし、これからも存在するだろう。

ソフトウェアが悪化したとは思わない、むしろ逆だ。ただ、JavaとOOPは間違いだったね。

今日使ってる製品やソフトウェアの中で、毎日少なくとも2つのバグに遭遇しないものはほとんどないよ。どのウェブサイト、ウェブアプリ、モバイルアプリ、コンソールアプリも、ユーザーに影響を与えるバグが明らかにある。ほとんどのバグが私がそれを診断したり報告したりするのを難しくしてる。毎日15分から30分はバグを回避するのに費やしてるから、普通の生活ができてる。今のソフトウェア文化は全然違う。常に変化し続けることが全てに勝る。モバイルアプリが動作を維持するためにアップグレードを強制してくるのに、2週間も耐えられない。私のKubuntu 24.04 LTSボックスは、LTSのaptリポジトリにいるのを二重チェックしてるのに、常にアップデートが流れてくる。ローリングリリースのディストリビューションは、実際に人々が意図的に使ってるもの（昔は不安定なブランチって呼んでた）。具体的なことを推測することはできるけど、私はソフトウェア開発者じゃないから、これらのチームで何が起こってるかは正確には分からない。でも、昔はこんな風にソフトウェアが作られたり使われたりしてなかった。もっと大人がいて、問題を引き起こすような決定を避けてた気がする。今はその問題を受け入れるか無視する価値観に変わったと思う。（「彼らは潜在的な問題が何かすら知らないほど無知だ」と結論付けるのは避けたいけど、現実的な可能性ではあるね）

例えば、商業ソフトウェア（重要なインフラにおいて）が「kバイトやMバイトのメモリを漏らした」り、恥ずかしい「コンピュータサイエンス101のエラーハンドリング」のミスがあったりすることを想像するのは簡単だよね。億ドルの結果を伴うけど、あなたはそれをうまくまとめたと思うよ…。

20年前は、電話をかけて人間に問題を解決してもらうのが普通だった。もちろん、たくさんのことがうまくいかなかったけど、今は何も作ろうとしないのが問題だよ。明らかに文化的な変化があって、「何も機能しなかったから、試す意味がない」っていうのは俺の記憶とは違う。今は個々の経験が重要じゃない、スケールの確率的な時代にいる。AIがコンピュータを予測可能から予測不可能に変えてるのも、同じ方向に進んでるけど、さらに加速してる。

ウィルスの「リーンソフトウェアへのお願い」を見てみて。1995年のもので、コンピュータがキロバイトで動いていたものにメガバイトのメモリが必要になったことを嘆いてる。

今はギガバイトがあるけど、無限の仮想マシンやアプリで埋め尽くしたいのに、残念ながらそれは不可能だ。肥大化がRAMのサイズと同じくらい速く進んでるから。

20年前もそんなに良くなかった。いや、良かったよ。私もその場にいたから。ほとんどのソフトウェアは、今見てるものよりずっと質が高かった。

いや、そうは思わないな。昔はバグがあるのは大問題だったし、ソフトウェアの品質はもっと高かった。過去に戻ってVMを使って客観的に測定するのも面白いかもしれないけど、個人的には自分の記憶がノスタルジーで曇ってない自信がある。主な理由は、今は常にアップデートできるから。これが競争の計算を変えてる。早く出荷してバグを常に修正する方が、遅く出荷してバグを少なくするより勝つんだよね（市場でも、社内でも「誰が早く出荷する？」って）。物理メディアでソフトウェアを出荷してた頃は、致命的なバグがあるのはすごく大きな問題だったけど、今はそうでもない。

それがどうして良くないの？昔はギガバイトを消費せずにできたのに、今はできないってことは、何かが悪化してるはずだよ。ギガバイトを消費するコストは下がったけど、悪化した状況を我慢できるからって、状況が悪くないわけじゃないからね。

そうだね、言ってる人たちは経験がない若い人たちなんじゃないかな。コンピュータやソフトウェアはずっと不安定だったよ。昔はゲームがプログラムだけじゃなくて、システム全体をクラッシュさせることもあった。それは今でも起こるけど、頻度は減ったかな。

Windows 95からMEの時代にいた人なら、みんな覚えてるよね。突然クラッシュすることが多かった。BSOD（青い画面）、"このプログラムは不正な操作を行いました"、"システムに接続されているデバイスが機能していません"、"Windowsは再起動してレジストリを修復します"、"エクスプローラーがエラーを引き起こしました"... Ctrl+Sは、みんなが最初に覚えたショートカットだったよね。Wordが宿題を台無しにしないように。競合するブラウザのボックスモデルやDHTML、変な共有ホスティングのCGI設定で、ウェブがどれだけ混乱してたかなんて考えたくもないよ。今は楽になったね。

AIに対して怒ってるわけじゃなくて、一貫したコードを作るためのAIに対して怒ってるって感じ。文法チェックや創造的なこと、例えばテキストを書くのにAIを使うのは全然OKだと思うよ。

この記事、上から下まで幻覚のような内容だよ。「3年間ソフトウェアの品質指標を追跡してきた」って言ってるけど、証拠は何も示さず、ただの体験談を並べてるだけ。この記事の事実は一つも信じられない。俺の体験を言うと、2005年にはPHPで作られたウェブアプリを作る能力のない開発者が普通だったし、WordPressやjQueryの理解も薄かった。最近は、技術に対する意識が高まって、ちゃんとしたコードを書くようになってきた。今のプロジェクトは、他のチームから引き継いだ混沌としたものでも、GitやCI/CD、少なくともいくつかのテスト、まともなホスティングインフラが整ってる。RailsやDjango、Nextみたいなちゃんとしたプラットフォームで作られてることが多いし、昔みたいに「SSHでサーバーに入って、壊さないように気をつける」なんてことはないよ。

このテキストのパターンがいろんなところで見かけるようになった。LinkedInでは、フィードがこのパターンに沿った短い文の投稿で溢れてる。さらに、返信も明らかにAI生成だよ。

それは鋭い観察だね！指摘してくれてありがとう！私たちは消費するためにここにいるんじゃなくて、批判的に評価するためにいるんだ。ざっと見るんじゃなくて、理解するためにね。人間が時間とともにAIの言葉をどのように取り入れてきたかを示すチャートを作ってほしい？

うん、記事の最初の方は「怒りのブログ」みたいに見えるけど、最後の方はほとんどAxiosの記事みたいで、箇条書きと「賢い」見出しばっかりで、なんか妙に型にはまってる感じがする。あと、「The」の見出しが多いのはどういうこと？AIっぽい匂いがするね。

うん、#5の記事にはガツンとやられた。AI検出器はゆっくり温まってたけど、「今日の本当のチェーン: React → Electron → Chromium → Docker → Kubernetes → VM → 管理DB → APIゲートウェイ。」のところで反応した。確かに、これらは全部技術だけど、アプリとサービスのバックエンドが全部使うかもしれないけど、チェーンの「リンク」が隣り合うときに必ずしも意味があるわけじゃないし、これを人間が書くとは思えない。文字通り読むと、誰かが理由もなくKubernetesを使ってElectronアプリをデプロイしてることを示唆してるよ。本当にクライアントサーバーアーキテクチャを伝えたかったら、サーバーサイドのものとElectronアプリの間のリンクとしてAPIゲートウェイを挙げるはずだし、ElectronをChromiumの上流に置くと思う。

私はずっとこんな風に話してるし、他の人もそうだと思うよ。

AIに対するバッシングが、あやふやなヒューリスティックから始まるのがめっちゃ面白い。エムダッシュを使うのが好きな人間として書いてるけど、今はその癖に気をつけなきゃいけない。みんなAIを見つけ出そうと必死だからね。クリシェな文章は確かに良くないけど、なんだかんだで、何かしらの形でそれを打破できてるのは嬉しいかな。

よく使われるフレーズを避けるのが疲れてきた！ LLMは使ってないけど。

番号付きリストはAIの匂いがするね。

みんなAI生成のテキストに過剰反応しすぎな気がする。確かに悪いけど、悪い文章は昔からあったしね。古い作品のほとんどは消えてしまって（ありがたいことに）、チョーサーやシェイクスピアの作品だけが残ってるんだ。

もっと言いたいことがあるけど、投稿の大部分はツイートをつなぎ合わせたみたいな感じで、あまりにも雑だと思う。それに、最初の図は何なの？そのグラフの軸は何を示してるの？「崩壊」の「症状」として「Calculator」、「Replit AI」、「AI Code」が挙げられてるけど、何それ？後半では「私たちの研究によると」って言ってるけど、著者は他のコンテンツミルの引用を信じてるの？それが研究なの？私たちの文章の品質基準はもっと高くあるべきだよ。経験豊富な開発者がLLMの出力をうまくキュレーションできるのと同じように、経験の浅いライターがLLMにうまく書いてもらえるとは限らない。

記事はLLMが書いたか、手助けしたみたいだね。品質についての記事なのに、著者がこんなことを確認してないのは皮肉だね。

なるほど。つまり、君もヒースローのターミナル2にいたってこと？

どうしてこんなに明らかに製品化の準備ができていないものが出荷されるなんてあり得るの？ 最近のソフトウェア品質の基準は、「顧客が訴えたり拒否したりしない程度の最低限の品質を保つこと」みたいだね。本当に底辺だよ。すべてが急いでいて、リリースの決定は会社が請求したお金を保持できるかどうかの可能性に基づいている。プロジェクトが必要な利益を上げられるなら、品質の悪さによる大量のエンドユーザーの拒否を考慮しても、ソフトウェアはリリースされるんだ。