乐于分享
好东西不私藏

AI 还没替代程序员,大厂工程师先开始刷 Token 了

AI 还没替代程序员,大厂工程师先开始刷 Token 了

前文

最近看了个有意思的访谈:AI Engineer 对 Gergely Orosz 的现场访谈。Gergely 他曾在 Uber、Skyscanner 工作,也是 The Pragmatic Engineer 的作者,访谈见:https://www.youtube.com/watch?v=CS5Cmz5FssI。

我喜欢这篇访谈的地方,是它没有继续聊那种已经被说烂的问题,比如 AI 会不会取代程序员,程序员还值不值钱。Gergely 真正讲到的是另一件更真实的事,AI 进了公司以后,最先改变的可能不是代码,而是人的恐惧、公司的指标、老板的焦虑,以及工程师为了证明自己没有落后而做出的各种动 作。它让我觉得,软件工程正在变的不只是工具链,而是整套组织心理。这个角度比单纯讨论 Claude Code 能不能写代码,有意思多了。

代码还没被改变,恐惧先变了

以前公司衡量工程师,看代码行数、看 PR 数、看 commit 数、看千行代码 Bug 率。大家都知道这玩意很蠢,你写一千行垃圾代码,不会比别人删掉五百行垃圾代码更有价值。你一天提十个没意义的小 PR,也不代表你真的比别人更能解决问题。

但只要一个数字被摆出来,只要它可能和绩效、晋升、裁员、老板印象发生关系,人就会开始围着它转。这次轮到 token 了。

Gergely 说,他在社交媒体上聊到 token maxing 后,很多大公司的人来找他说,自己公司里已经出现了类似现象。Salesforce 有人能查到每个人在 AI 上花了多少钱。Meta 里面,AI 使用量可能会被放进绩效评估的若干参考项里。Microsoft 有人为了把排行榜数字做高,让 agent 在后台跑一些没有价值的东西。

更赛博的是,有的人不直接读文档了,而是让 Claude Code 或者公司内部 agent 去总结,再来回问几轮。答案好不好不重要,token 上去了。

这尼玛就很赛博。

以前我们说一个人上班摸鱼,是打开网页假装工作。现在更高级了,你可以让 AI 假装你在努力工作,而且它还真的会留下数据。

最荒诞的地方在于,这些工程师未必真的相信刷 token 有用。他们只是不想落在底部。你想想看,一个大厂工程师,工资很高,房贷很重,家庭责任也在身上。公司又刚刚经历过裁员,周围所有人都在说 AI 重要,老板也在看 AI 使用数据。

这时候你敢不敢赌一句,我就是不用,因为我觉得没价值?很多人是不敢的。我非常理解这种感觉,不是每个人都有资格在公司指标面前潇洒地说,我只对真实产出负责。大部分人更现实,先别被筛出去,先别成为那个看起来没有拥抱 AI 的人,先别站到排行榜最下面。

所以 token maxing 看起来像笑话,其实背后是一种很真实的恐惧。AI 还没真正替代工程师,工程师已经先开始害怕自己看起来不像一个会用 AI 的工程师了。

使用量不等于效果

这块我觉得特别值得聊。过去两年,我们讨论 AI 对软件工程的影响,太容易只盯着能力,Claude Code 能不能修 bug,Cursor 能不能重构,GitHub Copilot 能不能把样板代码补出来,模型上下文够不够长,benchmark 又涨了多少。

但公司不是由 benchmark 驱动的。公司是由人驱动的。而人会焦虑,会攀比,会揣摩老板意思,会在不确定的时候先做看起来正确的事。

这也是为什么我觉得 Gergely 这场访谈有价值。它讲的不是 AI 让代码写得更快这么简单,它讲的是,当 AI 进入公司以后,组织内部的激励、恐惧、权力关系,会一起被放大。

说到效率这块,访谈里还有一个很有意思的反差。很多公司领导现在会觉得,工程师怎么还不用 AI。你看 Anthropic,天天说自己越来越多代码是 Claude 写的。你看这些 AI 公司,收入涨得这么快,产品迭代这么猛。那我们公司是不是也应该用起来?

于是领导开始推,要全员使用,要培训,要统计,要有目标。坦率的讲,我完全能理解领导为什么这么做。站在老板视角,如果一个东西可能让公司效率提升一大截,而你的团队还在慢悠悠观望,那确实会急。尤其现在这个时间点,AI 不是一个锦上添花的玩具,它更像一个可能改写竞争格局的变量。

问题是,使用量不等于效果。

这个判断太重要了。

Gergely 提到,早期很多资深工程师不愿意用 Cursor、Claude Code 这类东西,不是因为他们固执,而是因为它们在老代码库里确实没有那么顺手。一个真实的大型代码库,里面有历史包袱,有内部框架,有奇怪约定,有十年前没人敢删的逻辑。这时候你让一个 agent 进来,它不一定能立刻理解上下文。

它可能写得很快,也可能错得很快。资深工程师的直觉是,我自己来可能更稳。这不是抗拒新技术,这是对复杂系统的敬畏。

但领导看到的是另一件事,你没用。你没用,所以你是不是落后。你没用,所以团队是不是错过了机会。你没用,所以是不是该想办法逼大家用。于是指标出现了,排行榜出现了,荒诞行为出现了。

这就是很典型的古德哈特定律,一个指标一旦变成目标,它就不再是一个好指标。以前是代码行数,现在是 token 数。外壳变了,人性没变

工程师不是消失,而是被推到更宽的位置

顺着这个再聊聊,AI 对工程师个人到底有没有帮助。Gergely 的回答我觉得很诚实,对个人,有帮助。对团队,还不一定。

这个判断比很多极端观点舒服太多了。现在网上有两种很吵的声音,一种是 AI 已经无所不能,工程师马上都不用写代码了。另一种是 AI 全是泡沫,除了写 demo 什么也干不了。我自己的感受是,这两边都有点太急。

就像我今天正在改这篇稿子,用的不是一个单纯的文本编辑器,而是让 Codex 帮我读素材、看规则、写新稿、再检查文件。这件事肯定让我更快。但如果你问,Codex 能不能完全替我判断这篇文章该怎么写,哪些地方该保留,哪些情绪是真的,哪些表达会假,不能,至少现在不能。

它能帮我把手变长,但脑子还得我自己长。软件工程也是一样。Claude Code 能帮你写一段实现,能帮你跑测试,能帮你读一个陌生模块。但你要不要这么改,为什么这么改,改了会不会影响旁边三个系统,出了事故谁负责,这些东西还是人要兜底。

所以我一直觉得,AI 对工程师的改变,不是把工程师从写代码的人变成不写代码的人,而是把工程师从单线程干活的人,推向一个更复杂的位置。你要会拆任务,要会给上下文,要会验收,要能识别它什么时候看起来很自信但其实在胡来。你还要知道,什么时候不要用它。

这个要求其实更高了。

很多朋友可能会觉得,那这不就是工程师变成 AI 的管理者了吗?访谈里也聊到这个说法,Gergely 很不认同。他说,如果你真的做过工程经理,就知道这类比不太对。

工程经理要处理人的问题,绩效,冲突,职业发展,情绪,团队信任,沟通成本。这些东西非常重。而你和 Codex、Claude Code、GitHub Copilot 打交道,不需要担心它明天心情不好,不需要一对一谈话,不需要处理两个 agent 互相不爽

更像资深工程师带几个速度很快但经验不稳定的实习生。你给它方向,它马上给你东西。但你不能闭眼收,你要看,要改,要判断,要知道它哪里可能埋雷。

DHH 在另一个访谈里说过一个比喻,Gergely 也提到了,他说这更像穿上机甲。我觉得这个比喻挺准。你还是你,只是你的手臂变多了,力量变大了,行动半径变远了。但机甲不是自动驾驶,你坐在里面,还是得负责。

小团队会更能打,大团队会更焦虑

这也是我觉得很多 AI 编程讨论会跑偏的地方。大家老想找一个终局答案,工程师会不会消失,初级工程师还有没有机会,以后是不是只剩下会 prompt 的人。但真实世界很少这样一刀切。

更可能发生的是,工程师的职责继续膨胀。Gergely 讲了一个历史脉络,我觉得很重要。在 AI 之前,工程师的边界其实已经在扩张。测试曾经是独立角色,后来很多测试责任并进了软件工程师。DevOps 曾经是专门团队,后来很多创业公司要求工程师自己对部署和运行负责。产品判断也在往工程师身上靠,所以这些年才会越来越多人讲产品工程师

AI 只是把这个趋势又推了一把。以前公司希望工程师会写代码,后来希望你会测试,会上线,会监控,会理解业务。现在还希望你会调度 agent,会设计工作流,会把小团队干成大团队。

听着很爽吗?也不一定。这背后其实是压力,团队会变小,期望会变高,初级工程师可能更早被要求像高级工程师一样思考。这话听着有点刺耳但,我觉得这就是正在发生的事。

不是说每个人都马上要变成超人,而是很多公司会越来越默认,一个会用 Claude Code、Codex、Cursor 的工程师,应该能覆盖过去更多人的工作面。这就带来一个很现实的问题,如果你还在用过去的方式定义自己的价值,只说我会写代码,那确实会越来越危险。

但如果你能把 AI 当成一个放大器,去放大你的判断力、产品感、系统理解、沟通能力,那你的价值反而可能更清楚。因为代码本身会越来越便宜,但知道该写什么,为什么写,写到哪里停,出了问题怎么兜住,仍然很贵。

大厂真正重铺的是地下管线

回到大公司这块,我觉得访谈里最让我兴奋的一段,是 Gergely 讲大厂内部正在发生的 AI 基础设施建设。他说,从外部看,你可能没看到 Uber、Airbnb、Meta、Microsoft 这些公司突然发布一堆惊天动地的新 AI 功能。但公司内部其实很热闹。

他们在做自己的后台编码 agent,在接 monorepo,在做 MCP 网关,在把服务发现、on-call、代码评审、风险分类这些内部流程重新接一遍。我看到这里的时候,脑子里冒出来一个词,地下工程。

地面上没什么变化。用户打开 App,还是那个 App。按钮还在那里,页面还在那里。但地下的管线正在被重铺。

这块特别关键。很多人以为 AI 竞争就是看谁的聊天机器人更聪明,谁的产品界面更酷。但对大公司来说,真正值钱的可能是内部系统怎么被 AI 重新接管一部分。

一个通用的 Cursor 再强,它也不知道你公司十年 monorepo 里那些奇怪约定。它不知道哪个服务出了问题应该找谁,不知道哪个内部库看起来废弃了但其实某个老系统还在用,也不知道你们代码评审里哪些改动属于高风险。

这些上下文,只有公司自己有。

所以大公司会做内部定制,不是因为他们闲,而是因为通用工具只解决通用问题,真正的生产力瓶颈往往藏在公司内部那些脏兮兮、乱糟糟、但极其关键的系统里。

这块我是真的觉得有意思。因为它有点像电力刚进入工厂的时候。早期很多工厂只是把蒸汽机换成电动机,布局还是老布局,所以效率提升有限。真正的变化不是把动力源换掉,而是整个工厂围绕电重新设计。

AI 现在也有点像这样。你只是给每个工程师发一个 GitHub Copilot,当然有用,但未必翻天覆地。真正的变化可能是,公司把需求、代码、测试、部署、监控、事故响应、知识库、权限系统,全都重新串起来。到那个时候,它才不是一个插件,它会变成一种新的生产线。

新的时代啊,朋友们。

当然,这里面也有非常现实甚至有点搞笑的一面。Gergely 说,现在公司里只要项目带 AI,就更容易拿资源。以前你是开发者平台团队,想要两个 HC,可能没人理你。但你说我要做 agent experience,诶,预算来了。

这太真实了。每个时代都有自己的资源密码,以前是云原生,后来是大数据,再后来是数字化转型,现在轮到 AI。你可以吐槽它浮夸,但你也得承认,组织就是这么运转的。钱会流向叙事最强的地方,人也会。

Shopify 买的不是工具,是时间

Shopify 的故事就更典型。Gergely 提到,Shopify 在 2021 年很早就拿到了 GitHub Copilot 的访问权限。当时 Copilot 还没正式对外卖。Shopify 的工程负责人听说 GitHub 内部在做这个东西,就去找 GitHub CEO Thomas Dohmke,说我们想全公司用。

对方说这还不卖。Shopify 的意思大概是,我不是问你卖不卖,我们给你 3000 人的真实反馈。

你敢信???

这就是领先公司的味道。它们不是等工具成熟了再用,它们愿意先冲进去,被早期版本折磨,被 bug 折磨,被流程混乱折磨。为什么?因为它们买的是时间。

如果提前半年摸清楚这些东西,提前半年训练组织,提前半年知道哪些坑不能踩,那这半年可能就值很多钱。当然,不是所有公司都该这么干。你如果是一家业务和 AI 关系没那么强的公司,完全可以等等,等工具稳定,等价格下降,等最佳实践出来。没必要为了显得先进,把全公司拖进混乱里。

但 Shopify 不一样。它在科技行业里竞争,它要吸引最好的工程师,它要保持产品速度。对它来说,混乱是成本,也是门票。

我很喜欢这个判断。它没有把 AI 早期采用浪漫化,不是只说,冲啊,未来来了。而是承认,早期采用就是很烦,很贵,很乱,很折腾。但有些公司愿意用这些东西换领先。

这才是真实世界。

真实世界里,创新不是一道光照下来,大家一起鼓掌。真实世界里的创新,经常是有人先忍一堆破事,然后比别人早一点学会怎么活在新环境里。

最稀缺的能力可能是清醒

说到这里,我反而觉得这场访谈最值得带走的,不是某个具体结论。不是 token maxing 很蠢,不是工程师要学会用 agent,也不是大公司都该做 MCP 网关。

而是一个更朴素的判断,AI 进入软件工程以后,最先被改变的可能不是代码,是组织的心理结构。

老板会焦虑,不知道自己公司是不是落后。工程师会焦虑,不知道自己是不是看起来不够 AI native。平台团队会兴奋,因为终于有理由重做那些早就该重做的内部系统。创业公司会兴奋,因为小团队能做更多事。大公司会矛盾,一边害怕浪费钱,一边害怕不浪费这笔钱就被别人超过。

每个人都在重新找位置。

这才是最有意思的部分。技术本身当然重要,模型能力当然重要。但你把一个新技术丢进真实组织里,它不会按照论文里的方式展开。它会撞上绩效,撞上预算,撞上招聘,撞上裁员,撞上老板的焦虑,撞上员工的自保。

最终长出来的东西,往往比技术本身更复杂。

这也是为什么我越来越觉得,理解 AI,不能只看模型。还要看人,看公司怎么用它,看人怎么误用它,看指标怎么扭曲它,看恐惧怎么推动它,看好奇心又怎么把它带到一些很奇怪但很有生命力的地方。

我自己也还在摸索。说实话,很多时候我也不知道某个工作流到底是不是最优。今天觉得 Codex 这样用很爽,明天可能又发现 Claude Code 另一种用法更顺。今天觉得多 agent 并行很酷,明天可能发现自己根本验收不过来。

这玩意就是这样。它不是一门看完教程就毕业的课,它更像一项需要长期练的手艺。

Gergely 在访谈里提到 Simon Willison 的一个看法,我很认同。AI 很难真正用好,而且没有固定手册。你需要持续改自己的工作方式。这对工程师来说其实挺反直觉的,因为我们习惯了理解原理,然后掌握工具。理解编译器,理解数据库,理解网络,理解系统设计,理解越深,用得越好。

但大模型这件事有点不一样。你理解 transformer,理解 attention,理解概率预测,当然有帮助。但它不会自动告诉你,今天这个需求应该怎么拆,应该让 agent 做哪一段,应该怎么写验收标准,应该什么时候叫停。

这些只能在使用里学。用错几次,踩坑几次,被它一本正经地胡说八道几次,你才会慢慢形成感觉。

所以我不太喜欢那种特别绝对的 AI 生存指南,好像只要学会几个 prompt,马上就能领先所有人。没有那么简单。但我也不喜欢那种冷笑式的否定,好像只要指出 AI 会犯错,就证明它没用。也没有那么简单。

真正值得做的,可能还是保持开放。别神化,也别装作看不见。你可以不刷 token,但你最好真的去用。你可以不相信排行榜,但你最好真的知道 Claude Code、Codex、Cursor、GitHub Copilot 分别适合干什么。你可以讨厌公司乱设指标,但你最好也别让自己停在过去那套工作方式里。

因为浪潮不会因为指标很蠢就停下来。

这也是我写完这篇最强烈的感受。AI 没有让软件工程变简单,它让软件工程变得更宽了。以前你只要面对代码,后来你要面对系统,再后来你要面对产品和业务,现在你还要面对一堆会写代码、会犯错、会加速你、也会误导你的智能协作者。

这事儿挺烦。也挺有意思。

反正我觉得,真正厉害的工程师,接下来不会是 token 用得最多的人,也不是最会喊 AI 口号的人,而是那些能在混乱里保持判断的人。知道什么时候该让机器跑,知道什么时候该自己想,知道什么时候该加速,也知道什么时候该停下来,认真看一眼。

因为真正该被衡量的,应该还是你有没有做出有价值的东西。不是你烧掉了多少 token,不是你跑了多少 agent,不是你看起来多拥抱未来,而是你有没有在这个变化很快的时代里,仍然保住一点清醒,这可能才是 AI 时代最稀缺的工程能力。