对认知债务与能力退化保持警惕。
“AI 负责写代码，人类则作为在环中的协调者。”
这是当前行业中被大力鼓吹的一种观点：传统编程几乎已经走向终结，而规格驱动开发（SDD）才是未来。你只需要生成一份计划，然后完全脱离代码编写。智能代理更懂，它们会处理所有实现细节。你作为专家的角色，是提供“良好的品味”，审核输出结果，并不断引导这些代理去执行你精心制定的计划。
这种工作流程目前有多种形式，但总体而言，它通常是这样一个过程：某个人定义项目需求（同时涵盖宏观与微观层面），生成计划，然后像拉老虎机一样不断重复操作，通过多次迭代、甚至多个代理实例反复尝试，直到完成。在整个过程中，“协调者”与实际生成并提交的代码之间的距离越来越远。
编码代理确实强大且有用，但已经出现了一些可以量化的权衡问题，值得认真讨论：
为应对AI非确定性带来的模糊性，周边系统复杂度显著增加；
大量人群的技能正在退化；
个人与团队面临供应商锁定（例如 Claude Code 宕机时，整个团队停摆）；
使用这些工具的成本波动且不断上升——员工成本是固定的，而 token 成本却难以预测；
这种模式能否成功，取决于一个关键前提：必须由具备批判性思维、能够从架构层面理解系统的熟练开发者来识别成千上万行生成代码中的问题，并在问题扩大之前加以修正。
然而，具有讽刺意味的是，AI 工具已经被证明会削弱个人的批判性思维能力和认知清晰度，而这些正是成功使用编码代理所必需的能力。
这不仅仅是“另一种抽象”
社区中常见的一种说法是：程序员只是“向更高层抽象移动”。但这些工具是否真的属于抽象层仍存在争议——更高的不确定性并不等同于更高的抽象层级。
当然，程序员历来对新语言和新编程方式持谨慎态度。例如 FORTRAN 刚发布时，也遭到质疑，人们认为它可能带来更多错误，直接写汇编更高效。后来编译器的引入也曾被批评为增加了“魔法”。这些担忧大多是基于对未知的恐惧，是一种规范性判断。
但如今的不同之处在于，这些影响已经不再是理论推测。在 AI 工具出现的短短几年里，我们已经看到了显著的实际影响，而且不仅限于初级开发者，甚至包括拥有十年以上经验的工程师。
编码代理悖论
对于初级开发者而言，学习曲线变得更加陡峭，因为他们与代码直接接触的机会被削弱，转而变成审查生成代码。代码审查固然重要，但它最多只占学习过程的一半。如果缺乏亲自编写代码所带来的摩擦与挑战，学习能力将被严重削弱。
这一现象需要时间研究，但目前已有大量轶事证据和研究报告表明，这确实是一个真实存在的问题。
这一次，确实不同。
当 C++ 开发者转向 Java 或 Python 时，他们并不会抱怨大脑混沌；当系统管理员迁移到 AWS 时，也不会觉得自己失去了对网络的理解能力。
资深工程师随着转向管理岗位而逐渐“生疏”的现象并不新鲜。这是经验积累后的自然结果——他们已经通过几十年的实践建立了扎实的理解，可以在更高层面做架构决策。但这些人本就极其稀少，而如果我们现在普遍放弃编写代码、解决问题和调试的过程，就无法培养出下一代资深工程师。
当前的趋势是，那些尚未经历长期积累、尚未建立深度理解的开发者，被提前推向需要高级技能的工作流程，以管理 AI 代理，而这些技能原本需要数十年才能获得。
甚至资深工程师也无法完全免疫。拥有近30年经验的开发者 Simon Willison 表示，他已经不再拥有对应用能力和运行机制的“清晰心理模型”，这使得新增功能越来越难以推理。
“熟练协调者”的问题
Anthropic 的一项研究中曾坦率指出一个风险：
代码能力退化令人担忧的原因之一在于“监督悖论”——有效使用 Claude 需要监督，而进行监督本身又需要那些可能因过度使用 AI 而退化的编程技能。
LinkedIn 软件工程总监 Sandor Nyako（管理50名工程师）也观察到这一问题正在扩散，并要求团队不要在需要批判性思维或问题解决的任务中使用这些工具。
他说：“技能的成长需要经历困难，人们需要锻炼解决问题的能力。如果没有批判性思维，又如何判断 AI 是否正确？”
此外，“过度使用”的界限也并不清晰。目前已有数据与案例表明，这些技能可能在数月内迅速退化。
这正是一个矛盾：编码代理的使用正在削弱有效使用这些代理所需的能力。
LLM 加速了错误的方向
与当前流行叙事相反，我们并不一定需要更快地写代码，尤其是那些我们并未完全理解、且规模庞大到无法合理审查的代码。
在 AI 出现之前，一个优秀开发者的优先级通常是：
理解代码及其与整个代码库的关系；
确保代码符合规范且高效；
在保证可读性的前提下尽量减少代码量；
开发速度。
而在 Agentic 编程中，这一顺序几乎被完全颠倒，速度被放在首位，而理解与简洁性被弱化。
编程就是思考
有些开发者是通过写代码来思考问题的。编写代码并非机械劳动，而是迫使人从技术角度全面考虑安全性、性能、用户体验和可维护性。
OpenCode 的作者 Dax 表示：
当我处理新的或复杂的问题时，写代码本身就是我理解问题的过程。我很难仅靠写一份完整的规格说明来思考问题。我喜欢写类型、函数交互方式、目录结构，这些都是大多数程序员一直在做的事情，也是我理解问题的方式。
语言表达往往存在歧义，而 LLM 会用假设去填补这些空白，从而导致更多审查、更多迭代、更高成本，以及与实际产出更大的脱节。
供应商锁定
在一次 Claude 宕机期间，许多开发者和团队完全停摆，因为他们已经高度依赖这些工具。原本只需键盘和编辑器就能完成的工作，如今却依赖 AI 订阅服务。
token 成本无法预测，模型不断变化，使用成本可能大幅波动。如果整个团队都依赖这种工作方式，支出将变得极不稳定。
这可能导致一种新的行业锁定：完成原本依赖自身能力的任务，现在需要持续支付费用。
研究也显示，调试能力下降了47%。开发者倾向于依赖 AI 快速完成任务，而忽视关键技能的培养。
如何应对
LLM 本身是强大的工具，如果使用得当，可以极大促进学习和能力提升。关键在于如何使用。
作者的建议是：降低 AI 的角色，将其作为辅助工具，而不是主导工具。
他的实践方式包括：
用 LLM 生成计划，但由自己主导实现；
编写伪代码以缩小理解差距；
将 LLM 用于辅助生成、文档查询和研究；
控制生成代码的规模，确保可审查；
不让 LLM 完成自己完全不理解的任务。
总结来说：像使用“船上的计算机”一样使用 AI，而不是让它成为主导者。
结语
AI 提高了生产力，但也可能削弱理解能力。历史已经多次证明，技术进步伴随着不可预见的后果。
如果将思考完全外包给机器，人类将停止成长与学习，最终被取代。