Agent 式编程是个陷阱
速览
本文探讨了当前热门的 Agent 式编程模式,认为其存在显著局限性。作者警告开发者,过度依赖此类自动化编码方式可能带来维护困难和逻辑混乱等问题。因此,Agent 式编程并非万能解药,反而可能是一个需要警惕的陷阱。
AI 深度解读
Agentic Coding Is a Trap:代理式编程的陷阱与技能萎缩
背景
本周,一位开发者在通话结束时的一句话让我久久无法平静。这位开发者拥有两年半的第一份商业工作经验,出身于编程训练营(Bootcamp),目前正维护着一团糟的 PHP 代码库——充斥着上帝类(God classes)、原始 SQL 查询、缺乏依赖注入,以及从超全局变量(superglobals)中直接拉取的全局状态。这种代码库几乎无法进行测试,身处其中,开发者往往花费数年时间去学习如何驾驭混乱,却从未真正学会如何构建整洁的代码。
在通话之前,他无法准确描述哪里出了问题,只是本能地感觉到“不对劲”。经过一个小时的梳理,我们明确了他所处的阶段、实际存在的差距以及向前发展的直线路径。结束时,他有了清晰的图景和具体的构建目标。然而,就在那一刻他说出了那句让我深思的话:“我觉得自己落后太多了。”
这并非绝望,而是终于看清现实后的沉重感。这种焦虑从模糊的低鸣变成了有形状、有名字、有路径的具体问题。这正是成长的开始,但也揭示了当前 AI 辅助编程背景下更深层的行业危机。
核心内容
代理式编程的陷阱
Cal Newport 近期引用了开发者 Lars Fay 的一篇热门文章《Agentic Coding Is a Trap》(代理式编程是一个陷阱)。Fay 描述了当前大多数开发者采用的新工作流:描述需求,拉动杠杆,让 AI 代理(Agents)迭代直到完成。在这个过程中,编排者(Orchestrator)与被生成和提交的代码之间产生了日益扩大的距离。
Fay 的核心论点是:只有具备高超技能、能够进行批判性思考并在架构层面运作的开发者,才能在数千行生成的代码演变成问题之前发现其中的隐患。讽刺的是,AI 工具已被证明会负面影响那些你用来有效使用它们所必需的批判性思维能力。
技能萎缩与“LLM 精神病”
Reddit 上充斥着类似的抱怨:
- “因为 AI,我失去了编码能力。”
- “让 AI 做 100% 的编码工作把我的脑子搞坏了。”
- “每次使用 AI,我都觉得自己作为一名专业人士在退步。”
甚至有人因接近所谓的“LLM 精神病”(LLM psychosis)而不得不短暂休息。Cal Newport 指出,计算机科学教育中存在一个已知现象,称为“大三墙”(Junior Year Wall)。学生让 AI 处理基础课程,到了大三面对硬核内容时,却没有任何基础知识可以依靠。Fay 认为,这种现象正在整个行业蔓延。一位拥有 30 年经验的开发者坦言:“我个人强烈感受到了技能萎缩的影响。这曾经是我深度工作的来源,现在不再是了。”
分阶段的能力模型:Code-First vs. Best Practice-First
Fay 的文章虽然重要,但主要针对特定类型的开发者。作者强调,不能向处于更高范式的对象提供低层级的建议,也不能向尚未建立基础的对象提供高层级的建议。
1. 如果你是 Code-First(代码优先型)开发者:
- 现状:你能构建事物、交付功能、熟悉语言,但在解释架构决策(如边界为何存在、依赖指向、抽象价值)时会沉默。这不是性格缺陷,而是阶段性的缺失。
- 缺失的体验:你尚未遭遇推动你进入下一阶段的痛点。例如,你还没有被不稳定的端到端(E2E)测试折磨过,没有经历过环境切换导致测试套件莫名变红,也没有从零设计过能随代码库增长而保持稳固的测试策略。
- 判断力的培养:真正的技术判断力不是读出来的,而是通过“遭遇”培养的。遇到问题 -> 被挫败 -> 寻找解决方案 -> 整合 -> 带着伤疤(地图)前进。跳过阶段只会推迟撞墙的时刻。
- AI 的风险:AI 代理目前已在执行 Best Practice-First 阶段的任务(如规范驱动开发、契约优先设计、结构化测试生成)。如果你作为 Code-First 开发者让 AI 代劳,你并没有加速,而是外包了那些本应构建你评估 AI 输出能力的挣扎过程。
- 处方:不要扔掉工具,但降低其地位。自己写代码,用伪代码思考后再生成。制定硬性规则:绝不要求 LLM 实现你自己无法独立完成的东西。快速夯实基础,因为差距每月都在扩大。
2. 如果你是 Value-First(价值优先型)开发者:
- 现状:这类开发者已经具备深厚的基础,甚至让同事感到不适。他们面临的不再是技术追赶,而是人际摩擦和领地意识。
- 核心工作:不再是编码或追赶 AI 工具,而是耐心、领导力,以及学习如何缓慢地引导变革,让他人能够跟上而不感到被抛弃。
关键要点
- AI 削弱批判性思维:过度依赖 AI 代理会导致开发者与被生成代码之间的距离拉大,从而丧失在架构层面发现潜在问题的能力。
- 技能萎缩是普遍现象:从“大三墙”现象到行业性的“技能萎缩”,开发者因让 AI 处理基础工作而在面对复杂问题时缺乏后备知识。
- 阶段不可跳跃:技术判断力源于解决真实问题的痛苦经历。Code-First 开发者尚未经历 Best Practice-First 阶段带来的痛点(如测试维护),因此无法真正理解最佳实践的价值。
- AI 提升了行业门槛:AI 代理能够执行规范驱动和契约优先等高级任务,这意味着市场开始要求开发者具备 Best Practice-First 级别的能力,而不仅仅是 Code-First 的工具使用能力。
- 正确的 AI 使用策略:
- 自己编写代码,而非完全依赖生成。
- 使用伪代码进行思考,再让 AI 实现。
- 遵循“不可外包原则”:绝不要求 AI 实现你自己无法独立完成的逻辑。
- 高阶开发者的新挑战:对于 Value-First 开发者,核心挑战已从技术执行转向领导力、耐心以及推动组织变革的能力。
意义与影响
招聘与市场标准的转变
面试难度正在增加。过去,“我会 JavaScript”或“我用过 React”足以证明 Code-First 能力。但现在,由于 AI 代理可以执行 Best Practice-First 阶段的任务,市场开始为“知道工具为何存在、解决什么问题以及何时不使用”的能力定价。这意味着仅会调用工具的开发者竞争力下降,而具备架构判断力的开发者价值上升。
个人职业发展的警示
对于初级或中级开发者,盲目使用 AI 代劳是一种“伪加速”。它掩盖了基础技能的缺失,导致在遇到复杂架构问题时陷入困境。真正的加速来自于快速夯实基础,通过解决真实问题来培养技术判断力。
行业文化的影响
随着 AI 工具普及,开发者需要重新定义“熟练”的标准。行业正从单纯的工具使用能力,转向对批判性思维、架构设计和伦理判断力的要求。同时,资深开发者需要承担更多的导师和变革推动者角色,帮助团队适应新的工作流,避免因技术断层导致的组织摩擦。
应对策略
- 自我诊断:明确自己处于哪个阶段(Code-First, Best Practice-First, 还是 Value-First)。
- 调整 AI 使用比例:Code-First 开发者应大幅减少 AI 在核心逻辑生成中的占比,增加手动编码和测试编写的时间。
- 重视基础:不要跳过测试、依赖注入、架构设计等基础环节,这些是应对 AI 时代技术债务的基石。
- 培养领导力:对于资深开发者,重点应放在如何引导团队适应 AI 辅助工作流,而非单纯的技术提升。
