编码已经解决了吗？Theo 区分代码生成与软件工程

Boris Cherny 说编码已经解决，但 bug 尚未解决，这句话让许多开发者不高兴。我想为其中一种理解辩护，同时认真对待 Matt Pocock 的批评。很多分歧来自人们用“编码”指代不同范围的工作。

直接引发讨论的例子是 Claude Code 桌面应用的一条更新提示，文字明显被截断。我认为这是 bug，尽管 Boris 后来把它称为用户体验问题，并表示即将修复。截图展示了结果，但不能证明代码是谁写的或进行了哪些测试。

我担心的是，生成的代码在差异里可能看似合理，却没有人实际检查运行中的界面。在人类工作流程中，作者通常会在构建时看到页面。有了智能体，一份拉取请求本身并不能证明人或智能体检查过体验。

当用户无法读到文字时，我觉得区分用户体验问题和 bug 没有说服力。但在争论“编码已经解决”之前，我们需要定义编码。它可能指输入代码、把工单变成 PR，也可能指从想法到可用产品的全过程。

如果编码指工程师做的全部工作，我不认为它已经解决。如果只指生成源代码这一狭义行为，我认为当前智能体能完成其中很大一部分。这是我的判断，并不是说它们每项任务都能成功。

我用 Neal.fun 的密码游戏举例：它故意创造了糟糕的密码体验。作者显然写代码实现了这种效果。开发者也可能无意中做出糟糕体验；软件质量差，并不意味着没有发生编码。

糟糕结果可能来自说明不足的请求，也可能来自详细却错误的要求。这是两种不同的输入问题。即使实现者很有能力，如果计划指向了错误方向，结果仍可能不是用户需要的体验。

我画了一个简单流程图：好的、坏的或空泛的计划进入工程流程，最后产出软件。优秀工程师可能质疑计划，但忠实执行坏计划仍可能产生坏软件。计划模糊时，结果在很大程度上取决于上下文和判断。

图中的分数只是示意，并非测量出的概率。好计划和有能力的工程师可以提高成功机会，但不能保证结果。对于不完整的计划，结果可能很好也可能很差，取决于复杂度和团队的理解。

缺少的一层是验证：质量保障、预发布环境、预览构建和渐进发布。实际使用体验可能揭示一个听起来合理的计划并不适合用户。验证既检查实现，有时也能检查计划本身。

把图里的工程师换成智能体。一份 PR 可能看起来合理，但代码从未运行过。如果最终发现问题的只有客户，反馈就来得太晚。我猜被截断的提示反映了这种缺口，但我并不了解它完整的开发历史。

当验证发现问题时，结果应反馈到实现或规划阶段。小缺陷可以直接返回修复；糟糕的产品决策可能需要修改计划。目标是在问题触达用户前发现它，而不是承诺软件完美无缺。

测试困难不一定只是模型的问题，也可能来自环境。我在一些仓库工作时，启动本地构建验证修改比实际修改还耗时。如果人都难以验证，智能体也需要帮助和可用工具。

我怀疑桌面应用尤其难以并行测试：不同构建可能需要图形环境、独立状态和供智能体交互的方式。我将此与在不同浏览器标签中测试多个 Web 构建作比较。我对 Anthropic 内部流程的解释是一种推测。

人类也面临这些配置问题。与其责怪模型没有检查难以运行的东西，不如建立能让检查发生的工作流程。这是写代码步骤之外的工程工作。

这又回到了定义。有些人把编码限定为把计划转换成源代码；另一些人则包括规划和验证。我能理解两种用法，但整个循环及支撑它的平台属于软件工程，而我不认为软件工程已经解决。

Boris 并没有说软件工程已经解决。缺陷、测试环境、系统架构和有信心地进行修改都属于更广泛的流程。智能体在这里需要支持，正如新工程师需要一个能工作的开发环境。

我的理解是，Boris 认为智能体非常擅长实现规定好的变更，但自主发现和预防 bug 仍然更难。我随口估计的智能体成功百分比只是个人估计，不是基准测试结果。

改进既需要更好的项目架构，也需要模型和平台供应商提供更好的工具。智能体需要可重复地运行产品、检查结果并展示检查了什么。即使有视频也不自动等于有证据：我见过智能体制作的录像，里面明明显示功能没有正常工作。

以我的经验，清晰的 bug 报告加上验证修复的方法，可以让当前智能体处理许多缺陷。这与在发布前可靠地预见所有边缘情况不同。我不认为软件会变得完全没有 bug。

在 T3 Code，我投入精力让开发服务器能通过 Tailscale 访问，并使用真实数据的只读快照。这既帮助我远程检查工作，也帮助智能体测试更有代表性的场景。建立这些基础设施本身就是大量工程工作。

在智能体能够可靠地自行建立并使用全部验证循环之前，人需要搭建系统并检查结果。观察实际行为很重要，因为修改在源代码中看似合理，却可能产生明显损坏的界面。

我认为智能体越来越有能力发现许多代码中可见的问题，但代码审阅仍能发现架构不匹配、不合适的依赖、高风险修改，以及缺失或多余的测试。我对阅读代码局限性的说法是一种观点，并不能证明审阅没有价值。

如果“编码”指整个软件生命周期，Matt 的反对就很合理。Boris 最初的简短帖子没有定义这个词。人们可能激烈争论，实际上却在描述工作的不同部分。

在后续说明中，Boris 描述了几个阶段：模型先超过他自己的编码能力，再提高与编码相邻的工程任务能力，最终在更多计算机工作上超过人类。他表示 Claude 对自己的工作已达到第一阶段和第二阶段的一部分；这是他的判断和预测。

Boris 也指出，并非每位专家的情况都相同。他说自己在 2025 年 11 月停止手写代码，但仍每天使用智能体编码，并明确区分工程与代码生成。他承认模型生成的代码仍有 bug 和低效之处。

Matt 使用 John Ousterhout 对战术性编程与战略性编程的区分。战术工作是日常实现；战略工作关注长期架构和代码库健康。Matt 认可前者已经在相当程度上实现自动化，但质疑智能体能否进行战略思考。

我大体同意，智能体目前还不能可靠、主动地独立维护长期架构。它们仍然可以充当有用的顾问：在确定策略前，让它们调查设计、比较方案或验证一个理论。

人确定计划并提供验证结果的方法后，智能体可以快速执行工作。帮助人类的基础设施——容易配置、审阅、部署和回滚——也能帮助智能体。速度不能消除评估实际成果的必要性。

Boris 表示，一些战略工作已经开始自动化，包括维护流水线。Matt 指出，设计和管理从 bug 报告到复现、修复，或从架构提案到重构的流水线，本身需要战略判断。

我同意，人需要进行工程工作来建立这些系统，即使智能体能够协助。我的观点是，代码生成变得更容易自动化，而规划、验证和长期判断仍未解决。边界画在哪里，仍然可以讨论。