编码被解决了？软件还没有。

# 编码问题解决了？软件还没。 来源：https://arcplane.ai/journal/software-is-not-solved-yet Claude Code 的创建者 Boris Cherny 在最近的一次演讲（https://www.youtube.com/watch?v=We7BZVKbCVw）中说： > ……在这一点上，可以稳妥地说编码基本已经解决了——至少对于我从事的那种编程而言。 他描述了一个工作流程：Claude Code 编写 100% 的代码，Claude 审查每个拉取请求，而人类仍作为安全与质量检查点。 这句话之所以成立，是因为 AI 编码工具既神奇又令人失望。过去需要一整个下午才能完成的变更，现在几分钟就能得到一个像样的初稿，然后团队可能还要花几小时甚至几天来决定这个变更是否恰当。 如果实现变得如此充裕，为什么构建软件仍然需要这么多时间和精力？ ## 编码并非全部工作 “编码问题已解决”是一个挑衅性的说法。也是一个不完整的说法。 模型仍会产生幻觉，生成的变更仍需审查。但这个说法确实指出了现实：对许多软件团队来说，编写代码已不再是构建软件最慢的部分。 然而，软件开发并未感觉被解决。 因为编码不等于软件开发。 编码将指令转化为实现。它依然重要，也并非完美。但软件开发远不止于此：它将模糊的意图转化为可靠的系统。 无论团队遵循什么流程，在代码存在之前，必须有人理解问题。团队必须缩小范围，直到“完成”意味着具体的东西。 代码存在之后，必须有人证明该变更属于系统，安全地推送它，并持续承担后果。 这就是承诺破灭的地方。实现变得极其快速；而软件开发的其余部分并未消失。 ## 软件开发降低熵 不是物理学意义上的熵。但作为一个隐喻，它感觉挺恰当。 一个新功能通常从一个混乱的请求开始：“我们能添加团队邀请吗？”那时可能还没有实现可供比较。团队仍在弄清请求暗示了哪些产品行为。 产品思维首先减少混乱。也许“团队邀请”只是意味着向现有组织发送一封简单的电子邮件邀请。也许角色分配可以稍后再说。一个模糊的请求变成了一个更窄的赌注。 设计给这个赌注赋予形状。团队决定谁可以发送邀请，现有用户看到什么，以及邀请过期时会发生什么。现在有了提议的行为，而不仅仅是一个产品愿望。 实现将行为转化为真正的变更。代码赋予想法分量，但也给团队带来了新的不信任。下一个问题不再是“我们能构建这个吗？”而是“我们是否以正确的方式构建了正确的东西？” 审查和部署闭环。变更必须经受住与产品其他部分以及真实用户的接触。 在每一步中，软件开发都会缩小一个混乱的可能性空间，直到产生团队可以验证的变更。从这个松散的意义上说，软件开发就是降低熵：将困惑转化为经过验证的变更。 下面的图表展示了这个过程的简洁版本：意图变成团队可以支持的已推送变更。 展示软件开发过程的图表### 但快速编码也可能增加熵 起初，感觉 AI 智能体可以掌控实现。在更雄心勃勃的故事版本中，它们可能最终掌控整个循环。但在实践中，我们常常发现智能体“聪明过头”了。 失败模式很微妙。生成的测试套件可能很大，但大部分只是确认智能体已经选择的实现。审查线索可能会变得更长，因为智能体在核心问题周围吹毛求疵。一个计划可能听起来深思熟虑，但实际的产品权衡仍未决定。 这是“AI 废话”的一种形式：输出看起来很完整，但实际上并没有减少混乱。 引入 AI 智能体后，熵可能在流程的一个部分减少，在另一个部分增加。实现来得更快，但团队可能花更多时间重建智能体的意图，并决定有多少证据值得信任。 团队更快地产生代码，但未必更快地信任结果。 ## 缺失的部分：新的工作流程 一旦智能体进入日常工作，魔力就稍微消退了。它们开始感觉更像有能力的初级队友。工作开始看起来更像是指导： *你给它们足够的上下文开始，然后持续检查工作是否朝着你的目标前进。* 在我们团队中，这种转变是逐渐发生的。 起初，智能体是个人助理。它们在开发人员现有的循环内提供帮助，而开发过程的其余部分基本保持不变。 然后开发人员开始委托更大部分的实现。他们不再亲手编写大部分代码，而是成为智能体提议变更的编辑。 这效果出奇地好。这也让周边的工作流程感觉更沉重。 审查开始包含更多的考古工作。上下文必须重复。杂音测试必须被解读。审查者花更多时间重构发生了什么以及为什么。单独看每一件都不算戏剧性，但它们改变了工作的形态。 当任务仍在探索中时，聊天很有用。但一旦变更需要审查，聊天记录就成为糟糕的事实来源：重要的决策和具体证据与产生它们的来回讨论混杂在一起。 当人类编写大部分代码时，我们容忍了很多工作流程摩擦，因为实现本身需要时间。现在代码更早到来，所以周边工作流程就暴露了，而且在某些地方问题变得更糟。 这并不意味着“编码已解决”是错误的。它意味着瓶颈已经转移。 对我们来说，四个问题反复出现：上下文、规范、验证和人工检查点。 ## 需要改变什么？ 我们构建并运营一个管理数百万用户身份的身份验证产品。这使我们对智能体编写的代码持保守态度。在差异中看似局部的变更仍可能改变谁可以访问什么，尤其是在多租户系统中。 所以我们不能把智能体当作更快地扔代码过墙的方式。 ### 有目的地选择上下文 很多智能体工作成败在它写代码之前就已经定了。 大的上下文窗口有帮助，但更多上下文不一定更好。臃肿的提示可能会埋没那一条真正重要的规则。 大多数团队已经拥有所需的上下文，但它分散在文档、旧的拉取请求、聊天和团队成员记忆中。 对于邀请任务，有用的上下文围绕成员和访问：谁能邀请，租户边界在哪里强制执行，以及现有账户与新账户的接受方式是否不同。必须有人选择这些片段。如果这个选择留在开发者的头脑中，智能体就会猜测。如果它随任务传递，审查就从共享的基础开始。 工作期间创建的上下文也很重要。如果审查者两次纠正同一个错误，该反馈不应埋在两个单独的拉取请求中。如果团队引入了一个新约定，未来的运行应该能够使用它，而无需每个开发者粘贴相同的提醒。 这种纪律对智能体有帮助。它对团队也有帮助。智能体只是让旧的上下文问题更难忽视的压力。 ### 与工作保持一致的规范 模糊的任务以前没有现在这么危险。 当人类工程师接到模糊的任务时，他们会带着判断力。有时这种判断力表现为一个产品问题、一个记忆中的边界情况，或者拒绝按原样实现请求。 智能体更愿意继续前进。给它一个模糊的请求，它可能仍然产生一个完整的实现。即使解释是错误的，结果也可能看起来完成了。 这使得规范变得更加重要。 邀请规范仍然可以很短。管理员可以通过电子邮件邀请某人。邀请七天后过期。现有用户接受后加入。角色分配留待以后变更，跨租户访问保持禁止。如果审查发现一个缺失的边界情况，比如已暂停用户接受旧邀请，规范应该在智能体继续之前改变。 大多数任务只需要足够的形状来应对相关风险。一个小错误修复可能只需要预期行为和一个复现案例。随着风险增加，规范必须捕获重要的边界：用户流程、权限、约束和迁移故事。 一旦智能体开始编码，规范就不能消失。智能体根据它规划。实现根据它评判。如果团队发现一个缺失的边界情况，规范会改变，智能体继续以更新后的意图工作。 这就是我们在循环中重视规范的那个版本。有用的规范是那个与工作保持足够近以便与之争论的规范。 ### 审查者可信任的证据 > 当代码生成廉价时，信任变成了昂贵的部分。 智能体可以编写有用的测试。它们也可以编写主要确认它们已经选择的实现的测试。覆盖率上升，而审查者仍要问：我们真的证明了我们关心的行为吗？ 验证必须足够可见，以便审查者知道智能体运行了什么，什么失败了，以及失败后改变了什么。他们还需要知道通过的命令是否确实是该任务的正确命令。 之后，审查者应该看到这些承诺的证据，而不是一堵泛泛的绿色检查墙。运行应该显示管理员和非管理员路径已被执行，过期已被覆盖，以及新用户和现有账户的接受都有效。该证据背后的命令或环境也应可见。 一个小工具变更可能只需要单元测试。产品流程则不同：真正的信号可能来自端到端地演练体验。对于身份验证和权限变更，我们通常希望来自可复现环境的证据，尤其是围绕数据库状态和权限。 正确的检查取决于仓库和团队。重要的是审查者能够检查它们。审查者不应为了理解为什么认为该变更是安全的而翻阅冗长的聊天记录。 智能体擅长表现得自信。工作流程必须产生证据。 ### 判断力重要的检查点 人类不应永远坐在每个循环中。那违背了目的。 但某些时刻仍然需要判断力。 在实现之前，需要有人检查这是否值得构建。缺失的约束或错误的范围可能会非常有效地将智能体引向错误的答案。 这可能是在任何代码存在之前，人工检查点就重要的地方。必须有人决定角色分配是否在范围内，所有者和管理员是否都可以邀请，以及如何处理已经属于另一个租户的电子邮件。如果人类回避这些问题，智能体仍然可以为错误的产品决策交付干净的代码。 对于某些任务，这个检查点可能比代码审查更重要。 > 干净的代码无法拯救糟糕的规范。 实现之后，审查转向结果。问题是智能体是否真正以适合产品的方式解决了问题。仅凭测试存在只能说明部分情况；测试必须有意义。有时风险在于稍后才会出现的维护问题。 审查的深度应取决于风险。复制更新不应经历与权限变更相同的过程。随着系统赢得信任，某些类别的工作可以以更少的监督运行。其他的应保持严格审查。 这些边界应该是工作流程的一部分。 ## 让成果有意义才是工作本身 提示只是开始。大部分工作仍然发生在一个想法和一个团队可以信任的变更之间的空间。 这个空间现在需要更多的结构。正确的上下文必须随任务传递，规范必须随着团队学习而不断变化。证据必须展示实际证明了什么，而不仅仅是报告某件事通过了。工作流程还必须知道何时停下来询问人类的判断。 否则，智能体的工作就变成了一种更快地创建没人真正相信的代码的方式。 代码越来越容易产生。当前的工作是让它变得有意义。