Your job is to deliver code you have proven to work
这是一篇 Simon Willison 关于 AI 辅助开发时代工程责任的短文。文章的核心判断非常直接：软件工程师的职责不是“提交一大段看起来像样的补丁”，而是交付已经被自己证明可运行的代码，并把这种证明一并交给评审者。放到 agent 时代，这篇文章等于把 verification-first 从“最佳实践”提升成了职业底线。
- 文章开头先批评了一种越来越常见的坏模式：借助 LLM 快速生成大补丁，然后把“确认它到底能不能工作”的成本甩给 reviewer 或开源维护者。这不是效率提升，而是把工作和风险外包给别人。
- Simon 把“证明代码有效”拆成两步，而且明确说两步都不能省。第一步是 手动测试：你要能把系统放回初始状态，执行改动，再亲自验证结果是否符合预期。
- 他对手动测试的要求很具体：如果能压缩成一组终端命令，就把命令和输出直接贴进 review；如果难以文字展示，就录屏给 reviewer 看。重点不是形式，而是你得拿出可复查的证据。
- 第二步是 自动化测试：贡献里应该包含一条能证明改动成立的测试，而且撤销改动后这条测试应该失败。文章明确认为，在 LLM 和 coding agents 已经把写测试成本大幅压低的情况下，跳过自动化测试几乎没有正当理由。
- 这篇还把 coding agent 重新放回同一个责任框架里：你不是让 agent “写点代码看看”，而是让它先证明改动有效，包括自己跑 CLI、做截图、写测试、复用现有测试模式，并继续迭代直到证据充分。
- 文中有个很重要的判断：对机器人来说，自动化测试和手动测试的边界其实更模糊。让 agent 启动服务、运行命令、截图、比对输出，本质上都是在构造一种机器可执行的“手动验收”。
- 放到《The Spec Layer》的框架里看，这篇解决的是“产出之后怎样证明它真的成立”，而 spec layer 解决的是“产出之前怎样减少 agent 朝错误目标做出局部正确选择”；两者是互补关系，不是替代关系。
- 文章最后把责任边界说透了：计算机不会承担责任，系统里真正承担责任的是人。所以今天“能生成 1000 行补丁”本身已经几乎没有价值，真正稀缺的是“我已经验证过它有效，并愿意为此负责”。
ℹ️ Conflict:
- 这篇把验证责任压得很重，但“证明有效”并不等于“穷尽所有边界”。很多复杂系统里，验证本身也是分层和有成本上限的，所以更准确的做法是提供与变更风险相匹配的证据，而不是追求伪绝对证明。
- 它强烈反对把验证负担甩给 reviewer，但现实里 code review 仍然承担一部分补充发现问题的职责；更稳的边界是 reviewer 不该替作者完成第一性验证。
- 文章把自动化测试成本说得接近免费，这是重要趋势判断，但不等于测试设计、fixture 维护和长期回归成本真的消失了。
- Agentic engineering
- Best Practices for Claude Code
- The Spec Layer
- Spec-driven development
- My fireside chat about agentic engineering at the Pragmatic Summit
- Simon Willison, “Your job is to deliver code you have proven to work”, 2025-12-18.
- 原文摘录：[llm-wiki/raw/01_AI/Your job is to deliver code you have proven to work](/raw/01_AI/Your job is to deliver code you have proven to work.md)