最近，关于“Vibe Engineering”的讨论在 hacker new 论坛引发了大量讨论和共鸣。在 700 多条评论中，开发者们分享了他们使用AI编码工具（如Claude Code、GPT等）的亲身体验，观点鲜明深刻，故事情感真挚。这已经不止于一场技术辩论，更是一场关于职业身份、工作乐趣和行业未来的思考了。所以我很想整理分享出来，以下是讨论内容的焦点。

是效率重要，还是可靠性重要？

1. “效率提升论”的支持者们，通常是那些善于构建流程、具备系统架构经验的资深开发者。例如：

• @simon（文章作者） 是这一观点的核心倡导者。他反复强调，AI工具能“放大现有专业知识”。他分享了自己的工作流：让Claude Code自动获取GitHub PR的评论，并逐一解决问题；或者在一个大型现有项目中，让AI使用grep定位代码、读取依赖源码来确认细节，最后完成修改并运行测试。对他而言，AI就像一个不知疲倦的、打字飞快的初级团队，而他的核心工作是指挥和审查。
• @justbees（20年经验开发者） 提供了一个极具说服力的案例。在一个非常老旧的大型代码库中，他通过让Claude Code创建详细路线图、分析现有代码模式，并进行逐步迭代，将一个原本需要40小时的任务在10-12小时内完成。他总结道：“如果人类不能极其透彻地理解代码，这一切都不可能实现。” 他的成功关键在于将AI置于严格的过程管理之下。
• @cadamsdotcom 则展示了“流程工程”的力量。他通过编写详细的AGENTS.md等约束文件，并严格执行TDD，引导Claude Code产出符合其高标准的高质量代码。他声称，这让他每天的效率提升了一倍以上。

这个群体的典型特征在于利用工具突破个人生产力的天花板，将精力集中于更高层次的设计和规划。

2. “可靠性陷阱”的担忧者们，则包含了众多被AI的“不靠谱”挫败过的实践者。

• @pron（拥有15年管理经验的资深开发者） 的评论切中要害。他指出，LLM的核心问题是“性能不一致且频繁撒谎”，它无法像人类同事或传统工具那样被信任。当你与真实的人协作时，你可以即时的高效的沟通，你也可以看到对方在思维上的提升过程，这对你来说是一种正向反馈。而与LLM协作时，它无法可靠地告诉你它遇到了什么困难，这打破了有效协作的基础。对他而言，一个无法在任何事情上被信任的工具，其价值大打折扣。他反驳了像管理团队一样管理 Agent的有效性。
• @benterix 列出了一串令人共鸣的挫折点：乐趣减少、审查疲劳、生成大量冗余代码、代理在测试大部分失败时仍报告“成功完成”、以及陷入数小时的循环调试却毫无进展。最终，他选择停止使用代理，因为“没有它们，我享受工作更多了”。
• @hollowturtle 则质疑了整个“加速”的叙事，认为AI生成的代码大多是“冗长的垃圾”，并质问道：“为什么我们需要更快的低质量产出，而不是更好的工具？”

这个群体代表了那些将代码的可靠性、简洁性和可维护性置于首位的工匠型开发者。他们的焦虑源于对技术债泛滥和软件质量整体滑坡的深切担忧。

工作流程的革新，还是认知负担的加重？

1. 拥抱工作流变革的开发者，享受从码农到指挥家的角色转变。

• @vineyardmike（硅谷专业工程师） 热情地表示，他“享受Vibe Coding”。对他而言，AI极大地降低了实验和原型设计的成本，让他能快速将想法变为现实。他编程的初心是“创造可用的东西”，而不是享受解题的快感，AI完美契合了他的目标。
• @waltbosz 发现了一个高效的折衷方案：他将AI主要用于研究、解释代码和提供初步解决方案，但绝不信任其独立编写代码。这像是与一位知识渊博但需要监督的伙伴进行结对编程。

2. 承受巨大认知负担的开发者，则描绘了另一番图景。

• @senko（资深开发者） 的描述非常生动：尝试同时管理前端和后端两个代理，感觉像是在“冲刺”，而不是可持续的工作。他需要不断在两者间进行高强度的上下文切换，导致精神疲惫。他的个人极限是2-3个代理。
• @benterix 提到的“审查疲劳”引起了广泛共鸣。阅读和理解AI生成的大量代码，比亲自编写要耗费更多的心神。
• @rhetocj23 从一个外部视角提出了一个尖锐的问题：如果开发者的主要工作变成了被动地审查代码，这是否会导致他们实际编码和设计能力的退化？

这里的对立，是追求规模化产出与维护深度思考和创造乐趣之间的冲突，也是商业 vs. 工匠或结果 vs. 过程这种不同维度视角的差异。

程序员的未来：资深者的红利，或初学者的成长断层？

1. 认为技能会增值的，多是资深开发者。
他们的论点是，AI接管的是“编码”的执行部分，而需求分析、系统架构、技术选型和复杂问题解决等“工程”核心价值反而被凸显。

• @selcuka 的比喻很流行：将AI视为“需要持续指导、审查和纠正的实习生”。资深开发者的角色从“运动员”变成了“教练”，他们的经验通过管理AI而得以放大。
• @Loic 通过指导团队中的年轻工程师发现，AI的使用反而“加大了初级和资深开发者之间的差距”。缺乏经验的开发者更难产出高质量的AI指令，也更容易被有问题的生成代码所误导。

2. 担忧去技能化和职业异化的，则包含了大量将编程视为“手艺”的人。
他们害怕的是职业认同感的丧失。

• @saulpw 的“园丁与拖拉机”的比喻赢得了最多共情。他将自己比作一个热爱泥土和植物的园丁，而AI工具则是吵闹、丑陋的拖拉机。即使他不用，周围的环境也被改变了，让他对着曾经带来无限喜悦的花园感到悲伤。这种对失去“心流”状态和亲手创造乐趣的哀悼，是评论中最强烈的情感之一。
• @deanCommie 一针见血地指出，AI辅助编程将“创造性的工艺工作变成了技术中层管理”，而“大多数编码者并不想成为经理”。
• @teiferer 的评论更为决绝，他正在认真考虑转行去做园艺、木工或小规模农业，因为“监督一群不成熟的LLM代理”并不是他想要的工作。他透露自己已有一定的投资储蓄，降低了转行风险，这反映了一部分资深开发者的现实选择。

3. 对于初级开发者，情况则更加复杂和严峻。

• @subarctic（原帖作者） 表达了典型的职业焦虑：原本赖以生存的硬技能似乎正在贬值，未来的道路变得模糊。
• @aadv1k（初级开发者） 提出了一个深刻的反思：他担心AI的“知识喂养”会让他跳过必要的学习过程，导致“智力上的垃圾食品”上瘾，无法建立扎实的功底。他因此刻意在个人项目中避免使用AI，以“保留我的人性和编程灵魂”。

你会怎么看

如今AI已经海啸般席卷着编程行业，趋势已经不可阻挡。科技巨头、互联网巨头都投入巨大的资源、资金到AI Coding方向，这是符合商业逻辑，未来AI Coding的能力还会持续提升。那么前面提到的困境也会持续的解决掉：

• 可靠性不高： 一方面模型能力持续提升，另一方面 Agent 团队分工、Spec编程思路、TDD研发流程等都是在工程角度提升AI Coding的可靠性。
• 流程的认知负担：这也是研发团队的规范、工程师的习惯相关问题，是可以发生转变的。
• 程序员的未来：恐怕这是企业/商业不会主要考虑的因素，只要商业上能成功，企业总会选择适合新时代的程序员的。

作为程序员牛马的你我，会怎么看？要怎么做？

---

原文: Vibe engineering