“每一个独立贡献工程师，现在其实都是一线经理。”这句话来自LaunchDarkly的CTO Cameron Etezadi，他曾担任IBM的工程副总裁。他对The New Stack表示，AI不仅改变了软件工程师的工作方式，更彻底颠覆了这个岗位的底层逻辑——他甚至认为，独立贡献者这个角色已经不存在了，即使是刚出校门的毕业生，实质上也是前端管理者。

这个判断并非孤例。Gartner最新的研究预测，到2029年，60%的企业将拥有规模更小的软件工程团队。小到什么程度？Gartner首席分析师Aliyah Camacho给出的答案是“微型团队”，两到三名工程师足矣。如果这个预测成真，软件开发将进入一个前所未有的精兵时代。

打开网易新闻 查看精彩图片

Etezadi进一步解释，如今成为优秀工程师所需的技能，其实就是优秀管理者需要的能力，核心是项目规划和跨团队协调。他主张，公司应当像评估一线经理那样去评估工程师的工作产出。这意味着，写代码这件事本身，在岗位评价体系中的权重正在发生结构性位移。

但这里藏着一个根本性的分歧：当角色定义被改写，我们到底该怎么衡量“生产力”？AI编码工具已经无处不在，科技巨头们高调宣称这是不可争议的未来。可帮助工程师更快地产出更多代码，真的等同于更高的生产力吗？Citizen Health的CTO Daniel Wang给出了明确否定的回答，他曾在Uber担任工程总监。“软件的存在是为了解决问题。如果AI让我们交付10倍的代码，但客户成果没有改善，那我们并没有变得更有效率。”

Wang指出，问题出在大多数公司追踪的信号本身就错了。当前行业普遍盯着的指标，用AI测量平台Larridin创始人、前Coinbase工程负责人Ameya Kanitkar的话说，是一些“看得见但无关紧要的活动”——比如代码行数、合并的PR数量之类的版本数据。这些东西可以量化，却回答不了最核心的问题：我们到底做对了决策没有？代码真的解决了客户的麻烦吗？

Wang主张，工程师效率的评估重心必须转移到决策质量和最终成果上，也就是“代码存在之前和之后发生的一切”。他列举了几个值得追踪的硬指标：从想法到上线的周期时间、回滚率、逃逸缺陷数量，以及系统可靠性。与此同时，他提醒技术领导者要多问几个定性的问题：“我们选对方案了吗？”“这段代码是否切实解决了客户的问题？”

这些标准听起来像是理所当然的常识，然而现实中，大部分公司并没有在这里投入注意力。当AI让编码的门槛骤降、让交付速度飙升，追踪真正重要的事情反而变得更难了。一个诡异的现象正在浮现：我们拥有了前所未有的代码生产能力，却说不清自己是不是变快了，更说不清自己是不是做对了。