なぜコーディングは「解決」されていないのか：本番環境ソフトウェアにおけるLLMの限界

TL;DR – コーディングは解決されていない

LLMが生成するコードは開発を加速させますが、ソフトウェアのコストの大半は、信頼性、セキュリティ、スケーラビリティといった非機能要件（NFR）にあります。本番環境レベルのシステムでは、依然として人間のエンジニアがコードを理解し、検証し、責任を負う必要があります。AIは責任を負うことができないからです。

1. 中心となる議論：コード生成 ≠ 解決されたエンジニアリング

作成は安価だが、保守は高価である。 著者は、LLMによってコードを書くコストは下がったものの、運用コストの大部分はソフトウェアを大規模に保守・運用することから生じると指摘しています。
非機能要件が支配的である。 セキュリティ、信頼性、パフォーマンス、コンプライアンスといったNFRは、LLMの生の出力ではほとんど対処できず、深いドメイン知識を必要とします。
論理と量の限界。 LLMは、大きなコンテキスト、論理的な一貫性、決定論的な動作に苦労します。その確率的な性質ゆえに、構文的には正しいものの、微妙なバグを含むコードを生成する可能性があります。
説明責任の欠如。 AIは罰せられたり、罰金を科されたり、法的責任を問われたりすることはありません。法的および組織的な責任は、ソフトウェアをリリースする人間に残ります。

「制御できないものに対して責任を負うことはできません。その理解こそが、システムの挙動を推論し、AIが必然的に失敗したときにそれを修正するために不可欠なのです。」 – Alex Ewerlöf

2. 著者が強調する現実世界のリスク

リスク領域	LLMが不十分な理由
医療、金融、航空、防衛	エラーが人命に関わったり法的罰則を招く可能性がある。AIには必要な厳格な検証パイプラインが欠けている。
セキュリティ	LLMは隠れた脆弱性を導入する可能性があり、人間が書いたコードのように監査することができない。
スケーラビリティ	パフォーマンスの低下は負荷がかかって初めて現れることが多く、LLMはすべてのエッジケースの相互作用を予測できない。
法的責任	LLMに責任を負わせる仕組みは存在せず、組織が非難を負うことになる。

3. コーディングにおけるLLMの現在の仕組み

プロンプト → モデル – 開発者が自然言語で仕様を提供する。
生成 → ハーネス – モデルがコードを生成し、コンパイラ、リンター、テストスイートを実行するハーネスに送られる。
フィードバックループ – コードが基本的なチェックに合格するまで、エラーがモデルに送り返される（多くの場合、Chain-of-Thoughtやツール呼び出しを通じて）。
人間によるレビュー – 理想的には、開発者が差分を検査し、NFRを検証し、承認を行う。

著者は、高リスクなドメインにおいてステップ4は譲れないと強調しています。

4. Hacker Newsでのコミュニティの反応

4.1 同意する意見

@efficax は、LLMは網羅的なテストやファジングを自動化することで信頼性を「強化」できると主張していますが、著者の見解は実際の経験不足に基づいているようだと指摘しています。
@lordnacho は、「小規模なコーディング」（解決済み）と「大規模なコーディング」（未解決）を区別し、アーキテクチャやトレードオフに関する人間の判断の必要性を強調しています。
@mstaoru は、エンジニアがコードを打つのではなくAIを「導く」ことに時間を費やすという新たなベースラインを見ており、これは役割が消滅するのではなく変化しているという著者の主張と一致しています。

4.2 反対する意見

@brainless は、プログラミングの根本的な再発明を予測し、LLMがいずれ現在の言語やフレームワークを置き換えるだろうと示唆しています。
@manny_rat は、日々の業務においてLLM生成コードは最小限のレビューで済み、10倍の生産性向上をもたらしていると報告し、「高リスク」なソフトウェアが一般的であるという前提に疑問を呈しています。
@jpadkins は、多くの社内ツールにおいて、エージェントの出力はすべての正確性基準を満たしており、コードレビューは任意であると主張しています。
@bluegatty は、「論理」に関する批判に反論し、LLMはコンパイラのフィードバックに基づいて効果的に学習されているため、コンパイラにとって完璧なコードを生成する能力が高いと述べています。

4.3 ニュアンスのある観察

AI過剰摂取 – 複数のコメンテーター（@askonomm、@mywittynameなど）は、AIへの過度な依存が開発者のスキルを低下させ、レビューが困難な巨大なPR（プルリクエスト）につながる可能性があると警告しています。
法的な説明責任 – @hibikir は、AIが責任を負えないという著者の主張に反し、法制度はすでにAI主導の損害に対して組織に責任を負わせていると指摘しています。
経済的視点 – @MatrixMan は、AI生成のカスタムソフトウェアによるコスト削減は、多くの小規模チームにとって品質への懸念を上回る可能性があると述べています。

5. エンジニアとリーダーへの実践的なアドバイス

LLMを「代替」ではなく「アシスタント」として扱う。 コードの骨組み作成、ボイラープレート生成、代替案の探索に活用し、NFRは常に検証すること。
ハーネスと自動テストに投資する。 強固なフィードバックループ（コンパイラ → テストスイート → モデル）こそが、決定論的な失敗を捉える唯一の方法です。
明確なオーナーシップを維持する。 知識、権限、説明責任という3本柱は、特に規制の厳しいドメインでは人間のエンジニアが保持しなければなりません。
AI過剰摂取に注意する。 トークン制限のある生成に留め、巨大なPRを避け、スキル低下を防ぐために個人的なコーディングの練習を続けること。
インセンティブを調整する。 企業はAI生成サービスを現実的に価格設定すべきです。安価なAIを使いながら「人間レベル」の品質として過剰請求することは、信頼を損なうことになります。

6. 今後の展望

モデルの改善（コンテキストウィンドウの拡大、推論能力の向上）は、論理的なギャップを縮小させますが、完全には排除しません。
ドメイン特化型エージェント（セキュリティ特化型LLMなど）は、NFRのギャップを埋める可能性がありますが、それでも人間の監視が必要です。
規制圧力は高まる可能性が高く、高リスク分野ではAI生成コードに対する監査証跡と説明責任が義務付けられるでしょう。
スキルの進化 – エンジニアは純粋なコーダーから、プロンプトエンジニア、AIオーケストレーター、品質の守護者へとますます変化していくでしょう。

7. 結論

LLMはコード作成の障壁を劇的に下げましたが、信頼性の維持、セキュリティの確保、説明責任の遂行といったソフトウェアエンジニアリングの本質的な課題は未解決のままです。HNでの議論は、開発者の役割が近い将来変化すると見る層と、著者が現在のモデルの能力を過小評価していると主張する層に分かれています。立場に関わらず、コンセンサスは明確です。本番環境レベルのソフトウェアには、依然として人間の専門知識が不可欠であるということです。