「コーディングは解決済み」という幻想を、2つの工学学位を持つベテラン開発者が粉砕
Coding Is Not Solved – Alex Ewerlöf Notes
LLMによるコーディングが「解決済み」という言説に、AIを早期から活用してきたベテラン開発者が異議を唱える。コードの生成は安くなったが、保守性・信頼性・セキュリティといった非機能要件こそがコストの大半を占め、AIは論理や大量のコンテキストを苦手とする。医療や金融など説明責任が求められる分野ではAIに責任を負わせられない。AIの過剰摂取がサービス品質を損なうと警告する。
AIに責任を負わせることはできない。AIは罰を受けることも、苦しむこともない。AIを罰することはできないのだから、決して説明責任を負わせることはできない。
HNでの議論
531- efficax
コードを読んだからといって、コードを理解したことにはならない。ソフトウェアの経験から学んだ教訓の一つは、私はコードを決して理解していなかったということだ。ある動作をすると思い込んでいても、そうではないと分かるまでは気づかない。
LLMが可能にしてくれるのは、こう言えることだ。「このものがどう動作するかのあらゆる方法を洗い出せ。このソフトウェアを実行できる様々な方法を分析し、ファザーを構築し、プロパティテストを構築し、考えうるあらゆるシナリオでこのソフトウェアを実行しろ。完全なトレースを記録しろ。すべての出力を記録しろ。そして各シナリオのバグを分析しろ」。そんなことは手作業ではできない。
もし我々が本気で取り組み、リソースを投入し、時間を割くなら（そしてそれは「以前の半分の時間で済む」と言うだけで実現できるのだが）、ヘルスケア、金融、自動車、防衛、発電所、航空、製造業でLLMによって作られたソフトウェアは、LLMによってさらに信頼性が高く、より良いものにできる……コードを一行も読むことなく。ちなみにLLMは論理がとても得意だ。
とにかく、この記事全体は、実際にはLLMを使ってソフトウェアを作っていないか、しばらく試していない人のように読める。私も2025年には同じように感じていた。私は何十万行もの難しいコードを書いてきた。これを読んでいるあなたは、おそらく私が書いたソフトウェアに触れたことがあるだろう。例えば、しばらくの間、アメリカでデビットカード取引をするたびに触れていたはずだ。私はコードを理解し、品質を気にかけている。だからこそ、コードにLLMを全面的に活用しているのだ。
- askonomm
私が気づいたのは、AIは怠惰で無能な開発者を、より怠惰でより無能にさせるということだ。その結果、製品の品質はより速く、より大きく損なわれる。今や大量のコードが押し出されているため、以前は怠惰で無能な開発者がひどいコードを押し出すのをある程度防いでいたコードレビューは、現実的にそんな量のコードを人間がレビューできるはずもなく、事実上死に体となっている。AIにコードレビューをさせる企業もあるが、まあ……AIにコードを作らせ、AIにコードをレビューさせる……決定論的な結果を期待するなら、ここにある愚かさは分かるだろう。
消費者がより低い品質の製品に適応し、企業が怠惰で無能な開発者の存在を正当化できるようになるのか、それとも消費者が反発し、企業に開発者の質を高めることを強いるのか、時間が経てば分かるだろう。
注：私は毎日AIを使っているし、怠惰で無能でさえなければ、AIで高品質なソフトウェアを作ることは完全に可能だ。
- temp00345
私はこういう記事をほぼ毎日読んでいる。
この記事は1年前に出ていれば100%正しかっただろうし、9ヶ月前なら75%正しく、3ヶ月前なら50%正しく、今ではおそらく25%かそれ以下しか正しくない。
この記事がどこから来ているかは完全に理解できる。私も、30年以上のプログラミング経験が急速に時代遅れになりつつあることを受け入れるのに苦労している。このことで眠れない夜もある。つらい。
でも、最新のモデル（今日時点でOpus 5.5 / Astra 6）をもう一度試してみてほしい。
彼らが何をできるか見て、彼らが生成するコードを読んでみてほしい。
どんな問題領域でも、低レベルのC++でも、高レベルのTypescriptでも、Clojureでも、あるいはこれらの奇妙な組み合わせでも。
遠慮しないで、大きなタスクを与えて、アプリ全体、UIも含めて作らせてみてほしい。
そしてその出力を1年前のOpus 4やgpt-5と比較してみてほしい——当時は、奇妙でバグだらけでない関数を一つ作ることもできなかった。
これがまさに私の問題だ。モデルがすでに非常に優れていることではなく、どれほど速くそこまで良くなったかということだ。
だから、コーディングがまだ解決されていないとしても、それはすぐにそこに到達するだろう。
- thesumofall
著者は、エンタープライズソフトウェアの90%がどれほど退屈で単純か、過小評価していると思う。航空機や発電所を動かしている部分ではない方の話だ。その多くは一夜漬け、ずさんに管理された下請け業者、そしてそもそも低品質な要件（まったく違う本業を持つ人々によって書かれているから）から生まれている。そしてどうだ？そのほとんどは24時間365日、問題なく動いている。LLMはただ、そういうものをさらに増やしてくれる。そしておそらく、もっと良いものになる。
- brainless
私は約30年プログラミングをしている（学生時代も含む）。プロとして18年だ。
誰か教えてくれないか、なぜ40以上のプログラミング言語があり、そのうち人気なのが10程度なのか。そしてそれぞれに約20のフレームワークがある。さらに各言語に人気のライブラリが200ほど加わる。このマトリックスは、それがすべて好みの問題だと気づくまで意味をなさない。
我々エンジニアのほとんどは、プログラミングについて自分自身のメンタルモデルを構築している。我々はみんな正しい。しかしユーザーは気にしない。LLMは、必要に応じてよりハードウェアに近いコードをどんどん生成するために存在する。彼らは座って、あらゆる仕様からグラフを作り、自分たちで開発したASTを使い、必要ならCPU上で実行することもできる。彼らはそれをやるだろう。我々がどれだけ議論しても、それを止められない。
プログラミングは再発明される。現在のソフトウェアの書き方は、もはや問題にすらならないと思う。
- hibikir
> 自分が制御できないものに対して責任を負うことはできない。その理解が、システムの振る舞いを推論し、AIが必然的に失敗したときに修正するための鍵だ。
これは良い前提ではない。法律の世界の至る所で、自分が制御していない、しかし事実上所有しているものに対して責任を負わされる人々がいる。子供を傷つける犬を放したり、逃げ出せる環境に置いたりすれば、どうなるか見てみるといい。
予測不可能な状況で、合理的なガイドラインをはるかに超えて問題が発生する場合、責任を問われないこともある。
だからもちろん、あなたが完全には制御できないはずのAIが行ったこと、あるいはあなたが納品したAIが書いたコードに対して、責任を問われることはありうる。狼の群れを放つとか、子供を傷つけかねない安全でないおもちゃを売るとか、そういうふうに扱うべきだ。前例は至る所にある。
- thefilmore
「コーディングは解決済み」の著者たちより：今日、同僚がClaude Codeを実行しようとしたところ、代わりにBunのヘルプメニューが表示される問題に遭遇した[1]。以前、私がClaude Codeを使ったときには、何度か自分自身をアンインストールした[2]。
- hakunin
LLMが生成したソフトウェアは十分に良いと主張する人々：
何年もコードを書いていない
自分のコードが比喩的に指が6本あることに気づけない！
良いものとは何かに対する基準が低い
品質やNFRを気にしない
Sカーブを理解するのが難しい
antirezのような例外もあるが、多くの声高な楽観主義者にはこれが当てはまると思う。
- lordnacho
これについての私の考え：
- 小規模なコーディングは解決済みだ。現在の状態があり、それを変えたい、そしてどう変えたいか分かっている。例えば、何らかの理由でブロッキングTCPハンドラがあり、それを非同期にしたい。自分でいじることもできるし、LLMに変更させてもいい。
- より大きな意味でのコーディングは決して解決されない。何を作りたいかを決めるには判断力が必要だ。何を作るにしても、決断すべきことがある（誰のために、何のために？）し、それらの決断は時間とともに変わる。LLMはいくつかのデフォルトの決断を代わりにしてくれるし、それで良ければデフォルトが手に入る（POCには最適）。しかし、LLMが何を決めたのかに気づかないことすらある。ある規模になると、それらの決断を見直すのに多くの時間を費やすことになる。しかし今あるのは、決断を変える際の摩擦がかなり低くなったということだ。以前は非常に時間がかかった多くのことを、今はテストできる。
- LLMが確率的であるという点は、言われるほど重要ではない。ジュニア開発者に何かコーディングするよう頼んでも、彼が何を作るかは分からない。おまけに、自分が何かを解決できると確信していても、自分自身でも解決策がどうなるか分からないことがある。もしかしたら、使おうと思っていたライブラリが結局適切でないと分かるかもしれない。最終的に何を使うかは分からないが、何かが問題を解決することは分かっている。問題には複数の解決策があり、どれを見つけるかは必ずしも重要ではない。
- 私はまだ […]
- josephmtummon
記事を読んで、著者に完全に同意したが、コメント欄の反論にも同意している自分に気づいた。
AIコーディングの実践について個人的に矛盾を感じるのは、AIが複雑なタスクさえも完了するのが信じられないほど印象的であることに完全に同意し、少なくともコードを書くことに関しては私よりずっとずっと優れていると言えることだ。
私の問題は、毎回「怠惰な」選択肢を与えてくれ、同じレベルの思考を必要としないことだ。これは完全に開発者である私自身の責任であり、単純な解決策は、LLMが正確に何を生成しているかを学び理解する時間をしっかり取るようにすることだと分かっている。これを試して、理解を深めながら進められるよう別のスキルを設定している。
とはいえ、今日LLMを使わずに何かを実装しようとすると、ずっと時間がかかるが、一度没頭すると、LLMの出力をあれこれ読むことからは決して得られないフロー状態に入れる。そして終わったとき、たとえ自分の解決策が完璧でなくても、はるかに多くを学び、問題に対する自分のコンテキストがずっと良くなっている。通常はその後LLMとレビューできる。これでたいてい、より良い実装、さらに重要なことに、自分が責任を持てる実装になる。
私のような新しい開発者（経験約2年）にとっては、何年も何年も問題解決の経験を積んでいないので、毎日AIツールを置いて問題解決能力を高める時間を確保しないと、[…]