My fireside chat about agentic engineering at the Pragmatic Summit
这是一篇 Simon Willison 关于 Pragmatic Summit 炉边谈话的总结，主题仍然是 agentic engineering，但比前一篇 Lenny 播客摘录更偏向具体操作细节。文章最有价值的部分不是再重复“代码变便宜”这类总判断，而是把一套更清晰的实践方法说透了：先教 agent 怎么跑测试、用 red/green TDD、让它做手动验证、在高质量模板和代码模式上扩写，并始终把 sandboxing 当成真实安全边界。
- Simon 把开发者采用 AI coding 的路径描述成一个阶段变化：从问答式助手，到写代码片段，再到 agent 产出的代码量超过自己。这种量变跨过某个阈值后，工作方式就会整体重排。
- 文章对“信任 AI 输出”给了一个更现实的标准：不是逐行永远不信，而是像对待别的内部平台团队一样，先信任可验证的行为；如果服务出问题，再深入看实现。对 Simon 来说，
Opus 4.5是第一批让他在常见 API 场景中建立这种默认信任的模型。 - 它把一个很具体但高价值的套路写清楚了：每次开始 coding session，先告诉 agent 如何运行测试，例如
uv run pytest，再明确要求使用red/green TDD。他甚至直说，测试现在“基本免费”，因此在 agent 时代不写测试更说不过去。 - 自动化测试之外，文章还强调“手动测试仍然必要”。即使测试套件全绿，服务也可能没有真正跑起来。所以他会要求 agent 把服务启动在后台，再用
curl或Showboat这类工具做手动验收，并把测试过程记录成文档。 - 文中还展示了一种很强的
consistency-driven development：先让模型从多个现有实现中抽出一个 conformance test suite，再反过来依据这个 suite 为新系统生成实现。这相当于让 agent 先逆向提炼标准，再据标准写代码。 - Simon 对代码质量的判断也比“vibe coding 万能”细得多：一次性小工具可以接受意大利面代码，但长期维护的软件完全不同。而且差代码不是 agent 的宿命，很多时候只是人选择不继续要求 refactor。
- 他特别强调模板和代码模式的重要性。agent 极度擅长沿用现有模式，所以一个带测试、README 和 CI 的好模板，会直接提升后续生成代码的质量；坏模式也会被同样忠实地放大。
- 在安全边界上，这篇文章把重点压得很实：
prompt injection的对抗核心不是“我有没有足够聪明地识别恶意输入”，而是sandboxing。即使 Simon 为了便利有时会在本机开dangerously-skip-permissions，他也明确承认这很冒险，只是在拿风险换速度。 - 它最后还补了一条很现实的生态判断：agents 一方面在放大开源价值，因为它们高度依赖现有库与生态；另一方面也在向开源项目灌入大量未经审查的垃圾 PR 和低质量贡献。
ℹ️ Conflict:
- 这篇仍然是 Simon Willison 的个人工作法总结，不是可直接复制到所有团队的标准流程，尤其是对本机高权限运行 agent 的容忍度明显带有个人风险偏好。
- “测试免费”是很有力的判断，但它更接近“生成测试的边际成本下降了”，不等于测试设计、验收标准和长期维护真的没有成本。
- 文中一边强调默认信任更强模型，一边又强调沙箱和手动测试必不可少；这不是自相矛盾，而是说明“更可信”不等于“可不设边界”。
- Agentic engineering
- Agent scaffold
- Sandboxing for agents
- Highlights from my conversation about agentic engineering on Lenny’s Podcast
- Simon Willison, “My fireside chat about agentic engineering at the Pragmatic Summit”, 发布日期未在 raw 摘录中明确给出。
- 原文摘录：[llm-wiki/raw/01_AI/My fireside chat about agentic engineering at the Pragmatic Summit](/raw/01_AI/My fireside chat about agentic engineering at the Pragmatic Summit.md)