Agentic Coding Is a Trap

代理式编程是一个陷阱

Remaining vigilant about cognitive debt and atrophy. 警惕认知债务与能力退化。

“AI does the coding, and the human in the loop is the orchestrator.” This is the sentiment being hyped up around the industry currently: traditional coding is all but dead, and Spec Driven Development (SDD) is the future. You generate a plan, and disconnect from writing any code. The agents know better, and handle all the implementation. You are there as the expert, to provide “good taste”, review the outputs, and constantly steer the agent(s) to execute the plan that you meticulously put together. “AI 负责写代码，人类在回路中担任编排者。”这是目前行业内大肆炒作的一种观点：传统编程已死，规范驱动开发（SDD）才是未来。你只需生成一个计划，然后脱离具体的代码编写工作。AI 代理比你更懂，它们负责处理所有实现细节。而你作为专家，负责提供“品味”、审查输出，并不断引导代理去执行你精心制定的计划。

The workflow takes many shapes at this point, but in general, it is a process where someone defines the project’s requirements (simultaneously at a micro and macro level), generates a plan, and then pulls the slot machine lever over and over, iterating and reiterating with often multiple agent instances until it’s done. All the while, putting a growing distance between the “orchestrator” and the code that is being generated and committed. 这种工作流目前有多种形式，但总的来说，它是一个定义项目需求（同时兼顾微观和宏观层面）、生成计划，然后不断拉动“老虎机拉杆”的过程——通过多个代理实例反复迭代，直到任务完成。在此过程中，“编排者”与实际生成并提交的代码之间的距离越来越远。

Coding Agents are helpful, and powerful, but there’s already some quantifiable trade-offs that need to be discussed: 编程代理确实有用且强大，但已经出现了一些需要讨论的可量化权衡：

• An increase in the complexity of the surrounding systems to mitigate the increased ambiguity of AI’s non-determinism.
• 为了缓解 AI 非确定性带来的模糊性，周边系统的复杂性增加了。
• Atrophying skills for a wide swath of the population.
• 广大从业者的技能正在退化。
• Vendor lock-in for individuals and entire teams (Claude Code outages have already had entire teams at a stand-still).
• 个人和整个团队的供应商锁定（Claude Code 的宕机已经导致整个团队陷入停滞）。
• Fluctuating and increasing costs to access the tools. An employee’s cost is fixed; tokens are a constantly moving target.
• 使用这些工具的成本波动且不断上升。员工的成本是固定的，而 Token 成本却是一个不断变动的目标。

Being successful with this approach to coding agents hinges on a rather crucial element: only a skilled developer who’s thinking critically, and comfortable operating at the architectural level, can spot issues in the thousands of lines of generated code, before they become a problem. 要成功运用这种编程代理方法，关键在于一个核心要素：只有具备批判性思维、且能从容应对架构层面工作的资深开发者，才能在成千上万行生成的代码中发现问题，并在它们酿成大祸之前将其解决。

Yet, in an ironic twist of fate, it’s the individual’s critical thinking skills and cognitive clarity that AI tooling has now been proven to impact negatively. 然而，讽刺的是，事实证明 AI 工具恰恰对个人的批判性思维能力和认知清晰度产生了负面影响。

Not Just Another “Abstraction”

不仅仅是另一种“抽象”

A common refrain we hear in the community is that programmers are just “moving up the stack” and into a different type of abstraction. Whether or not these tools are really an abstraction layer in the first place is not a settled matter; a higher level of ambiguity is not a higher level of abstraction. 社区中常听到的一种说法是，程序员只是在“向上移动技术栈”，进入了一种不同类型的抽象。但这些工具是否真的属于抽象层尚无定论；更高程度的模糊性并不等同于更高程度的抽象。

If we put that to the side though, it is true that programmers tend to be wary of new languages and new ways of programming. When FORTRAN was released, programmers were skeptical of it, too. They had similar claims: it was likely to introduce more bugs and instability, and writing assembly directly was more efficient. Later, there would be discourse around the integration of compilers introducing too much “magic” into the process. These were normative arguments around a fear of what might be lost if these new technologies were embraced. 撇开这一点不谈，程序员确实倾向于对新语言和新编程方式保持警惕。当 FORTRAN 发布时，程序员也曾持怀疑态度。他们当时也有类似的论调：它可能会引入更多的 Bug 和不稳定性，直接写汇编效率更高。后来，关于编译器集成引入过多“魔法”的讨论也层出不穷。这些都是基于对拥抱新技术可能带来的损失的恐惧而产生的规范性论点。

The difference with what is happening today is that those previous fears were speculative and theoretical. In just the short few years that AI tooling has existed, we are already seeing significant impacts. These aren’t just junior developers, but even those with a decade (or more) of experience: 与今天发生的情况不同的是，以前的那些担忧大多是推测性和理论性的。而在 AI 工具存在的短短几年里，我们已经看到了显著的影响。受影响的不仅是初级开发者，甚至包括拥有十年（或更久）经验的资深人士：

• Junior developers are faced with an even steeper climb, as we truncate their ability to work with code and replace it with reviewing generated code. Reviewing code is important, but it’s only 50% of the learning process, at best. Without the friction and challenges that come with working with code directly, their ability to learn is seriously diminished.
• 初级开发者面临着更艰难的攀登，因为我们削减了他们直接处理代码的能力，取而代之的是审查生成的代码。审查代码固然重要，但充其量只占学习过程的 50%。没有直接处理代码所带来的摩擦和挑战，他们的学习能力会严重受损。

Studying this phenomenon takes time, so anecdotal evidence is important to gather to get a real-time view of the situation. But it has also been studied, and there are numerous reports reinforcing that this is a real phenomenon. 研究这一现象需要时间，因此收集轶事证据对于实时了解情况至关重要。但该现象也已被研究，大量报告证实这是一个真实存在的问题。

It actually is different this time.

这次确实不一样。

When a C++ developer moved to Java or Python, they didn’t complain of brain fog. When a sysadmin moved to AWS, they didn’t feel like they were losing their ability to understand networking. 当 C++ 开发者转向 Java 或 Python 时，他们不会抱怨大脑迟钝。当系统管理员转向 AWS 时，他们也不会觉得自己在失去理解网络的能力。

A Senior Engineer losing their coding edge and becoming “rusty” over time as they move into managerial roles and practice coding less is not a new phenomenon. This was the natural progression of expertise: an engineer who had decades of coding, friction, and experience logged would have the time and experience to solidify those skills and wisdom. And they could apply that wisdom when their job became less about syntax, and more about higher-level architectural decisions. Those individuals are not only exceedingly rare, but you won’t get the next wave of seniors if we’re all abdicating the friction of writing, problem-solving, and debugging. 资深工程师在转向管理岗位、减少编码实践后，随着时间推移失去编码敏锐度并变得“生疏”，这并不是什么新鲜事。这是专业能力的自然演进：一位拥有数十年编码、摩擦和经验积累的工程师，有足够的时间和经验来巩固这些技能和智慧。当他们的工作不再侧重于语法，而是转向更高层级的架构决策时，他们就能运用这些智慧。这类人才不仅极其稀缺，而且如果我们都放弃了编写、解决问题和调试所带来的摩擦，我们将无法培养出下一代资深工程师。

What is happening right now is a trend where developers, who’ve never had that longevity or the 30+ years of friction that led to that deep understanding, are being moved into higher-level workflows requiring the same skills to manage the AI agents that the senior engineer took decades to obtain. 目前发生的情况是，那些从未经历过长期磨练、没有 30 多年摩擦以积累深厚理解的开发者，正被推向更高层级的工作流。这些工作流要求他们具备资深工程师耗费数十年才获得的技能，才能去管理 AI 代理。

However, Senior Engineers aren’t immune, either. Simon Willison, a developer with nearly 30 years experience, has reported not having a “firm mental model of what the applications can do and how they work, which means each additional feature becomes harder to reason about.” 然而，资深工程师也无法幸免。拥有近 30 年经验的开发者 Simon Willison 曾表示，他无法建立起“关于应用程序能做什么以及如何工作的稳固心理模型，这意味着每一个新增功能都变得更难推导。”

The “Skilled” Orchestrator Problem

“熟练”编排者的问题

Buried in a recent study by Anthropic was a surprisingly honest moment when speaking about the risks of engaging with coding agents on a regular basis: Anthropic 最近的一项研究中隐藏着一个令人惊讶的坦诚时刻，谈到了定期使用编程代理的风险：

“One reason that the atrophy of coding skills is concerning is the ‘paradox of supervision’ … effectively using Claude requires supervision, and supervising Claude requires the very coding skills that may atrophy from AI overuse.” “编码技能退化之所以令人担忧，原因之一在于‘监督悖论’……有效地使用 Claude 需要监督，而监督 Claude 又恰恰需要那些可能因过度使用 AI 而退化的编码技能。”

Sandor Nyako, Director of Software Engineering at LinkedIn who oversees 50 engineers, has noticed it proliferating throughout the organization and requested his team not to use them for “tasks that require critical thinking or problem-solving.” 领英（LinkedIn）负责 50 名工程师的软件工程总监 Sandor Nyako 注意到这种现象正在整个组织内蔓延，并要求他的团队不要将这些工具用于“需要批判性思维或解决问题的任务”。

“To grow skills, people need to go through hardship. They need to develop the muscle to think through problems,” he said. “How would someone question if AI…” “为了提升技能，人们需要经历磨难。他们需要锻炼出思考问题的肌肉，”他说。“如果 AI 出错，一个人又该如何去质疑它……”