「只写代码」曾经真的算一份工作。传统的研发流水线里，需求有人写，界面有人画，测试也有人做，研发的角色基本就是把需求翻译成代码、提交、下班。这样一种清晰到近乎舒服的分工，正在以肉眼可见的速度瓦解。
写代码这件事，正被一块块拆走
最先被抽走的，是那些黏在编码周围的零碎活。工程师用 AI 写代码时顺手让模型补好注释，写完再让模型把文档总结出来；有些团队已经要求产品用 Vibe Coding 直接产出可交互的 Demo，拿去跟前端对接，原型图那一步被跳过了。
写查询的岗位也在收缩。运营和财务发现，让模型跑一条 SQL 比提需求、等数据组排期快得多，原本归数据小组的活正一点点被分走。测试和代码迁移更早被盯上：补用例、跑回归，比养一个专职测试便宜；老系统换语言，过去要一个团队搬大半年，现在丢给模型搬，留一个人盯结果就够。这些活原本都算「写代码」的一部分，如今正一块一块被单独拎出来，交给 AI。
三年的争论，结论早就定了
2024 年，GitHub Copilot 上线都好几年了，圈子里还在吵「AI 到底能不能写代码」。
2025 年，问题变成了「AI 写的代码能直接上线吗」。
到了今年，没人再问了。因为答案太明显：能。当「能不能」不再是问题，真正的问题变成了——如果 AI 能把代码写出来，那「只负责写代码」的人，还剩下什么？
市场给了一个拧巴的答案：AI 回旋镖
最近流传很广的一个梗是，不少企业把裁掉的程序员又请了回来，理由是发现 AI 不会「欠薪」。
我认真追了下源头，发现这不完全是段子。CNBC 七月初的报道提到，福特正在重新召回数百名资深工程师，原因是自动化系统解决不了质量问题。圈内把这种现象叫「AI 回旋镖」：前面砍掉的人，后面又飞回来。
根子在于 AI 干不彻底。
模型写代码很快，但判断、验证、救火这些事它干不利索。越是要到生产环境里、只有真实日志才能暴露的 bug，它越没招。这是结构性的——无论模型怎么进化，都绕不开「没在生产现场就看不到现场的问题」这件事。
对企业组织还有一条更扎心的逻辑：AI 的工资是 Token 算力费，充值一断就直接停工，一分钱都拖不得；人不一样，人的工资可以缓一缓，这个月资金紧，下个月再发，人往往还会继续干活。企业当初裁员，是算准了 AI 更便宜、更听话；现在把你叫回来，一半是因为 AI 真干不完，另一半是因为你虽然不一定比 AI 便宜，但能跟公司共进退。
自举的 AI，最贵的是验证
Claude Code 的负责人前段时间做了一件挺酷的事：让 Claude 去重写 Claude 自己的应用界面。AI 写 AI，听起来已经自举了。
但如果你去看他的复盘，着墨最多的不是生成，而是他花在验证上的时间。模型吐出一堆代码，他得逐行判断哪些对、哪些错，其中还有不少「看起来对但逻辑有坑」的部分。模型一分钟生成的东西，他可能要花一个小时才能确认它是对的——代码能跑，不代表逻辑正确；逻辑正确，也不代表符合设计意图。
这让人想起一句更老的金句。Fred Brooks 在《人月神话》里说过：给一个已经延误的项目加人，只会让它更延误。因为新人带来沟通成本，而沟通网络的复杂度随人数平方级增长。给项目加 AI 也是一个道理：产能确实上来了，可每一行代码都要人校对，验证成本跟着平方级往上涨。
快是有代价的。AI 把「写」这个动作加速了十倍，「判断」的分量也跟着涨了十倍。
当 KPI 还在数 commit
这个行业长期用代码行数、commit 次数、PR 数量来定义「工作量」。这些数字跟产品好坏、跟解决问题、跟创造价值，关系都不大，它们只是好量化，所以好考核。
可当一行代码既可能是人写的、也可能是 AI 写的，数数还有什么意义？AI 把写代码压缩到一两个小时，剩下的时间全在判断、验证、跟人掰扯需求。而面试还在考算法题，绩效还在数提交次数。有意义吗？
我是怎么重新定义这一年的
我自己的习惯是，绝大多数想法都是先跟 AI 聊出来的。睡前冒出一个念头，第二天丢给模型，让它拆成问题，我一个个答，答着答着项目就成形了。练的是我自己判断需求、定义问题的能力。
我是从产品和项目侧过来的，前后端都懂一点，写代码并不是我的主业。今年借着 AI 把代码这头也接上了：过去验证一个想法要排开发、等排期，现在自己就能把原型敲出来。因为产品感重，我的延伸方向是「售前解决方案加代码」——能跟客户把方案讲明白，回头还能自己把原型做出来。
代码反而成了整条链路里最好办的一步。
被代码填满的时间空出来之后，我拿来搭自己的技能管线：AI 干重复的活，我去读文档、看别人怎么拆产品、翻行业报告。以前一年都看不完的东西，现在几个月能过一遍。关键是把 AI 当成你的专家助理，别让它替你到处开花，把眼光收回到一个具体场景、一个具体产品上，专注下来。我做的事，早就不再叫「写代码」了。
几个挪动能力的思路
如果你是写代码的，可以借 AI 把能力树往外挪：从后端挪到前端，再往产品经理那一摊走，方向是「决定写什么」，而不只是「把写好的东西写出来」。
如果你是做产品、做项目的，可以往「售前解决方案加代码」走，我自己就是这么干的。
真正难的是接下来这个问题：你的工作该怎么重新定义？这个答案 AI 给不了你。它只会替你做掉「已经被定义好的」那部分，而定义本身，得你自己来。
一句话总结
「只写代码」不会回来了。被抽走的，是那些能被清晰定义、交给机器执行的环节；留下来、也最值钱的，是决定写什么、判断写得对不对、在 production 里救火的那部分。AI 接得住「写」，接不住「想」和「担」。 redefine 你的工作，而不是等它被重新定义。