AI 增强型 vs AI 依赖型 — 程序员分化
What it is
AI 正在将程序员分为两类。AI 增强型开发者先形成自己的判断，再用 AI 放大能力；他们批判 agent 输出、保持对公共沟通的作者身份、在 bug 调查中用人类 expertise 缩小搜索空间。AI 依赖型开发者直接接受 AI 输出、跳过思考步骤，将判断和沟通一并外包。
这种分化的核心不是「用不用 AI」，而是**「哪些决策仍由人类保留」**。
Why it matters
失业是外部事件，认知退化是内部过程。使用 AI 越方便，越容易跳过思考步骤，而「方便」本身成为最大的陷阱。
Staff engineer 的实战数据提供了具体的行为边界：agent 可以生成全部代码变更，但人类必须做编辑审查；agent 可以诊断 80% 的 bug，但人类 expertise 负责从 14 次失败会话中逐步缩小搜索空间；agent 可以写单元测试和本地环境配置，但 UI 测试和架构设计仍需要人类判断。PR 描述、Slack 消息、ADR 和博客文章则应保持人类作者身份——这些沟通不是信息传递，而是信任信号。
Key points
- 先判断，再放大：增强型开发者在提问前已形成自己的假设，AI 的作用是验证和加速，而非替代思考
- 明确的「不外包清单」：公共沟通（PR 描述、Slack、ADR、博客）保持人类作者身份，因为它们是信任和责任的载体
- Bug 调查的最优分工：agent 擅长自主诊断（约 80% 成功率），但人类通过补充日志上下文、建立复现、反驳错误假设来提升最终成功率
- 测试与设置是「便宜」的委派对象：单元测试和本地环境配置可以大量交给 agent，但 UI 测试和架构设计需要人类品味
- 拒绝率是质量信号：staff engineer 平均拒绝五六个 agent 尝试后才接受一个，这种快速筛选是 harness 能力的体现
- Harness 能力即竞争力：增强型 = harness 能力强；依赖型 = harness 能力弱
Evidence across sources
| Source | Key Claim | Relevance |
|---|---|---|
| 微软首席工程师经理访谈 | AI 将程序员分为增强型（先思考再问）和依赖型（直接要答案）；认知退化比失业更危险 | 企业视角：招聘应区分两类人才 |
| Sean Goedecke — How I use LLMs as a staff engineer in 2026 | 从「偶尔使用 agent」到「持续轻监督使用」；agent 生成全部代码但人类编辑审查；公共沟通不外包；bug 调查 80% 自主诊断率；拒绝五六个尝试后才接受一个 | 个人实践：增强型的具体操作边界和度量 |
Open questions
- 如果招聘无法区分增强型和依赖型，企业是否会系统性低估 AI 时代的真实技能？
- 「不外包清单」在不同角色（工程师、PM、设计师、作家）中应该有何不同？
- 当 agent 能力继续提升，增强型与依赖型的分界线会向上移动还是消失？
- 年轻开发者是否更容易成为依赖型，因为他们缺乏「先形成判断」的肌肉记忆？
Prompts for witness
- 自检：今天使用 AI 时，是先思考再问，还是直接问？哪些场景中我跳过了思考步骤？
- 如果必须列出 3 项「永远不外包给 AI」的工作内容，你会选什么？为什么？
- Sean Goedecke 说「我通常拒绝五六个 agent 尝试后才接受一个」。你的拒绝率是多少？你多久检查一次 agent 的输出？
- 在哪些场景中你发现 agent 的「正确」输出反而让你变懒了？
Related
- harness-engineering/overview — Harness Engineering 总览
- harness-engineering/lou-tiancheng-harness — 楼天城的 Harness 观点
- product-trends/ai-operator-role — 企业 AI 落地角色
- claude-code/overview — 编码 agent 的工作流设计