如果你真的想避免淹没在“人工智能垃圾”中，你需要经验丰富的工程师来监督所有人工智能生成代码的可观察性、测试和审查。

　　反弹是不可避免的。过去一年里，硅谷一直在告诉我们，软件开发即将变成一项“快速发布”的练习——你只需描述想要什么，然后让人工智能编码代理去构建它。当然，也许你可以留几个高级工程师来为产出“加持”……也许不需要。毕竟，谷歌的桑达尔·皮查伊表示，其75%的新代码现在由人工智能生成，并由工程师审查，相比之前大幅上升。

　　万岁！对吧？嗯……

　　《华尔街日报》最近强调了Mario Zechner和Armin Ronacher的警告——他们是流行的OpenClaw人工智能代理核心部分的两位工程师。他们认为，人工智能编码工具正在用他们所谓的“氛围垃圾”充斥软件。他们的抱怨是：太多人使用人工智能来跳过软件开发中真正重要的部分——设计、判断、测试、所有权，以及对所更改系统的深刻理解。

　　这值得认真对待。当那些帮助构建数百万人使用的工具的人开始警告说，这些工具正以工业规模产生错误甚至危险的软件时，或许是时候重新思考支撑这波人工智能浪潮的一些假设了。

　　我们需要的是反思，而非否定。

　　正确答案不是“人工智能编码很糟糕”。那太愚蠢了。人工智能编码的能力大致相当于电动工具：它帮助熟练的人做得更多、更快，同时也帮助不熟练或粗心的人更有信心地犯下更大的错误。这就是微型企业人工智能的故事。

　　“几乎正确”仍然非常错误

　　我曾在相关论点中提出：人工智能代码“几乎正确”的真实成本是巨大的。问题从来不是大语言模型会生成明显破碎的垃圾——如果是那样，我们会抓住它并继续前进。问题在于，它们快速生成了看似合理的输出。快速且合理，正是那种容易流入生产的组合。

　　重要的是要认识到：生成代码从来不是软件开发中最难的部分。正如Honeycomb创始人兼CTO Charity Majors所说，成为一名优秀的软件工程师，“关乎你随着时间的推移理解、维护、解释和管理生产软件的能力，以及将业务需求转化为技术实现的能力”，而不仅仅是编写大量代码。正如我之前写过的，开发速度很少是正确的衡量指标。开发人员花费大量时间理解现有系统，而不仅仅是为它们添加代码行。

　　人工智能并没有消除艰苦工作的需要。它所做的是让人们更容易愚蠢地跳过艰苦工作。

　　这一点在软件之外同样成立。我在工作中经常使用人工智能——例如，用它粗略地制作培训销售团队的幻灯片，或综合客户反馈。人工智能给了我一个起点，比如一份可能80%正确的备忘录初稿。这确实是一份礼物。但只有80%正确的终稿是一种责任，所以我必须指导和监督代理。这是真正的工作，尽管与我之前所做的工作形式不同。

　　核心问题是推卸责任

　　关于人工智能编码的辩论中最愚蠢的版本是：人工智能是否会取代开发者。更好的问题是：人工智能会奖励什么样的开发者？它不会奖励盲目接受输出的人。相反，它奖励那些能够快速、准确地判断输出是否符合系统、安全模型、性能边界、用户需求和组织标准的人。换句话说，人工智能奖励的是经验——它奖励那些知道“好”是什么样子的人。

　　这就是为什么一支支自主编码代理让我感到紧张。不是因为代理没有用处，而是因为责任不会像提示那样线性扩展。开发者可以审查一个人工智能生成的变更，或许五个。如果变更很小、测试很强，也许二十个。但是，当一家公司开始庆祝由数十或数百个代理发起的拉取请求、问题、测试、迁移和修复时，显而易见的问题是：谁真正知道发生了什么？

　　如果答案是“另一个代理”，很抱歉，我们又回到了起点。开源维护者已经深陷这种困境。在维护者警告低质量、通常是人工智能生成的贡献激增并压垮项目后，GitHub一直在加强更严格的拉取请求控制。据InfoWorld报道，GitHub已考虑更强大的过滤器和维护者控制，以阻止洪流。

　　这就是人工智能的丑陋经济学：生成成本低，但审查成本高昂。

　　摩擦即判断

　　Ronacher一直以令人钦佩的清晰度阐述相关观点。在题为“摩擦即判断”的演讲中，他与Christina Ponceleta认为，代理生成的代码倾向于向“当下方便”的答案漂移：捕获异常、添加回退、掩盖奇怪的边缘情况、保持演示运行。每个变更孤立地看似乎合理，但问题在于数百个变更在代码库中累积后会发生什么——它们会悄悄使系统变得更难推理。

　　在我看来，这听起来是对的。摩擦不是敌人；恰恰相反，摩擦才是你的判断所在。

　　这就是为什么“人在回路中”这个说法——尽管已经变得老生常谈——仍然重要。但只有当人类既能够注意到、又有能力判断工作时，这句话才有意义。初级开发者接受生成的代码，因为它通过了第一次测试，这并不能解决问题。高级开发者也无法以真正审查的速度“审查”大量代理编写的拉取请求。

　　保障措施不是“隐约在回路中的人”。不，这是故意应用的专业知识，配合一套强制问责而非推卸责任的系统。对于开发者来说，人工智能在用于有边界的任务时最为强大，例如生成测试或解释不熟悉的代码。同样，当被要求做出广泛的架构决策或推断出存在于人脑中而非代码仓库中的业务规则时，人工智能则较为薄弱。

　　对于管理者而言，最糟糕的指标就是“人工智能生成代码的百分比”。这就像用“自动补全起草的句子百分比”来衡量新闻编辑室。谁在乎呢？真正的问题是：缺陷是否减少？交付是否更快？事件是否更少？客户是否更满意？

　　护栏不能只停留在备忘录上

　　纪律是必要的，但对企业来说还不够。你不能指望数万名工程师、分析师、营销人员、律师和销售人员仅凭善意和备忘录就能可靠地“放慢工作并检查结果”。在大规模环境中，保持人类在回路中必须由架构来强制执行，而非依赖善意。

　　实践中，这意味着将护栏内建到系统之中——包括代理接触的边界、身份、数据治理和可观察性。这听起来像是我工作的地方（甲骨文）所倡导的方向。我看到整个行业真正有趣的转变——是的，甲骨文也在下注：将更多控制权推入数据层本身，使代理针对受控的企业数据操作，而不是作为掌握生产密钥的灵活脚本。

　　这并不像“代理会写你所有代码”那样令人兴奋，但你猜怎么着？那很好。在企业人工智能领域，“无聊”是件好事。

　　那么，谷歌宣称75%的新代码来自人工智能，这对企业有多重要？这可能是真的，但谷歌也拥有世界上最好的一批工程师来审查那些产出。这是故事中太多人工智能鼓吹者跳过、但绝不应该跳过的部分：人类才是让人工智能发挥作用的途径。