AI 编程代理越可靠，代码责任越难分清

独立开发者、Django 早期贡献者 Simon Willison 在参加 Heavybit《High Leverage》播客第 9 期后写文反思：他原本认为 vibe coding 和 agentic engineering 是两类清楚不同的 AI 编程方式，但在自己的生产代码实践中，这条线正在变浅。

Willison 的不安来自一个具体变化：他承认，面对 Claude Code 这类编码代理生成的某些生产代码，自己已经不总是逐行审查。这个判断不等于编码代理已经可以替代代码审查。它更像一个早期信号：当代码生成速度和可靠性上来后，工程组织最缺的可能不再是“写出代码”，而是证明这些代码值得被交付。

Willison 的分界线被 Claude Code 撞松了

Willison 对 vibe coding 的定义并不只是“用 AI 写代码”。在他的表述里，vibe coding 是一种不关心代码质量、甚至不要求使用者会编程的方式：描述需求，拿到一个能跑的东西，坏了再让模型改。它适合个人、低风险工具；如果软件面向他人，牵涉数据、安全和故障成本，这样做就是不负责任。

agentic engineering 则相反。它假设使用者是专业工程师，懂安全、可维护性、运维、性能和测试，目标是更快构建更高质量的生产系统，而不是把低质量代码更快推上线。

问题在于，Claude Code 这类代理在常规任务上越来越稳。Willison 举例说，让它写一个执行 SQL 查询并输出 JSON 的 API，再补自动化测试和文档，他已经相信它大概率会做对。于是他开始像对待大公司里其他团队交付的图片缩放服务一样，把代理产物当成半黑盒：先看文档、跑用例、集成，出问题再深入仓库。

这个类比很有启发，也有硬伤。团队有声誉、负责人和事故后的复盘机制，模型没有职业信誉，也不能承担责任。工具“过去多次写对了”会带来信任积累，也可能带来偏差正常化：每一次侥幸正确，都会提高下一次在错误场景里放松警惕的概率。

代码变快后，验证成了新的稀缺品

AI 编程正在改写开源项目和内部仓库的外观信号。过去，一个 GitHub 仓库有上百次提交、清楚的 README、自动化测试，通常意味着维护者投入了时间。Willison 说，现在他可以在半小时内生成一个看起来同样成熟的仓库：提交记录、文档、测试都齐全。

这让“工程痕迹”贬值。测试和文档仍然重要，但它们不再足以证明项目可靠。更关键的信号变成：有没有被真实使用，使用了多久，是否经历过边界条件和失败恢复。

这也是企业采购 AI 时代自研工具时容易低估的限制。一个团队用 Cursor、GitHub Copilot 或 Claude Code 很快搭出 CRM、报表系统、内部运维平台，并不等于它已经适合公司级使用。企业真正该问的不是“仓库看起来像不像专业项目”，而是“有没有真实业务跑过、谁负责故障、出了数据问题谁签字”。

受影响最大的不是初级程序员，而是技术负责人

对软件工程师来说，AI 代理更像经验放大器。会设计接口、会拆任务、会写验收条件的人，能让代理跑得更快；缺少工程判断的人，则可能更快制造看似完整的风险资产。

对技术负责人来说，瓶颈会向前后两端移动。Willison 用一个假设说明变化：如果每天产出从 200 行代码变成 2000 行，原本围绕“代码很贵”设计的软件生命周期都会受压。需求澄清、架构设计、评审、测试、发布、监控和回滚，都要重新配速。

这和上一代 AI 编程助手不同。GitHub Copilot 早期更像自动补全，主要加速函数、样板代码和局部实现；现在的编码代理能创建文件、改测试、写文档、提交一组完整改动。生产力提升越接近“端到端交付”，责任空白就越难被一句“人类仍在环”盖住。

接下来最该观察的不是哪家模型又多会写代码，而是团队会不会建立新的验收制度：哪些任务允许半黑盒接受，哪些必须人工逐行审查；测试覆盖之外，是否记录真实使用；代理生成代码进入生产前，谁拥有最终责任。没有这些机制，AI 写得越快，工程债也会来得越快。