在过去 5 年中，LLM 在软件工程社区引发了巨大动荡，大部分讨论都围绕着一个核心问题：我们这个职业的未来是什么？
一系列具有不同程度人工干预和控制的竞争范式已经出现：一方面是几乎无需人工参与的 agents，最近流行的"vibe coding"理念不鼓励手动修改代码，而是通过 LLM 与代码库交互；实现独立模块或功能的聊天机器人，有时甚至使用代码解释功能运行代码；另一方面是预测用户意图的编码助手，充当"强化版自动完成"。
关于这些模型的极限、实用性和潜力，存在诸多不同观点。一些人相信，这些模型将在前所未有的时间和资源投入下发展到人类水平能力，并将能够自动化构建生产级软件系统；而怀疑者则贬低这些模型，声称其生成的代码平庸且琐碎，无法扩展到任何生产环境。
我并非在此争论模型本身的极限或能力，有比我更优秀的专家具备深厚的理论知识和实践经验。然而，我将论证以下观点。
世界上的每一件软件都必须相对于某种正确性标准而"正确"。在 LLM 出现之前，我们的时间被分配在编写、阅读和验证代码上。有了 LLM，我们能够将代码编写阶段卸载给 LLM，但验证过程无法被卸载，只能被推到不同的层面。
外界有人争论正确性只是一小部分领域的事务，比如火箭或密码学。别搞错，正确性所需的严格程度会变化，但对正确性的要求不会改变。软件总是 为某种目的而创建，无论是消费和转换数据，向用户提供信息，还是允许用户交互并创建新数据。正确性是指创建的软件符合创建者意图的概念，而创建者必须验证这种符合性。
在不太关键的应用和领域中，正确性是一个试验问题。如果我制作一个网站来展示关于我举办的派对的信息，我会检查网站是否显示了我希望的所有相关信息。如果只是和朋友的派对，这样就足够了。如果是工作派对，我除了在电脑上测试外，还会在手机上尝试，甚至可能请几个使用不同设备的朋友检查，确保一切正常。
即使在上述例子中，正确性的重要性也是上下文相关的。随着领域和规模的变化，我们验证正确性的机制也会改变。当我们创建商业应用软件时，会聘请"测试 "（QA）专家来测试程序中的许多路径，以发现意外行为，即所谓的缺陷 。典型公司除了测试 外，还会花费大量时间测试代码，测试的严格程度随用户数量、资金规模、应用领域关键性的变化而变化。小型 SaaS 公司可能只编写一些集成测试来检查特定场景，或为某些组件实现单元测试，而 AWS 则会数学证明每天处理 PB 级数据的 S3 实现的正确性。
那么，基于目前的讨论，LLM 应该能够生成不需要严格正确性的代码库。也许它甚至可以生成测试，或为其编写的代码编写证明，对吗？也许 LLM 真的能从流程中移除人类，作为一组协作的 agents 工作；即使不是现在，也许在未来可以。我在讨论中多次听到这种论点。问题在于，我们没有考虑到代码的可验证性。我们谈论了严格性和规模，但严格性作为领域 LLM 适应性的参数是不够的，我们需要讨论 LLM 生成的代码如何被验证，这也包括测试代码。
让我们退一步思考 UI 编程（主要与前端开发相关）。许多从业者的经验表明，LLM 能够在单个提示中生成整个前端应用程序，甚至基于餐巾纸上的草图。我们看到像 V0 这样的专门工具专注于 UI 生成。然而，它们在其他领域并不那么成功，或至少没有普及。关于这种现象的一个流行观点是，LLM 是在公共代码库上训练的，UI 编程占据这些代码的很大比例。然而，这无法解释为什么 LLM 在 Web 服务器应用程序（主要与后端开发相关）中不那么受欢迎，这些应用可能与 UI 编程同样普遍，甚至在代码中具有更少的多样性和更多的结构。
尽管关于前端和后端流行度差异有一些心理学解释，主要是创建炫酷且令人印象深刻的 UI 比创建能吸引同等注意力的后端更容易，因此关于前后端比较的流行性或可用性的轶事证据不应被赋予太多可信度，我假设 UI 比我们编写代码的任何其他领域都更容易验证。
UI 的验证几乎字面上就是"查看"。当我们查看网页时，我们几乎立即识别出生成的代码与我们的意图之间的偏差，并能向 LLM 提供即时反馈。Web 服务器的验证需要设置一组测试输入，将其发送到服务器，可能创建一些临时状态，并检查输出是否符合我们的预期。事实上，这比尝试更容易编写测试，而编写 UI 测试是一个困扰业界 30 年的长期痛点，至今尚未解决。
上周"vibe coding games"的兴起似乎源于同一根源。生成的游戏虽然令人印象深刻，但其验证可以通过尝试实现。通常在没有持久状态的单服务器上实现，游戏通过降低用户体验或删除导致问题的功能来回避复杂的网络或性能问题，而不是解决这些问题本身。这并非说这不是有效的选择，但这种选择的原因不是因为这些问题不重要，而是因为它们更难验证正确性，需要自定义测试基础设施或领域知识。
回到标题，可验证性是极限。
这是告诉我们什么无法通过 LLM 实现的极限，它无法通过 agent 方法解决。 安全 agent 理论上可以为应用程序添加安全检查，但如果不以打算生成代码的人的身份验证这些检查，它们就是无价值的。测试 agent 可以为程序添加测试，但在我们验证测试是否符合我们的意图之前，测试本身是无意义的。
到目前为止，我通过理论化 LLM 和我们生产软件的方式阐述了我的观点。现在，我应该分享我认为我们应该做什么。
如果可验证性是极限，如果它是使用 LLM 编程的瓶颈，那么自然的问题就是我们如何提高这个极限，我们如何使验证更容易？
我相信我们需要采取的第一步是放弃无限强大和可扩展的软件 agent 意识形态。如果可验证性真的是极限，那么再多的 agents 也无法解决问题。在我看来，我们需要更好的验证工具和界面。例如，与其让程序员阅读 LLM 生成的测试，不如将生成的测试总结为人类可读的格式，当然，总结也存在信息丢失的风险。我们应该更多地依赖声明式随机测试方法，如基于属性的测试，程序员定义一个应该在所有可能输入上成立的谓词，并通过生成随机输入并传递给程序来测试这个谓词。这种方法已在许多领域用于增强程序可靠性，但尚未被软件工程社区广泛采用。这种方法的优点是，拥有一个通用谓词比多个单元测试更容易检查和理解，此外还有增强的测试强度。
我们需要增加讨论正确性时使用的词汇量。我们需要对性能、安全性、可访问性、灵活性有更广泛的理解，以及如何衡量程序的这些质量，以便我们知道在应用程序中寻找什么，并拥有验证这些质量的机制。在当前状态下，正确性通常被归因于功能正确性，主要意味着"输入输出符合预期"，而应用程序的大多数其他期望被归类为"非功能属性"，软件工程社区在很大程度上忽视了正确地衡量和验证它们。
让我用一个预测来总结。 很长时间以来，我一直相信 LLM 不会成为优秀的程序员，即使有进一步改进。在它们在竞赛编程中取得成功后，我的观点发生了转变，也许作为一个改过自新的竞赛程序员，那是我的李世石时刻。我现在，虽然暂时地，相信 LLM 确实可以在所有拥有完美预言机的领域取得成功。
重要的是要理解，这并不意味着 LLM 将成为产生 100x 代码的神，因为实际上软件工程有用的几乎所有领域都没有完美预言机。完美预言机是一种反馈机制，每次都给你"正确/错误"的答案，它们几乎只出现在游戏中，因为现实世界通常没有完美的正确性模型。赢得或输掉一场游戏是完美预言机，创建能在竞赛编程竞赛中通过评判的程序也是如此。
即使是编程中最形式化的方面，用户可以证明代码正确的定理证明器，也不是完美预言机，因为它们无法告诉你是否在证明的中间步骤上走在正确的道路上，只在你的证明正确或遇到困难时提供信息。我希望这个不完美的预言机足以赢得证明这场游戏，LLM 在自动化证明方面会比我们更优秀。如果这一天到来，我们的下一个工作可能是创造新的定理，要求 LLM 生成代码和证明，并将这样的系统安全可靠地扩展到生产级代码库。