Essential Complexity（本质复杂性）
定义
软件问题中无法靠工具自动消除的真实复杂性，包括领域约束、抽象边界、维护后果和责任判断
与 AI Coding 的关系
Jacob Harris 借用 Brooks 的区分来解释为什么自己不 Vibe Code：AI 很擅长继续降低 accidental complexity，也就是写代码本身的麻烦；但真正困难的部分往往是 essential complexity，也就是理解现实、设计正确抽象、权衡长期后果。
这不是说 LLM 对复杂系统完全没用，而是说 LLM 不能让复杂性消失。它最多把一部分复杂性迁移到 prompt、harness、测试、review 和架构决策里。如果人类误以为“代码生成速度”已经解决了“系统设计难度”，复杂性只会换一种形式回来。
为什么重要
本质复杂性是 AI coding 最容易被遮蔽的部分。LLM 让语法、样板代码、API 调用和常见重构更便宜，这会制造一种错觉：只要生成足够快，软件问题本身也会变简单。
但真实系统的难点经常来自领域规则、例外情形、责任归属、用户后果、长期维护和组织边界。这些东西不能靠更多代码自动消除。它们需要人建立 Conceptual-Model、划定 Bounded-Context、设计测试和承担判断。
因此，essential complexity 是区分 Agentic-Engineering 和 Vibe-Coding 的分界线。前者让 Agent 帮人处理可验证执行，后者容易把设计判断外包给模型。
识别信号
- 需求表面简单，但每次追问都出现例外、权限、合规、责任或历史包袱。
- 类名和函数名总是不满意，说明团队还没有找到正确词汇。
- 测试难写不是因为框架麻烦，而是因为行为边界没有说清。
- Agent 反复生成可运行方案，但每个方案都让未来维护更难。
- 业务专家和工程师对同一词的理解不同。
关键数据点
- Harris 把现代语言、标准库、框架、编辑器重构工具都视为对 accidental complexity 的持续压缩。
- 文章明确指出，系统抽象是否优雅、清晰、可维护，仍然需要技能、经验和失败教训。
- 作者认为 LLM 的“高级自动补全”在 weird、rare、messy 的复杂场景中缺乏解释自身路径的能力。
- Why I Don’t Vibe Code 的迁移价值在于提醒：工具进步降低的是实现摩擦，不自动提供判断、责任和模型质量。
前提与局限性
- 前提: 任务包含真实领域约束和长期维护要求，而不是一次性脚本或低风险原型。
- 前提: 团队关心的不只是功能跑通，还包括抽象质量、协作理解和未来演化。
- 局限: 通过更好的类型系统、测试、领域模型和 Agent Harness，部分看似本质的复杂性可能被转化为可验证流程。
- 局限: 对新手而言，LLM 可能先帮助跨过入门门槛，再逐步暴露 essential complexity。
- 误判风险: 不是所有摩擦都是本质复杂性。环境配置、样板代码和 API 参数问题通常应该被工具消除。
关联概念
- Vibe-Coding — 容易把生成代码的速度误认为解决系统复杂度。
- Agentic-Engineering — 生产级实践需要把 essential complexity 显式纳入验证和 review。
- Friction-as-Design-Signal — 摩擦常常提示本质复杂性正在暴露。
- Conceptual-Model — 本质复杂性最终落在概念模型和边界选择上。
- Judgment — 处理本质复杂性需要判断力，而不是只需要执行力。
- Code-as-Conceptual-Infrastructure — 本质复杂性最终需要被词汇、边界和模型承载。