Jacob Harris 写了一篇"Why I Don't Vibe Code"，作者是 dotey（宝玉）转发的。原文很长，这里是关键内容的提炼。
我是个守财奴
作者花了几百美元在 AI IDE 额度上，然后卸载了。因为他祖上两边都是出了名的铁公鸡，他完全无法接受为"思考"持续付费这件事。
他发现自己其实并不怀念 AI。离开 AI，他回到了 Emacs，发现没有 AI 也没觉得哪里不对劲。
我年纪大了，所以还记得一些事
作者引用了 Fred Brooks 的《没有银弹》——软件工程的经典命题：偶然复杂性可以被工具消除，但本质复杂性去不掉。
设计出正确、优雅、清晰、易维护的抽象架构，是无比艰巨的工作，需要技能、经验，以及从过去系统崩溃史中艰难汲取的智慧。
LLM 可以帮助处理偶然复杂性——但本质复杂性还在那儿，而且哪儿也去不了。
我爱死这些混乱了
作者指出了一个关键问题：LLM 无法进行元认知——跳出来审视系统本身。
AI 模型的构建基础和它们看待世界的方式都被极度剥离了细节。当人类看着一段文字，能看到上下文（格式、标题、作者、链接），而 LLM 只在一个纯粹由字母构成的世界里运转。
他举了 DOGE 团队的案例：他们看到 SSA 数据库里有 900 万条 120 多岁的"活人"，直接得出欺诈结论，而不是质疑数据质量本身。这和 LLM 走偏的逻辑一模一样——拒绝考虑数据字面意思之外的任何替代解释。
摩擦是上天的恩赐
作者说他需要摩擦来工作：
- 当写代码变得异常困难，这说明他正在走向一条歧路
- 他会在开始写代码之前先强制自己写 ADR（架构决策记录）
- 这个文档写作过程经常让他发现对自己的直觉过度自信了
AI 驱动开发对待摩擦的态度是不管三七二十一直接写过去。LLM 极其配合，但根本不知道自己为什么选择了那条路，感觉不到摩擦，无法告诉你这个架构方案是否比另一个更清晰优雅。
我极其在乎
这是最简单也最深的理由：编程是他表达创造力的一种方式，他不想拱手让给机器。
当代码出 Bug 可能导致报纸更正或诉讼时，他没有退路可以推卸给 AI。如果把道德责任外包给 LLM，他永远无法被追责。
而当 LLM 表现良好时，它是即将取代程序员的天才；当 LLM 删除了你的基础设施或在测试结果上撒谎时，错的却是你——"谁叫你没把提示词精确配置好"。
作者的核心判断
作者见到的 vibe coding 成功案例，要么是开发者本身已经是该领域专家（因此能驾驭 AI 的工作），要么是那些搞砸了也无伤大雅的边缘项目。
对于大多数情况，问题不在于 AI 能做什么，而在于谁来判断 AI 的输出是否真的好——如果负责提示词工程的人本身缺乏洞察力，分辨不出好坏方案，就会陷入死循环：一遍又一遍让 AI 强行穿越重重摩擦写代码。
最终生成一堆奇形怪状的抽象逻辑，唯一的设计文档就是那个指示 AI 模型的 Markdown 文件。留给未来接手的人一道难题：从那个文件里重构当年的架构决策。
布鲁克斯在 1986 年说"没有银弹"；2026 年我们还在找银弹。