LLM 只会写代码，却解决不了软件开发的真正难题

快速阅读：LLM 确实能飞速写出代码，但它解决的只是“偶然复杂性”。软件开发的真正硬核挑战在于设计、规格说明与测试，这些“本质复杂性”无法通过堆砌 Token 来消除。盲目追求生成速度而不夯实工程基础，只会导致交付不稳定的泥潭。

作者声明：该图片由AI生成

有人觉得 LLM 正在重塑编程范式，认为它不仅写得快，甚至能比人更快地进行研究和测试。但这种乐观情绪里藏着一个逻辑漏洞：如果编程的瓶颈只是“打字速度”或“语法细节”，那 LLM 确实是神；可如果瓶颈在于如何定义一个复杂的系统，那 LLM 只是个跑得极快的打字员。

Fred Brooks 在《No Silver Bullet》里把开发难度拆成了两类：本质复杂性（软件本身的逻辑架构）和偶然复杂性（比如内存管理、语法错误）。LLM 极大地抹平了后者，但这就像是在给手术室换了更快的缝合针，并不能改变手术本身需要精准判断的本质。

有网友提到，现在的趋势是把 LLM 接入 Agentic workflow，让它去调试、去验证。这听起来很美，但现实很骨感。DORA 的报告和 CircleCI 的数据都指向了一个尴尬的真相：AI 确实提高了吞吐量，却也带来了交付不稳定性。代码写得越快，引入的回归错误和安全漏洞就越多。如果你的评审队列（Review Queue）处理速度没变，只是往里面塞了更多由 AI 生成的“代码垃圾”，那整体效率不仅没升，反而会被无穷无尽的调试工作拖垮。

更有意思的是关于“编程民主化”的争论。如果一个完全不懂编程的人靠“自然语言”指挥 LLM，他极有可能造出一个看起来完美、实则漏洞百出的系统。这种“看起来能用”的幻觉最危险，因为它在用户意识到风险之前，可能已经泄露了所有敏感数据。

与其担心被时代抛弃而盲目拥抱 Agent 浪潮，不如回去把版本控制、测试套件和持续集成这些“老古董”练好。如果未来真的出现了能解决本质复杂性的银弹，那些守住工程底线的人，才会是第一批驾驭它的人。

现在的软件开发，到底是进入了加速期，还是仅仅进入了更快的混乱期？

b-list.org/weblog/2026/apr/09/llms/