为什么编程问题尚未解决：LLM 在生产软件中的局限性

TL;DR – 编程问题尚未解决

LLM 生成的代码可以加快开发速度，但软件的大部分成本在于非功能性需求 (NFR)，例如可靠性、安全性和可扩展性。生产级系统仍然需要人类工程师来理解、验证代码并对其负责；AI 无法承担责任。

1. 核心论点：代码生成 ≠ 解决工程问题

创建成本低，维护成本高。 作者指出，虽然 LLM 降低了编写代码的成本，但大部分运营支出来自于大规模维护和运行软件。
非功能性需求占主导地位。 NFR（安全性、可靠性、性能、合规性）很少能通过原始的 LLM 输出得到解决，需要深厚的领域专业知识。
逻辑和容量限制。 LLM 在处理大上下文、逻辑一致性和确定性行为方面存在困难。它们的随机性意味着它们可能生成语法正确但仍包含细微错误的代码。
问责制缺口。 AI 无法受到惩罚、罚款或承担法律责任。法律和组织责任仍然由发布软件的人类承担。

“你无法对你无法控制的事情负责。这种理解对于推断系统行为并在 AI 不可避免地失败时进行修复至关重要。” – Alex Ewerlöf

2. 作者强调的现实风险

风险领域	LLM 的不足之处
医疗、金融、航空、国防	错误可能导致生命损失或引发法律处罚；AI 缺乏所需的严格验证流程。
安全	LLM 可能引入隐藏漏洞；它们无法像人类编写的代码那样进行审计。
可扩展性	性能回归通常只在负载下出现；LLM 无法预见所有边缘情况的交互。
法律责任	不存在让 LLM 承担责任的机制；组织必须承担责任。

3. LLM 目前在编程中的工作方式

提示词 → 模型 – 开发人员提供自然语言规范。
生成 → 框架 – 模型生成代码，并将其输入到运行编译器、代码检查器和测试套件的框架中。
反馈循环 – 错误被反馈给模型（通常通过思维链或工具调用），直到代码通过基本检查。
人工审查 – 理想情况下，开发人员会检查差异、验证 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。
投资于框架和自动化测试。 稳健的反馈循环（编译器 → 测试套件 → 模型）是捕获确定性故障的唯一途径。
保持明确的所有权。 三支柱模型——知识、授权、问责——必须由人类工程师掌握，特别是在受监管的领域。
警惕 AI 过度依赖。 限制令牌预算生成，避免大规模 PR，并保持个人编码实践以防止技能退化。
调整激励机制。 公司应现实地为 AI 生成的服务定价；在使用廉价 AI 的同时对“人类水平”的质量收取高价会侵蚀信任。

6. 未来展望

模型改进（更大的上下文窗口、更好的推理能力）将减少但不会消除逻辑差距。
领域特定代理（例如专注于安全的 LLM）可能会弥补一些 NFR 差距，但它们仍然需要人工监督。
监管压力可能会增加，要求在高风险行业中对 AI 生成的代码进行审计追踪和问责。
技能演变 – 工程师将越来越多地成为提示词工程师、AI 编排者和质量守护者，而不是纯粹的编码员。

7. 结论

虽然 LLM 极大地降低了代码创建的门槛，但软件工程的基本挑战——维护可靠性、确保安全性和承担责任——仍然没有解决。HN 的讨论反映了一种分裂的观点：一些人看到了开发人员角色的近期转变，另一些人则认为作者低估了当前模型的能力。无论立场如何，共识是明确的：对于生产级软件，人类的专业知识仍然是不可或缺的。