如果你最近逛过 Hacker News 或者开发者论坛，大概率见过这种论调：
"AI 编程工具让初级开发者写代码太快了，他们根本不理解自己在写什么。五年后，这群人只会写 prompt。"
这个观点听起来很有道理。但我觉得它问错了问题。
真正的问题不是"会不会写代码"
计算器发明的时候，数学老师也担心学生会丧失心算能力。后来呢？学生的心算确实差了，但花在高级数学建模上的时间变多了。
AI 编程工具在做同一件事：把开发者从 boilerplate 代码里解放出来。
真正的问题是：代码 review 的质量在下降。
当 AI 能在 30 秒内生成 200 行代码，review 的人有多少耐心逐行检查？大多数情况下，跑一遍测试，通过了就 merge。
这带来的风险是隐性的。AI 生成的代码在 happy path 上跑得很好，但 edge case 的处理往往薄弱。这些薄弱点，只有在生产环境才会暴露。
我自己的体验
我自己的工作流已经大量使用 Claude Code。但我的用法不是"写完就交"。
省下来的时间，我拿去做两件事：
第一，读 AI 生成的代码。不是扫一眼，是真的读。不理解的地方，追问 AI 为什么这么写。这个过程本身就是学习——你会发现 AI 用的某些模式，自己以前没想到过。
第二，把精力花在系统设计上。以前写一个功能，70% 的时间在敲代码，30% 在想架构。现在反过来了。
角色变了，但核心的判断力——这才是开发者真正的价值——不仅没退化，反而更重要了。
公司层面的风险
一个团队如果大量依赖 AI 生成代码，短期内产出确实会飙升。
但长期来看有两个隐患：
知识传承断裂了。 资深开发者离职后，留下的 AI 生成代码对新人来说是黑箱——没人知道当初为什么这么写。
调试成本转移了。 以前写代码时犯的错，写的时候就发现了。现在 AI 替你写，错误在运行时才暴露，定位成本翻倍。
GitHub 自己的调查显示，使用 Copilot 的开发者接受 AI 建议的代码比例超过 40%。你写的代码里，每 10 行有 4 行不是你写的。
这本身不是问题。问题是那 4 行你有没有真的理解。
给用 AI 写代码的人一个建议
每段 AI 生成的代码，至少读两遍。第一遍看它在做什么，第二遍想它为什么这么做。
多花的 5 分钟，可能在未来某个凌晨 3 点的紧急 bug 里救你一命。
五年后，"会写代码"不再是稀缺能力。"知道该写什么代码"才是。
主要来源：
- GitHub Copilot 用户调查数据（AI 代码接受率 40%+）
- Hacker News: "Why senior developers fail to communicate their expertise" (361 points)
- 个人 Claude Code / Cursor 使用体验