让我们谈谈 LLMs
原文链接: Let's talk about LLMs
核心观点：No Silver Bullet
作者基于 Fred Brooks 的经典论文"No Silver Bullet"来分析LLM对软件开发的影响。这是一个非常有深度的视角。
为什么使用"LLM"而不是"AI"
作者认为"AI"是一个模糊且过度重载的术语，容易陷入equivocation（歧义）的争论。当前关于编程和"AI"的争论几乎都可以追溯到大型语言模型的出现。
关键洞见
- 意外困难 vs 本质困难：Brooks将软件开发困难分为两类——本质困难（软件固有的）和意外困难（生产过程中附带的）
- 内存管理是意外困难：手动内存管理是偶然的，不是必然的——很多语言有自动内存管理
- 代码生成只是1/6工作：在"The Mythical Man-Month"中，Brooks建议软件任务中5/6时间用于编码之外的事情
- Rails脚手架20年前就能做到：自动生成整个应用骨架和CRUD处理程序的能力在LLM出现前就存在
- 程序员大部分时间做什么：与想要新软件的人沟通、了解他们想要什么、制定初始规格、分解成适当大小的 pieces、测试原型、准备下一次迭代、审查代码
关于"10x程序员"
"Sackman, Erikson, and Grant的研究显示，在一组有经验的程序员中，最佳和最差表现的比率平均约为10:1，在程序速度和空间测量上为5:1。"
作者指出，即使假设LLM能把编码时间降到零，按照Brooks更宽容的公式，也不会带来数量级的提升——而且这种提升甚至低于 Brooks 认为雇佣优秀人类程序员所能带来的。
关于自动编程的历史观点
作者引用了David Parnas的观点："自动编程一直是使用比程序员当时可用的更高级语言的编程的委婉说法。" Brooks也认为更高级语言本身不能成为银弹——最大的收益来自第一次转变，即从机器的意外复杂性跃升到更抽象的步骤解决陈述。一旦消除了那些意外，其余的就更小了。
结论
LLM在代码生成速度上确实令人印象深刻，但如果不解决软件开发的"本质困难"——规格、设计和测试的概念构建——就不可能带来数量级的生产力提升。这与历史上其他"银弹"技术（高级语言、面向对象等）的预期类似。