ソフトウェアエンジニアリングの基礎が、AIエージェント時代にこそ重要
Software Engineering fundamentals matter more
AIエージェントが「できるかどうか」の壁を越え、ソフトウェア開発の現場で活用が進む一方、著者は「基礎」の重要性を強調する。LLMは推論ではなく予測を行い、人間の知識を圧縮したものに過ぎない。デバッグ容易性、保守性、レイヤリング、合成可能性といったソフトウェアの「継ぎ目」を設計するには、深い思考と経験が必要であり、現在のLLMでは不十分だと論じる。また、プロンプトインジェクションや指示追従の危険性（Simon Willisonの「lethal trifecta」）にも触れ、エンジニアの役割はますます重要になると説く。
LLMは推論するのではなく、予測しているのです。
HNでの議論
235- Alien1Being
AIが生成したコードは、IKEAの家具のようなものだ。
IKEAの家具は、優れたキャビネット製作の要素を多く体現しているが、必須ではない要素は省いている。そして、退屈していたり、無能だったり、落ち込んでいたり、燃え尽きていたり、恨みを抱いていたり、疲れていたり、機嫌が悪い日だったりするキャビネット職人よりも、それを一貫して行う。
将来、AIコードは必然的に、優れたソフトウェアエンジニアリングの実践のほとんどを体現するだろう。そして、退屈していたり、無能だったり、落ち込んでいたり、燃え尽きていたり、恨みを抱いていたり、疲れていたり、機嫌が悪い日だったりするソフトウェアエンジニアよりも、それを一貫して行うだろう。
HNのメッセージや、周りの同僚を見れば、平均的なソフトウェアエンジニアがどれほど凡庸かがわかるだろう。
今日のIKEAは、ほとんどの人にとって十分に良い。
明日のAIコーディングは、ほとんどの企業にとって十分に良いものになるだろう。
高度な技術を持つ職人やソフトウェアエンジニアの必要性を大幅に減らすのに十分なほど良い。
自分をキャビネット職人やシニアソフトウェアエンジニアと呼ぶ人々のスキルを低下させるのに十分なほど良い。最近、私が個人的に知っているキャビネット職人は、プロジェクトビルダー向けの契約キッチンしかやっていない。
しかし、IKEAがそうであるように、AIもまた、特別な要件や好み、資金、または過剰な自己評価を持つハイエンドな分野では、家具職人がまだ存在し、繁栄し続けるのに十分なほど悪い。
おそらく、現在のソフトウェアエンジニアの約1％が、AIコードが必然的に優れたソフトウェアエンジニアリングの実践に従う能力を持つようになった未来に必要とされるだろう。
そして、いつものように、残るのは主に凡庸な人々だろう（あなたにも希望があるということだ）、時折、例外もいるが。
- brabel
> ソフトウェアをデバッグ可能にし、保守可能にし、レイヤー化し、構成可能にすることは、今でもかなりの離れ業だ。その作業の多くには、広範で思慮深い推論が必要だ。そして、そこが今日のLLM、たとえ最先端のモデルの「能力」の最先端であっても、不足している点だ。
私のキャリアを通じての探求は、何が保守可能なソフトウェアなのか、何が構成可能で何がそうでないのか、そしてその2つや他の多くのことがどのように直接対立するのかを理解することだった。単一の答えはない。ここにいる多くの人が望むように、素早く市場を支配することが目標なら、保守性はコードベースの非常に低い優先事項だ。構成可能性は統合者にとって重要かもしれないが、CRUDバックエンドでは完全に無視できる。
さらに、これらの無形の特性のほとんどを測定する良い方法を知らない。非常に有能なソフトウェア開発者でさえ、OOPが良い考えかどうか、全員が純粋関数型プログラミングを使うべきかどうかといった基本的なことでも意見が分かれる。
したがって、LLMがこれをあなたのために解決するのが上手くなることをどう期待するのか？ あなたが受け入れるトレードオフを正確に記述し、それがどれだけうまく機能しているかを測定する方法を与えれば、LLMが不足しないようになるとは思う。現在の状況を考えると、LLMが不足しているか、人間が不足しているかは、単に意見の問題だ。
- mortalapeman
生成されたコードでは、ディレクトリ構造、インターフェース設計、一般的な状態管理が、たいてい場当たり的な混乱状態になる。最高のフロンティアモデルでもだ。しかし、本当に気になるのは、モデルがプロンプトで指定していない前提をしばしば作ろうとすることだ。「これは大変だ、脱出しよう」というエラー状態と「これは致命的ではない」というエラー状態の違いのような微妙なことだ。時々尋ねることもあるが、多くの場合、決定を下すだけで、しばしば間違った決定をする。最終製品を検証するための完全なテストスイートと優れた型チェッカーがなければ、ループ全体は私にとって役に立たず、AIが出力するすべてのコード行をレビューし、巨大なゴミの山を築かないように何年ものアーキテクチャ経験を活用する必要がある。
- mstank
ソフトウェアエンジニアの皆さんに質問です。
コンピューターサイエンスを学んだことはないが、人生の大半で基本的なコードを書いてきた者として（今はAIで加速中）、ソフトウェアエンジニアリングの基礎を学ぶのに最適な場所はどこですか？
- user43928
この記事はここにいる多くの人が聞きたいことを言っているが、私の意見では、核心的な議論は間違っている。
> ソフトウェアをデバッグ可能にし、保守可能にし、レイヤー化し、構成可能にすることは、今でもかなりの離れ業だ
そうでもない。私は何ヶ月もモバイルアプリに取り組んできたが、約2ヶ月前からコードを一目見ることさえやめた。
15万行のコード、その約半分はテストで、AIは私に代わってコードを維持することに何の問題もない。
デバッグ可能か？ 数秒で広範な計測を追加できる。
これには専門知識やプロンプト、TDDの言及は必要ない。それがデフォルトだ。
率直に言って、著者が大規模なコードベースを完全にエージェント任せで、コードをレビューせずに開発しようとしたとは思えない。ここにいる多くの人は、生成されたコードを見て、標準以下だと判断し、実践的に取り組むと思う。
> 彼らは、プロンプトインジェクション攻撃を常に一貫して防ぐことが根本的にできない
AnthropicのAutoモードに関する記事から：
> 私たちは第三者であるTrajectory Labsに評価を依頼し、2026年7月17日時点の最新の公開バージョンのClaude CodeとCodex内のさまざまなモデルをテストしました。彼らは、Anthropicから保持された72の間接プロンプトインジェクションシナリオをテストしました。
> この評価では、Claude Fable 5、Opus 5、Sonnet 5の自動モード実行に対して、720の攻撃試行のうち成功したものはありませんでした。一方、GPT-5.6 SolがCodexのAuto-reviewモードで実行した場合、攻撃の5.83%が成功しました。注目すべきは、これは当社の最新モデルに対する平均攻撃成功率0.09%よりも大きいことです。
- dmitrijbelikov
LLMは新しいExcelだ
- hirvi74
> 昨年、エージェントハーネスは「できるかどうか」のルビコン川を渡った。
兄弟、私はまだ「正しくできるか？」モードだ。私は何を間違えているのだろうか？（修辞的な質問だが、アドバイスは歓迎する）
- erichocean
シナリオ：AIラボがソフトウェア開発用のASIを社内で開発する。ASIはバグのないソフトウェアと人間が読める仕様書を生成する。あまりに信頼性が高いため、会社はコードが仕様と一致することを保証できる。
開発者にトークンを提供する代わりに、完成したソフトウェアを企業に販売する：仕様を入力し、ソフトウェアを出力する。
企業はもはやソフトウェア開発者を雇う必要がない。代わりに、AIラボから、バグがなく、品質が保証された特注ソフトウェアを購入する。
私にはもっともらしいと思える。