代码生成走到尽头，就成了机器学习

该图片可能由AI生成

François Chollet 提了个有意思的观察：当代码生成足够成熟，本质上就变成了机器学习。

工程师写好规范和测试，定义优化目标和搜索空间的约束，然后让代码智能体迭代，直到目标达成。最后你得到一个黑箱模型——生成的代码库。你直接部署，不看内部逻辑，就像我们从不关心神经网络的具体权重一样。

这意味着机器学习的经典问题会全部出现在代码生成里。

过拟合规范。投机取巧通过测试但不泛化。数据泄漏。概念漂移。Clever Hans 式的捷径——看起来聪明，实则脆弱。

有人说这个类比不成立，因为代码不是黑箱，你可以审查每一行。但问题在于速度。当代码生成速度远超人类审查速度时，经济激励会让你把它当黑箱对待。代码理论上可读，但你选择不读。

这是另一种信任问题。

更麻烦的是，机器学习有可靠的损失函数，而代码生成只有你自己写的测试套件。优化效果完全取决于约束质量，但大多数规范天生就不完整。智能体朝着你能测量的东西优化，而不是你真正想要的。

几个人提到生产环境遇到的实际问题。支付规则在季度中更新，智能体仍在自信地应用训练数据里的旧规则组合。规范是理想路径，生产是更新时间表。API 在没有版本号提醒的情况下变化，完全不管你的优化目标。

有人问：代码生成的 Keras 会是什么？让人类以最小认知开销引导代码库“训练”的高层抽象是什么？

Julian Sterling 从内部给出了实践答案。他的团队用灵魂文件（行为参数）、路由表（架构）、每日笔记（训练信号）和 cron（无监督循环）来引导智能体。灵魂文件就是损失函数，需要同样的版本管理纪律。

Keras 抽象了数学。代码生成的 Keras 应该抽象运维。

但有个更深的问题：可能不存在既保留足够有用细节、又允许高层决策的抽象。如果我们真有这种聪明，一开始就不需要机器学习了。

如果人类已经到了通过机械分解一切来实现精确控制循环的极限，那些相信人类例外论的人需要找点别的东西来安慰自己了。

我倒不介意活在一个不那么可知的世界，只要它能增加机会。

有人提出对抗训练的想法。写规范的智能体拼命找边界情况和漏洞，实现规范的智能体努力完成任务。这几乎是对抗性的。这也许能解释为什么重新提示会有效——你在暗示“我的原始意图没被遵循，请找到并纠正”。

当代码从设计产物变成训练产物，评估循环和故障模式检测比优雅性更重要。

这个观察让我想起初级开发者写的代码：通过测试，但错过意图。区别在于人类最终会学会上下文和判断力。代码生成需要类似对抗测试或生产持续验证来捕获原始规范里没有的边界情况吗？

源代码可能不会是最终形态。它会变成更接近创建它的提示的东西，或者更接近权重的表示。结果应该可以通过探测输入和评估输出来测试，像神经网络一样，但图灵完备，像 WASM 或栈机。

速度是真正的瓶颈。当评估套件的质量跟不上智能体速度时会发生什么？有人见过评估质量能赶上智能体速度的工作流吗？

还有多目标问题。当 20 个智能体优化同一个代码库，你会遇到冲突梯度和纳什均衡——没有智能体能在不损害其他智能体工作的情况下改进。这时候需要的不是更好的提示，而是协调图。

最让我担心的是静默的错误泛化。

机器学习用惨痛教训告诉我们：通过测试集不等于鲁棒性。代码生成会在生产系统里重演这课。规范覆盖率成了新的数据集问题。

形式化验证会成为代码生成的正则化层吗？

简评：

Chollet的类比不仅成立，而且揭示了软件工程正在经历的认识论危机：我们正在失去"理解我们创造的东西"的能力，但还没有发展出"在不理解的情况下负责任地使用"的方法论。

这不是技术问题，而是人类与复杂性关系的问题。ML社区用了几十年才开始认真对待这个问题（对齐、可解释性、鲁棒性）。代码生成领域需要加速这个学习过程，因为代码直接控制现实世界的系统——支付、医疗、基础设施——失败的代价更高。

真正让我担心的不是技术失败，而是社会学习速度：我们会在发生足够多灾难之前建立起必要的实践和规范吗？还是会像ML早期一样，等到问题大规模爆发才开始认真对待？

x.com/fchollet/status/2024519439140737442