Why I Don’t Vibe Code
编译摘要
1. 浓缩
- 核心结论1: 作者反对的不是“使用 LLM”，而是把设计判断、抽象选择和责任承担交给 LLM。
- 关键证据: 他承认会用 LLM 处理 ImageMagick 参数这类低风险、可描述、可快速验收的小任务；真正反对的是 vibe coding 把系统设计、长期维护和“为什么这样写”的理解从开发者手中抽走。
- 核心结论2: 文章用 Brooks 的 accidental complexity / essential complexity 区分指出：AI 主要降低写代码的偶然复杂性，却不能消除问题本身的本质复杂性。
- 关键证据: 作者认为真正难的是把现实建模为清晰、可维护、能容纳例外的抽象，而不是把想法翻译成语法正确的代码。LLM 可以被引导参与这个过程，但如果人类已经能做出正确引导，人类也仍然是在做核心设计工作。
- 核心结论3: 摩擦不是纯成本，它是学习、理解和架构纠偏的信号。
- 关键证据: 作者强调 close reading 代码、逐行理解陌生系统、写 ADR、暂停思考和散步。当某段代码写起来很痛苦时，问题可能不是“需要更多生成”，而是抽象边界错了、系统已经在发出结构性警报。
- 核心结论4: 软件是社会责任的一部分，LLM 可以模拟 care，却不能承担后果。
- 关键证据: 作者从数据新闻和 civic technology 的经验出发，指出软件错误可能引发诉讼、公共服务失败或真实伤害。供应商在模型删除基础设施、虚构测试通过等事故中往往把责任推回用户，这说明 accountability 仍留在人类与组织身上。
2. 质疑
- 关于样本位置的质疑: 这是一位资深开发者的个人立场，建立在其已有抽象能力、项目风险意识和对编程本身的热爱之上。新手、一次性脚本、低风险原型、内部工具可能得到不同结论。
- 关于 essential complexity 的质疑: 文章正确指出 LLM 不能自动消除本质复杂性，但严谨的 harness、测试、类型系统、ADR、review 与人类引导可以把一部分设计探索转化为可验证过程。不能把“LLM 不能负责”推成“LLM 不能参与”。
- 关于“摩擦是礼物”的质疑: 并非所有摩擦都值得保留。环境配置、API 参数、样板代码和工具链碎片化常常只是浪费认知带宽。高质量工程实践需要区分“揭示结构问题的摩擦”和“应该被自动化掉的摩擦”。
- 关于伦理批评的外推: 文中对供应链、劳动、能耗和社会伤害的批评重要，但和具体项目是否使用 coding agent 之间还隔着组织责任、供应商选择、风险等级和替代方案。它应作为决策约束，而不是单一否决理由。
3. 对标
- 跨域关联1：vibe coding 的反例: 这篇文章为 Vibe Coding 提供了强反面样本。它不是怀旧地反对效率，而是指出当开发者不再理解抽象、边界和后果时，速度会变成认知债。
- 跨域关联2：代码作为概念基础设施: 作者关于森林、性别、日期、姓名、种族分类和诊断边界的讨论，支撑 Code-as-Conceptual-Infrastructure：软件抽象不是中性容器，它会压扁现实、遮蔽例外，并在制度系统中放大。
- 跨域关联3：摩擦作为设计信号: Friction-as-Design-Signal 的关键不是“慢就是好”，而是某些阻力提示系统模型不对。AI 若只负责绕过阻力，可能把架构问题包进更多生成代码里。
- 跨域关联4：责任与 ownership: 文章补强 Ownership 与 Judgment：AI 可以生成候选实现，但不能承担法律、道德、维护和协作后果。工程团队的剩余价值不只是验收输出，而是为选择负责。
- 迁移判断: 这篇文章最适合放在 Agentic Engineering 的边界讨论里：它提醒我们，AI Coding 的正确目标不是消灭开发者的思考，而是把人的判断力放在更高杠杆的位置。
关联概念