ハッカソン最終日、Lovableで開発が崩壊した理由
Explaining to business people why building software is still hard
ハッカソンでLovableを使い、初日に90%完成した「HoneyCrew」が2日目に突然崩壊。無限のバグと遅延にチームは混乱した。非技術者にソフトウェア開発の難しさを伝えるため、著者は家のリノベーションを例に挙げる。既存の家を壊して建て直す方が安いという請負業者の言葉が、ソフトウェアの根本的な複雑さを象徴している。
「おすすめしません。古すぎます。壊してゼロから建てた方がずっと簡単で安上がりです」。彼は優秀なソフトウェアエンジニアになれたかもしれない。
HNでの議論
54- dasil003
ソフトウェアはすべて経路依存的であり、コードはすべて負債であり、技術的な意思決定はすべてトレードオフだ。これはソフトウェアの不変の真理であり、AIやその前のいかなるムーアの法則の進歩によっても一片たりとも変わっていない。
自分が本当に何を求めているのかを真剣に考え抜き、新しいフィードバックや学びが入ってきたら自分の前提を見直すという困難な作業を、できないか、やろうとしないプロダクトマネージャーや意思決定者が多すぎる。同様に、顧客や目の前の問題から遠く離れ、自分自身の頭の中にある「良いソフトウェア」のプラトン的理想を追い求め、今本当に必要なものと将来必要になると予想されるものとの厳しいトレードオフから乖離してしまうエンジニアも多すぎる。今この問題を解くために書くソフトウェアは少なければ少ないほどよく、一方通行のドアになる決定は最小限に抑え、「スケーリング」の課題はできるだけ先送りにして、より完全な情報をもとに決定を下す方がよい。
これこそが、AGIがソフトウェア開発を魔法のように解決することはない理由だ。なぜなら、人は実際に試してみるまで自分が何を求めているのか本当には分からず、試した途端に別のものを求めるからだ。生の知能では、目的や人間の目標を解くことはできない。賢くなればなるほど、それは悪意あるジーニーや猿の手のようになり、愚かな人間のプロンプト入力者が望むことを決してきちんとやってくれなくなる。
- tripleee
これはすべて、ソフトウェアにおける品質の目的を誰も理解していないことが原因だ
低品質 = バグや問題が連鎖し、イテレーションや機能の追加・変更が遅くなる
これは人間が書いたコードにもAIが書いたコードにもまったく同じように当てはまる
それなのに、まるでコード品質が、人々が「おお」「ああ」と感嘆するためだけに存在する、完璧にインデントされた「美しいコード」にすぎないかのように、みんながコード品質を放棄してしまっている
- miranaproarrow
私のマネージャーは、Claude designでウェブアプリ全体をバイブコーディングした。それがなぜまだ本番環境に対応していないのか、理解するのに苦労している。
私の仕事は、それを私たちのバックエンドデータに配線することだが、こうした配線の多くは、私が実際に中に入って機能についてちゃんと考えることを要求する。これには時間がかかるし、Claudeでこのプロセスを速める方法を、私はまだ見つけられていない。
- digitallogic
> 1階分の予算しかないけれど、大家族で、数年後には2階も欲しくなることは分かっている。
> 2階を支えるためのインフラを今追加する方が、実際に2階が欲しくなったときよりもずっと安く済む。
この考え方の問題は、未来についての確実性を前提としていることだ。今の方がずっと安いのは、そのものが必要になる場合に限った話だ。必要にならなければ、時間と金をドブに捨てたことになる。
このたとえが弱くなると思うのは、大家族が欲しいかどうかの確実性は、新しい製品ラインが大きな普及を見せるかどうかよりも、おそらくはるかに高いということだ。
- mehagar
たとえコードを書くのにAIツールを使ったとしても、あるレベルでは、あらゆる可能な入力に対してプログラムの出力がどうなるべきかを指定しなければならない。
プロンプトで物事をゆるく指定するだけでは、AIツールがあらゆる可能な入力に対して生成すべき「正しい」出力を知るのに十分なコンテキストがまったく足りない。そもそも何が「正しい」かは多くの場合主観的だ（「このボタンは赤にすべきか青にすべきか？」）。