文章一：Agentic Coding is a Trap

核心观点

  • 反对把 coding agent 当成默认主流程，不反对 AI 本身。
  • 真正的问题不是“抽象层升级”，而是开发者与代码之间的距离被快速拉大。
  • AI 代理越需要强监督，就越依赖人的编码判断；但过度使用 AI 又会削弱这种判断力，形成悖论。
  • 大规模 agentic coding 还会带来 vendor lock-in 和 token 成本失控。

作者担心的损失

  • 编码、调试、问题拆解等核心能力萎缩。
  • 初级开发者少了“直接与代码摩擦”的成长过程。
  • 高级开发者也会失去对系统的稳定心智模型。
  • 团队对模型供应商形成流程依赖，服务波动会直接卡住生产。

作者给出的实践原则

  • 让 AI 做辅助，而不是做主导。
  • 用 AI 生成 spec、plan、伪代码、研究材料，但实现过程保持人深度参与。
  • 一次只生成自己能完整 review 的代码量。
  • 不把自己完全不会的事交给 agent 黑箱完成。

文章二：What do we lose when AI does our work?

核心观点

  • AI 不只是减少执行摩擦，也绕过了“任务启动”本身。
  • 但任务启动不只是开始做事，而是同时包含承诺、身份认同、上下文装载、目标澄清与风险承担。
  • 当这些过程被 AI 跳过后，产物虽然出来了，人却更容易与工作脱节。
  • 这种“不是我亲手长出来的成果”的感觉，会削弱意义感，甚至带来一种轻微空心化。

作者担心的损失

  • 对工作的 ownership 下降。
  • 对任务的情感投资减少，意义感变弱。
  • AI 倾向于生成“中位数答案”，容易让人过早放弃本来值得深挖的想法。
  • “开始”变便宜了，但“真正完成并认领成果”反而更难。

作者给出的实践方式

  • 对不重要、无须投入自我的任务，尽量放心交给 AI。
  • 对真正重要的任务，先自己启动，再让 AI 做 thought partner 或 editor。
  • 保留“这是我的作品”那段不可替代的摩擦过程。

两文共识

  • AI 最危险的地方，不是错误，而是让人逐渐失去能力与参与感。
  • 速度不是唯一指标，理解、判断、ownership 更稀缺。
  • 对重要工作，AI 更适合做副驾驶，而不是替身。
  • 真正长期有价值的，不是“把人排除出流程”，而是“让人保留判断与投入”。

两文差异

  • Lars Faye 更偏工程治理：代码理解、调试能力、成本、组织依赖。
  • Ricky Yean 更偏心理体验：启动能量、意义感、人与作品的连接。
  • 前者关注“人会不会变弱”，后者关注“人会不会变空”。

我自己的简短结论

  • 这两篇文章都不是反 AI，而是反“把 AI 默认设为主脑”。
  • 如果任务核心价值在于效率，AI 应该尽量接手。
  • 如果任务核心价值在于思考、判断、创造与成长，人必须保留第一手参与。
  • 一个实用原则是：把 AI 用在加速理解、润色表达、扩展选项上，而不是直接替代形成理解本身。

可记住的一句话

  • 对重要工作：先自己进入问题，再让 AI 放大你；不要先让 AI 替你做完，再由你回头认领。