為什麼程式設計尚未被解決：LLM 在生產環境軟體中的侷限性

TL;DR – 程式設計尚未被解決

LLM 生成的程式碼可以加速開發，但軟體成本的大部分在於非功能性需求 (NFR)，例如可靠性、安全性和可擴展性。生產級系統仍然需要人類工程師來理解、驗證並對程式碼負責；AI 無法承擔責任。

1. 核心論點：程式碼生成 ≠ 解決工程問題

創造很便宜，維護很昂貴。 作者指出，雖然 LLM 降低了編寫程式碼的成本，但大部分的營運支出來自於大規模維護和操作軟體。
非功能性需求佔主導地位。 NFR（安全性、可靠性、效能、合規性）很少能透過原始的 LLM 輸出解決，並且需要深厚的領域專業知識。
邏輯和容量限制。 LLM 在處理大上下文、邏輯一致性和確定性行為方面存在困難。它們的隨機性意味著它們可能會產生語法正確但仍包含細微錯誤的程式碼。
問責制缺口。 AI 無法受到懲罰、罰款或承擔法律責任。法律和組織責任仍然由發布軟體的人類承擔。

"你無法對你無法控制的事情負責。這種理解對於推論系統行為並在 AI 不可避免地失敗時進行修復至關重要。" – @Alex Ewerlöf

2. 作者強調的現實世界風險

風險領域	為什麼 LLM 不足
醫療、金融、航空、國防	錯誤可能導致生命損失或引發法律處罰；AI 缺乏所需的嚴格驗證流程。
安全性	LLM 可能引入隱藏的漏洞；它們無法像人類編寫的程式碼那樣進行審計。
可擴展性	效能回歸通常只在負載下出現；LLM 無法預測所有邊緣情況的交互作用。
法律責任	不存在讓 LLM 承擔責任的機制；組織必須承擔過錯。

3. LLM 目前在程式設計中的運作方式

提示詞 (Prompt) → 模型 – 開發人員提供自然語言規格。
生成 → 測試工具 (Harness) – 模型產生程式碼，並輸入到執行編譯器、檢查工具 (linter) 和測試套件的 harness 中。
反饋迴圈 – 錯誤會被送回模型（通常透過思維鏈或工具呼叫），直到程式碼通過基本檢查。
人工審查 – 理想情況下，開發人員會檢查差異 (diff)、驗證 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 過量 (AI Overdose) – 幾位評論者（例如 @askonomm, @mywittyname）警告說，過度依賴 AI 可能會侵蝕開發人員的技能，並導致大量、難以審查的 PR。
法律中的問責制 – @hibikir 指出，法律體系已經讓組織對 AI 驅動的損害負責，這與作者關於 AI 無法承擔責任的說法相矛盾。
經濟視角 – @MatrixMan 指出，對於許多小型團隊來說，AI 生成的客製化軟體所節省的成本可能超過了對品質的擔憂。

5. 給工程師和領導者的實踐建議

將 LLM 視為助手，而非替代品。 使用它們來建構程式碼框架、生成樣板程式碼或探索替代方案，但務必驗證 NFR。
投資於測試工具和自動化測試。 強大的反饋迴圈（編譯器 → 測試套件 → 模型）是捕捉確定性錯誤的唯一方法。
保持明確的所有權。 三支柱模型——知識、授權、問責——必須保留在人類工程師手中，特別是在受監管的領域。
注意 AI 過量。 限制代幣預算的生成，避免巨大的 PR，並保持個人程式設計練習以防止技能衰退。
調整激勵措施。 公司應現實地為 AI 生成的服務定價；在使用廉價 AI 的同時對「人類水準」的品質收取高價將會侵蝕信任。

6. 未來展望

模型改進（更大的上下文視窗、更好的推理能力）將減少但不會消除邏輯差距。
領域特定代理（例如專注於安全的 LLM）可能會彌補一些 NFR 差距，但它們仍然需要人類監督。
監管壓力可能會增加，要求高風險領域中 AI 生成的程式碼必須具備審計追蹤和問責制。
技能演進 – 工程師將越來越多地成為提示詞工程師、AI 編排者和品質守護者，而不是純粹的程式設計師。

7. 結論

雖然 LLM 大幅降低了程式碼創作的門檻，但軟體工程的基本挑戰——維護可靠性、確保安全性和承擔責任——仍然未被解決。HN 的討論反映了一種分裂的觀點：有些人看到了開發人員角色的近期轉變，另一些人則認為作者低估了當前模型的能力。無論立場如何，共識很明確：人類專業知識對於生產級軟體仍然是不可或缺的。