邮箱｜damoxingjidongzu@pingwest.com
Steve Yegge 不仅是著名的技术写作者和“呐喊者”，更是连接过去与未来的软件架构见证者。他曾在亚马逊、谷歌和 Grab 担任核心技术角色，积累了丰富的实战经验，如今则投身于 Sourcegraph，致力于打造面向 AI 开发者的下一代工具。
The Pragmatic Engineer 播客主理人 Gergely Orosz 邀请到前 Amazon、Google 工程大牛 Steve Yegge，在这次对话中聚焦于他对谷歌平台失败的深刻洞察，AI 编码的表面简单与内在复杂，以及一个全新工程角色——“AI 修复者”的兴起。Steve 以独特视角解读当下 AI 工具如何激活软件开发流程，推动生产力变革。
访谈内容原汁原味呈现于下：
Gergely Orosz：我第一次接触到你的博客，是通过你那篇广为流传的“吐槽系列”。大概是在 2010 年，我当时正努力在英国找到自己的第一份工程师工作，疯狂搜寻优质的面试准备资料。其中对我帮助最大的两个资源，一个是斯坦福大学整理的谷歌面试资料，另一个就是你那篇文章《Get That Job at Google》（《拿到谷歌的工作》）。
这篇文章给我留下了深刻印象，现在依然能在网上找到。最近我还发了一条推文，说尽管这篇文章已经过去快 15 年了，它的内容仍然非常有参考价值。尤其让我印象深刻的一点是：你在文中提到，就算你没拿到 offer，也不代表你不够优秀，你可能本来就配得上这份工作，所以不要灰心。你当初为什么想写这篇文章呢？
Steve Yegge：我其实被很多公司拒绝过。身边很多优秀的朋友也一样。我知道他们很有实力，但仍然没能通过面试。我看到的是很多所谓的“false negative”（漏判），也就是把优秀的人错判为不合适。而公司之所以倾向于漏判，是因为他们更怕招错人。谷歌当时就是这样，有足够的权力去说“不”。就是这么回事。
Gergely Orosz：你是 2005 年加入谷歌的吧？那时谷歌刚上市不久，是全球最热门的科技公司之一。
Steve Yegge：对，我是 2005 年入职的，你也是那年加入的？
Gergely Orosz：没错，2005。
Steve Yegge：所以我写那篇文章时，已经在谷歌经历了三年的面试流程。我很清楚谷歌看重什么，流程里有哪些坑。而且我觉得，哪怕现在已经过去十多年了，这套流程其实也没有太大变化。
Gergely Orosz：在那篇文章中，你提到了一个概念叫“interview anti-loop”（面试反循环），我之前从未听说过。能解释一下它是什么意思？现在这种现象还存在吗？
Steve Yegge：这是我自己发明的术语，但它描述的是一个真实存在、大家心知肚明的现象。其实在文章中，谷歌的招聘和 HR 部门对我写这段内容是有些担心的。但我当时想，如果不讲这个，整篇文章就缺乏诚意，也没什么意义。
所谓“面试反循环”，说白了就是：你在面试中可能碰到 5 到 6 个在技术观点上与你完全不合的人，他们可能误判了你。而你只是不幸撞上了这一组评委。很无奈，但确实会发生。
Gergely Orosz：实际上，我觉得这种情况在很多科技公司里都普遍存在，至少直到最近都是这样。也许正因如此，公司才会规定候选人 6 个月后可以重新申请。
Steve Yegge：我确实认识不少人是多次申请谷歌才成功的。比如我认识一个人，他第五次才拿到 offer，之后晋升非常快，发展得很好。显然他最初只是被误判了，但只要坚持，就有可能成功。
Gergely Orosz：很多读过你那篇文章的人提出一个核心批评：如果进谷歌或 Meta 这类公司的关键不在于个人能力，而更依赖面试官的主观判断，那这不是任人唯贤，也不公平。你怎么看？
Steve Yegge：我理解这个观点。面试从来都不是一个特别靠谱的评估机制。在我职业生涯的某些阶段，我甚至有点放弃去认真看待它了。很多人以为自己擅长面试、知道流程，但谷歌其实做过很多数据分析，结果显示面试得分与是否拿到 offer，甚至未来的工作表现，并没有强相关性。
所以我对面试机制本身已经不太抱有信心了。前段时间我帮一个朋友推荐去 Anthropic，我接到了那边的电话，但打电话的是招聘经理，不是 HR。他和我聊了整整 40 多分钟，深入了解这个人做过的事，而这些内容是你在传统面试中根本得不到的。
他之所以这么做，是因为我们都知道，面试有很多盲区。企业只能在“投入多少精力”和“评估质量”之间做权衡。
Gergely Orosz：确实，现在很多人都开始质疑面试的公平性，特别是编程面试，比如刷 LeetCode 之类的流程。于是有人开始主张直接让候选人“干一周活”，看看表现再做决定。像 Linear 这样的公司已经在这么做：他们会支付候选人日薪或周薪，让他们远程工作一周，等于直接“试用”。
当然，这也有现实问题。比如要花掉你整整一周的时间，而且很多人会说，我不可能同时给五家不同的公司这样试工，这就变成一个“高投入”的选择。
Gergely Orosz：但这就是现实。没有完美的面试方式。正如你说的，最终还是看你怎么选。
Steve Yegge：完全同意。我在这个行业干了 30 多年，见过各种“改进型”面试方法。我第一份工作所在的公司，当时的面试流程是：候选人要先做六个月实习，实习表现好才会转正。
Gergely Orosz：是哪家公司？
Steve Yegge：GeoWorks。他们的招聘门槛可能是我见过最高的。后来这家公司被亚马逊收购了，亚马逊对他们的招聘标准印象深刻。
Gergely Orosz：我们应该提一下这个“行业潜规则”：如果你现在去看谷歌、Meta，甚至微软的招聘官网，你会发现他们几乎不公开招软件工程师一级（SWE I）岗位。这是因为他们用实习生“填补”了这些初级职能。
Steve Yegge：完全正确。整个行业的校招竞争极其激烈，尤其是微软和谷歌这类公司。他们有资源跟各大高校建立合作关系，自然能拿到最顶尖的学生。
Gergely Orosz：也就是说，他们把所有初级岗位都提前锁定了。
Steve Yegge：我真心佩服那些选择去初创公司实习的学生。真的，那需要勇气。
Gergely Orosz：我最近和一个人聊过，她之后也会来参加这个播客。她当时同时拿到了微软和谷歌的留用邀请，也和微软的导师聊过。导师是个非常不错的人，坦诚地告诉她：你可以去大公司，但在初创公司能培养截然不同的一套技能。她深思熟虑后，决定冒一次险，去了 Kota，现在在 OpenAI。我觉得这段经历对她帮助很大。她跟导师谈完之后，整个人给我一种特别成熟、有远见的感觉。其实我原本没想到她会选这条路，因为那条“稳定路线”看上去很稳妥。
Steve Yegge：我也看到很多类似的例子。现在的大学生非常聪明，他们知道这些早期选择会影响未来发展。其实我们之前那篇写谷歌求职经历的文章里提到的很多问题，现在依然适用。现在做软件工程师，找工作确实不容易。
Gergely Orosz：那篇文章有一句话让我印象特别深刻，我想引用一下：“当你收到一家科技公司的 offer 时，其实只是侥幸通过了。”我起初是持怀疑态度的。但后来我自己经历了求职，也做过招聘经理，发出过很多 offer。很多候选人面试完说“我表现得很棒”，但以我在Uber的经验来看，我大概面试了一百个人，只有两三个是我们团队一致高度认可的。大多数人是好坏参半，最终做决定时往往挺纠结的。所以我现在真的明白这句话的含义，外人可能不容易理解，但招人很多时候确实靠运气。
Steve Yegge：我在谷歌的时候是招聘委员会的成员，流程是双盲的：我们看不到候选人是谁，也不知道面试官是谁，只看面试反馈。这是为了避免面试官之间相互影响。有一次，谷歌让我们参与一个实验。他们给我们看一批候选人的反馈记录，说这些人正在招聘流程中，请我们根据反馈做判断。但他们没告诉我们这些人是否已经被录用。我们照流程评估，结果发现我们拒绝了大概 60% 的人。
你能猜到吗？其实这些反馈是我们自己写的，是我们亲自参与的面试，也就是说我们否定了 60% 的自己。这真的让人清醒地认识到评估的主观性。那一两周之后可能是申请谷歌的最佳时机，因为我们大家对自己判断的信心都受到了动摇。
Gergely Orosz：60% 听起来几乎就是扔硬币，比完全靠运气好一点而已。
Steve Yegge：确实如此。整个面试流程在很大程度上受主观印象影响。很多研究都显示，人们往往在面试开始的前十秒就已经做出了决定。
Gergely Orosz：这篇文章给我的另一个启示是：每个人对面试的看法都不同。我原来不太信这些说法，但经历过招聘后我完全能理解。很多人面试后觉得自己表现很好，但我面试了一百人，真正得到一致好评的可能只有两三个。大多数人评价分歧很大，最终决定往往并不明确。这让我意识到，有时能拿到 offer 真的只是“刚好过了线”。你在文章中还提到了一个我以前没听过的概念，“面试反循环”。这是什么？现在还存在吗？
Steve Yegge：你提到当时被 Facebook 拒绝，反而帮助你拿到了Uber的 offer。这是怎么回事？如果真的有帮助，我也可以去 Facebook 试试看被拒。
Gergely Orosz：确实有帮助，因为我为了 Facebook 的面试做了很多准备。他们当时给我发了一些参考材料，我花了大量时间复习算法、复杂度分析这些知识。虽然以前也懂一些，但这次是系统地复盘一遍。在系统设计环节，我本以为自己表现不错，比如设计 Instagram 那种题型我准备得很充分，但没怎么和面试官互动。后来我收到反馈，才意识到自己其实没做得那么好。
不过等我去Uber面试时，正是因为之前做了大量准备，表现相对突出。那时在阿姆斯特丹和伦敦的Uber，很多人并不擅长这种面试形式，所以我借助提前一年的练习脱颖而出。所以说，准备从来都不会白费。
Steve Yegge：确实如此，准备很重要。但问题是，现在该准备什么？我有个朋友最近在面试，他是资深工程师。他说现在很多团队希望新成员能给他们“补齐 AI 能力”，这是当下的大趋势。那现在求职者到底该怎么准备？
Gergely Orosz：我最近又和一个人聊过，她叫 Jambi，也会来播客，她为 46 家 AI 公司做过项目，她原本在 Coda 工作，现在是一名 AI 工程师。她说现在的招聘环境确实很混乱。对中级工程师来说，大部分公司还是走传统的LeetCode 模式，然后额外问一些 AI 相关的问题。但她特别喜欢一种新型面试形式，让候选人基于实际 AI 项目做点东西。这种方式可以真正展示一个人的能力。
她说现在的局面是，公司其实也不知道 AI 工程师应该是什么样，候选人也摸不清方向，双方都在摸索。你在 2010 年写了《拿到谷歌的工作》，十年后又写了《拿到 Grab 的工作》。后者写的是一个火热的就业市场，很多初创公司正在争抢所有可用的人才。如今，市场更加拥挤，竞争比以往任何时候都激烈。
Steve Yegge：招聘人员就像是行业的早期预警系统，他们了解市场动态，因为他们直接和招聘经理沟通，而招聘经理则对接有预算决策权的人，这些人决定公司发展的方向。所以，与招聘人员保持联系，就能提前捕捉到行业趋势。我当时就是注意到工程师开始供不应求，这正是当时的关键问题。
Gergely Orosz：从外部看，你在谷歌发展得不错，却选择加入快速扩张的 Grab，有点让人意外。你为什么会做这个决定？
Steve Yegge：GeoWorks、亚马逊、谷歌其实在很多方面都很相似。GeoWorks 虽然主要做设备软件，但本质上差别不大。我当时在谷歌有个朋友，在 Grab 担任 CTO，叫 Theo Vaslacus。他对我说：“这是一场冒险，你得来。”我和他们聊了一下，发现东南亚正在经历一场生产力的爆发，这让我很感兴趣，事实也确实如此。只是后来疫情来了，一切都被打乱了。
Gergely Orosz：你在那篇《拿到 Grab 的工作》文章里写到，当时市场正在升温。疫情之后，资本大量涌入，催生了许多初创公司，其中不乏一些规模较大的企业，他们吸纳了大量人才。你怎么看当时的情况？你觉得现在是不是也有类似的趋势正在某些新领域发生？
Steve Yegge：没错，那时确实有大量投资在流入。文章发出后不久，疫情爆发，随后政府出台了大规模的经济刺激计划，很多人因此有了充裕的资金，催生了一波创业潮。对创业者来说是个好时机，对远程工程师来说也是一样。但刺激计划一结束，资金枯竭，形势急转直下。接着 AI 出现了，大家一下子陷入了迷茫，市场整体也开始下滑。
看看印度的就业数据，从 2021 或 2022 年的高点以来，岗位确实减少了很多。但与此同时，我们也看到生产力即将迎来新一轮爆发，类似的，技术带动的岗位增长也在酝酿。所以说，这就是市场的周期性。2018 年时，很多信号已经很明显，人们在努力预测未来，不只是为了选股，更是为了做出正确的职业和企业决策。而现在，我觉得你我都能感受到，形势正在回暖。
Gergely Orosz：这个我们之后可以再聊。我想回到我第二次看到你名字的时候。第一次是你写的那篇关于“如何进入谷歌”的博客，第二次就是那篇在 Google+ 上发布的“谷歌平台吐槽文”。那本来是一篇内部文章，但不知怎么的设置成了公开，最后被 Hacker News 转发，还被人存档了。现在它甚至在 GitHub 上还有一个条目，叫“Steve 的平台吐槽文”。这篇文章后来被广泛引用，因为它不仅批评了谷歌，也非常真实地描述了亚马逊的内部情况，包括杰夫·贝索斯那种“根本不关心员工日常”的管理风格。你平时就经常写这种内容吗？我们只看到这一篇而已。
Steve Yegge：我确实写过不少内部文章，但这篇的语气可能是最尖锐的。我之所以写，是因为那时候我已经在谷歌工作六年了，仍然无法争取到一个真正可用的平台支持。甚至连代码搜索团队都不愿意给我一个 API。他们说，现在谁还开放自己的 REST API？这在当时的谷歌内部很普遍，不鼓励服务复用，而是让大家直接使用已有产品。这让我非常沮丧，最后有天晚上实在受不了，喝了点酒，把心里话全写了出来。
Gergely Orosz：你那篇文章的结构非常清晰。你先总结了亚马逊的实践，再回顾了自己在那里的经历。你是很早就加入亚马逊的吧？
Steve Yegge：是的，我是 1998 年底加入的，那时候公司还很小。我们在西雅图市中心租了一栋四层楼的建筑，占了其中三层。公司当时只有一个数据中心，但已经有一种非常强烈的、类似粉丝文化的氛围。你能感受到，这地方真的在发生一些重要的事。
Gergely Orosz：那时亚马逊还只是卖书吗？还是已经扩展到其他业务了？
Steve Yegge：我加入时，已经上线了音乐品类，视频业务也刚刚起步。所以当时正好是公司从图书拓展到更广泛电商业务的转折点。
Gergely Orosz：你提到杰夫·贝索斯强制推行 API 化的平台架构。那时候你在亚马逊具体负责什么工作？
Steve Yegge：我当时在客户服务工具部门，可能还是这个团队的负责人。很多人以为贝索斯是通过正式的备忘录来推行 API 政策的，其实并没有。他不会去写正式的备忘录，他直接告诉大家要这么做，事情自然就发生了。
我们每周会和他开会，回顾客户联系亚马逊的十大原因。他最关心的是客户为何还会联系我们，比如最常见的问题是“我的包裹去哪了”或者“为什么我被重复收费”。这些都是高频问题。
客户服务团队面临的挑战很特别。也许正是因为贝索斯对客户体验的重视，才推动了 API 化。他想让亚马逊成为全球最以客户为中心的公司。客服团队经常抱怨无法访问网页服务的代码，供应链系统和配送中心系统他们也动不了，这使得他们无法有效帮助客户。贝索斯对此的反应是，如果有人阻碍客服获得技术支持，他就会让那个人“日子不好过”。结果就是，各部门必须向客服团队提供接口，而不能只是让他们自己去拉代码，在本地设法跑起来。当时很多服务还在用很旧的 C++ 系统，环境配置也极其复杂。这就是整个 API 化的起点。
Gergely Orosz：那大概是 2000 年左右？那时候还没有服务架构或微服务的概念。
Steve Yegge：没错，当时的服务大多基于 CORBA 这类专有协议，还有像 Co、Telaria 或发布-订阅模型，都是非常复杂的二进制结构。虽然 REST 的概念已经出现了，但没人重视，大家觉得这玩意儿没人真正理解，也没必要用。
Gergely Orosz：而且当时在安全机制上也还没有成熟的支持。
Steve Yegge：对，要过好几年大家才意识到，没错，你需要的就是一个 API。这其实就是我后来写那篇吐槽文章的起因之一，我在那篇文章里指出，亚马逊的很多做法其实是值得谷歌学习的。
Gergely Orosz：我读那篇文章时就觉得很明显，你虽然在批评谷歌，但其实是希望公司能变得更好。你给出了亚马逊的做法，然后说，“看，我们只要照这些做，其实就能做得更好”。
Steve Yegge：没错，我是这样想的，而且我觉得谷歌在很多方面确实很强，它做得比亚马逊好。实际上，亚马逊花了好多年才在某些方面追赶上谷歌，所以我们可以聊聊这个。
Gergely Orosz：你觉得谷歌在哪些方面做得更好？
Steve Yegge：比如，谷歌有一个内部 RPC 系统叫 Stubby。我在文章里也提到过，另外还有一个分布式锁服务叫 Chevy，它和 Stubby 是配套的。要实现一个高可用的分布式锁服务非常难，但 Chevy 做到了“七个九”的可用性，换句话说，十年可能只有 30 秒的不可用时间。这在工程上是非常了不起的。
Gergely Orosz：连“五个九”都已经很难达成了。
Steve Yegge：对，如果亚马逊做到五个九就很不错了，七个九在当时简直像神话。我再举个例子：谷歌早期提供了免费、几乎无限的非关系型数据库存储，带有强大的查询能力，供内部项目使用。这种基础设施是谷歌原创的，而其他公司还没开始考虑类似的事情。
Gergely Orosz：这些都是极其困难、需要解决硬核技术挑战的项目。
Steve Yegge：真的非常让我佩服。有时候我看到他们做出的系统，只能拍着额头想：“为什么我就没想到呢？”我曾经做过一个游戏，用的是自定义的远程过程调用（RPC）协议。后来我看到谷歌推出 gRPC，我一下就被震撼了。它是二进制协议，性能高，而且支持向前兼容，能在不破坏已有功能的前提下添加新功能。这个系统太优秀了。但可惜的是，使用它的人其实不多。
所以说，谷歌在很多底层技术方面真的很出色，但平台方面就完全搞不明白。这不是他们擅长的领域，甚至可以说是基因里没有这个能力。
Gergely Orosz：也就是说，无论是内部平台还是对外开放的产品，他们都没有做明白。
Steve Yegge：对，两个方面都不行。
Gergely Orosz：那后来你写了那篇吐槽文章。我真心建议听众去读一读，那是我读过最精彩的一篇技术评论，而且还很幽默。这篇文章后来产生了什么样的影响？它一开始是发在公司内部的，结果被泄露到外部了。显然外部世界开始用它来嘲讽谷歌。它在内部有没有起到真正的警醒作用？影响大吗？
Steve Yegge：谷歌的文化其实很开放。所以在下一次“TGIF”，就是“Thank God It’s Friday”，相当于全体员工大会，这个话题就被提出来了。
Gergely Orosz：TGIF 是谷歌非常有代表性的全员例会，对吧？
Steve Yegge：我记得当时负责数据中心的本·特雷诺站出来说：“大家都看了那篇文章。”所以公司确实有反应。但维克·贡多特拉非常生气，我是说，真的很恼火。因为我在文章里基本就是当众说他“生了个丑孩子”，而且还拿他孩子来举例批评。
Gergely Orosz：你指的是开发者平台？还是谷歌网站的哪个项目？
Steve Yegge：不是，是 Google+，我在文章里批评 Google+ 做得很差，但维克当时一心想让这个项目成功。他让拉里·佩奇对社交网络产生危机感，说如果不做点什么，脸书会彻底碾压我们，整个项目的出发点就很值得商榷。
Gergely Orosz：然后你提到，杰夫·贝索斯强制推行了基于 API 的平台策略。你当时在那儿具体负责什么工作？
Steve Yegge：说起来挺有意思的。外界普遍以为当时有一份正式的备忘录，但其实并没有。贝索斯不会写什么正式备忘录，他只会明确告诉大家该怎么做，事情也确实就推进下去了。当时我在客户服务工具部门，可能还负责整个部门的管理。贝索斯每周都会和我们开会，讨论客户最常联系亚马逊的十大原因。他想弄清楚为什么客户还需要联系客服，比如“我被重复收费了”之类的问题。但始终排在第一的是：“我的包裹在哪里？”
客户服务面临一个非常特殊的挑战，我当时还没意识到，但后来回想，这可能正是贝索斯如此重视客户服务、坚持开放 API 的原因。客服团队经常反馈，他们无法修改网页服务端的代码，因为那是别的团队在维护。他们也无法访问供应链系统或配送中心系统，导致难以解决客户问题。贝索斯的反应是，如果谁成为这种信息孤岛的阻碍者，那他就让他们吃不了兜着走。于是，他要求所有系统都必须向客服技术团队开放必要接口，而不是让他们去硬连代码、尝试本地跑一堆环境。当时那些系统还都是用一些糟糕的 C++ 写的，所以问题很多。这其实就是 API 化转型的起点。
Gergely Orosz：那应该是2000年初吧？当时还没有“服务”或“微服务”这些概念。
Steve Yegge：没错。当时所谓的“服务”大多是基于 CORBA 这样的专有协议，还有像 Co、Talarian 这样的中间件，采用的是复杂的二进制格式，也包括发布-订阅机制。REST 已经被提出，但没人真的理解，也没人当回事。
Gergely Orosz：而且也还没有专门的安全协议。
Steve Yegge：对，要过好几年，大家才意识到其实你就需要一个 API。这也正是我后来写那篇吐槽博客的起因之一，指出亚马逊其实很多做法并不理想。
Gergely Orosz：对，我记得你文章一开头就写了这点。虽然你在批评谷歌，但我感觉你是站在谷歌这边的，希望他们能改进。你列出了亚马逊做得好的地方，也指出谷歌可以在哪些方面做得更好。
Steve Yegge：确实。我是希望谷歌变得更好。我认为谷歌在很多方面都非常优秀，很多技术是亚马逊几乎不理解的。亚马逊花了很多年才赶上我们。比如我们可以聊聊 stubby 这个内部服务。
Gergely Orosz：谷歌擅长哪些方面？
Steve Yegge：比如谷歌有个叫 stubby 的 RPC 框架（远程过程调用），我在博客里也提过。还有 Chevy，一个分布式锁服务。Chevy 和 stubby 是相关组件。要知道，分布式锁服务很难做，但我们做到了非常高的可用性，接近“七个9”，也就是十年时间里大概只会停机30秒。这种基础设施的稳定性非常了不起。
Gergely Orosz：五个9已经很难了，七个9太夸张了。
Steve Yegge：在亚马逊，五个9都很难保证。谷歌很多基础设施项目，比如早期就给工程师们提供近乎无限的 NoSQL 存储服务，还有强大的查询能力，这些项目都非常超前。很多是谷歌发明的。
Gergely Orosz：这就是那种非常硬核的工程问题，而且难度极高。
Steve Yegge：对，有时候我看到谷歌内部某些系统时，甚至会拍自己脑门，想“我怎么就没想到呢？”比如我曾为一个游戏做过自定义的 RPC 协议。后来看到谷歌的 Stubby 和 Protocol Buffers，它们做到了前向兼容、不会破坏已有服务，还基于二进制格式，性能也极佳。太棒了。可惜使用范围不大。谷歌在这类基础技术上真的做得很好，但在平台化上就差很多。这不是谷歌的基因，他们确实不太理解平台思维。
Gergely Orosz：你是说，谷歌在内部平台和外部平台建设上都做得不行。
Steve Yegge：对，两边都不行。
Gergely Orosz：然后你写了那篇非常著名的博客文章。我强烈建议大家去读，是我看过最精彩的一篇文章之一。它最初是在谷歌内部发的，后来泄露到了外部。那文章在谷歌内部引起了反响吗？
Steve Yegge：当然。谷歌文化非常开放。那周五的全员 TGIF 会议上，这篇文章就被当面提了出来。
Gergely Orosz：TGIF 就是谷歌每周五的全员大会对吧？
Steve Yegge：对。当时负责数据中心的 Ben 在会上说：“大家都读了那篇文章。”他们确实有反应。但 Vic Gundotra 和其他项目负责人很生气。他们当时是主导 Google+ 的负责人，而我在文中直接批评了 Google+，就像当众嘲笑他家的孩子长得丑，还大声说出来一样。
Gergely Orosz：你是说 Google+ 的项目？
Steve Yegge：对，我当时说 Google+ 很糟糕。Vic 非常想推动这个项目，他让拉里·佩奇相信，如果不做 Google+，Facebook 会彻底击垮谷歌。我当时觉得这个想法站不住脚。那篇博客其实是我计划写的11篇系列文的第2篇，只是意外发到了公众平台，影响太大，我还因此躲了一阵子。那篇文章里只分析了 Google+ 失败的其中一个方面，平台。实际上我还想从更多角度去分析这个项目。
Gergely Orosz：回头看，你的判断其实是对的。
Steve Yegge：从各方面看我都是对的，但他们从没道歉过。我当时还说不应该做发布广告业务，结果也被证明是对的，我在谷歌很多判断都是对的，但我不太擅长说服别人。
Gergely Orosz：就像你说的，这项目本来就不值得做。你当初也明确表态，如果是你自己来决定，是不会做这件事的。然后你就继续投入到其他事情上了，而他们后来尝试了两次，结果都失败了。
Steve Yegge：我在项目复盘报告里其实提过一个建议，和后来 Groupon 采用的模式非常接近。所以也不能说一点成果都没有。当时我就说过，如果真要做，得先有一张覆盖大概八千人的人脉网络。而 Vote Groupon 最后就是按这个方向走的。
Gergely Orosz：被你预判中了感觉肯定挺爽的。听起来你已经尽力了，也提出了最靠谱的建议，还明确表示如果他们非要试试，那你不反对。
你当时的态度好像就是：“我不看好，但你们可以试。”然后你自己就继续推进别的项目了。
那你怎么看 Google+ 的结局？我记得谷歌曾推出 Google Wave，那时候它被定位成下一代电子邮件系统。但它很快就没什么动静了，我第一次意识到谷歌其实也会搞砸产品就是那会儿。
在 21 世纪初，我几乎觉得谷歌推出什么都不会错。他们发布新东西时我总是很激动，比如 Google App Engine，我当时觉得它酷毙了，我马上注册了账号，定价也低得离谱。后来我才明白那是因为谷歌在补贴这个平台。不过我记得 Google Wave 是第一个让我感觉不对劲的产品。当时各大科技媒体，比如 TechCrunch 和各类门户网站，都在说谷歌要革新电子邮件了，结果一试用才发现根本不是这么回事。
接下来就是 Google+。从外部视角看，我们很清楚谷歌是想挑战 Facebook 的地位，只不过如果 Google+ 失败了，那等于 Facebook 胜券在握。一开始它确实引起了一些关注，但很快就开始走下坡路，最后不了了之。当时你在谷歌内部，这整个过程是怎么演变的？我看过一些描述，说 Facebook 当时进入了“战时状态”，把谷歌的挑战当作头号威胁，反而让他们变得更加高效有执行力。你怎么看当时谷歌的问题？你觉得他们到底是缺了什么，还是错过了什么关键点？
Steve Yegge：那会儿我还在谷歌，也和很多参与项目的人聊过。我觉得 Google Wave 想抢占的市场，最后是被 Slack 给拿下了。Slack 的产品形态是对的，而 Wave 不是。我第一次看到 Wave 的时候，完全没有什么好印象。但它有种说不清的魔力，内部很多人都觉得它很酷，我当时就搞不懂它到底哪好。后来看到 Slack 的时候，我立刻就明白了，“哦，这才是那个对的版本。”很多人也有类似的感觉。这件事也说明谷歌一直在产品形态上把握得不太准。
这也是我打算写那 11 篇文章的初衷之一。我当时就想，如果他们早点出手收购 Reddit，哪怕直接买下来就行了。那时 Reddit 在美国的访问量还排不进前十，虽然已经很热门，但还没完全爆发。
那时还是在 Digg 火起来之前。所以我当时的想法是，谷歌应该打造一个比 Reddit 更好的平台。毕竟 Reddit 还在发展，还有很多可以改进的地方，而且这个平台需要和 Facebook 有明显的区别，这样用户就不会因为网络效应而轻易迁移过去。但谷歌的策略真的很奇怪。公司像人一样，会做出各种决策，而有些决策就是糟糕透顶。周围的人都看得出来问题在哪，但公司却充耳不闻，反而摆出一副“别教我怎么做事”的姿态。
Gergely Orosz：确实，总是这种感觉。你离开亚马逊已经十多年了，离开谷歌也有一段时间了。你觉得这两家公司这些年有哪些变化，又有哪些地方基本没变？
Steve Yegge：我觉得亚马逊的变化比谷歌大多了。这其实是第一次有人问我这个问题，所以谢谢你。亚马逊在几乎所有方面都实现了显著进步。当然，它仍有进步空间。但整体来看，亚马逊的执行力依然是全球最强的之一，而且他们成功规避了我在博客开头提到的那些典型问题。现在的亚马逊运转良好，我认识在那里工作的人也都挺满意的。总体上，他们是一家善于做出正确决策的公司，跟苹果类似。虽然他们偶尔也会犯错，哪家公司不会呢？相比之下，谷歌自我加入那天起，感觉就一直没什么变化。
Gergely Orosz：最近有谷歌的人问我对谷歌开发者生态的看法。我反问他：“你确定想听实话？”然后我说：“开发者生态？哪来的生态？”我举了 Flutter 和 React Native 的例子给他看。
目前 React Native 的核心团队中，Meta有大约 10 名全职开发人员，另外还有几家公司也投入了人力，整个项目大概有 50 人左右参与。而 Meta 是主力贡献者。如果你浏览 React Native 的官网，会看到展示页面上列着 Meta、微软、亚马逊等公司的标志，还有 Shopify。页面专门有一部分是 Shopify 的案例：为什么我们坚定采用 React Native？我们有数千名开发者在使用它，还有很多实际应用场景和案例研究。
React Native 被广泛用在 Meta 的产品中，比如 Facebook 和 Instagram，虽然不是整套应用都用它开发，但显然广告模块等关键部分已经采用了。而如果你再去看 Flutter 的官网展示页面，Flutter 至少有 50 名全职人员，团队规模是 React Native 的五倍。官网顶部你会看到一些谷歌自家的小应用，看起来还行。
但继续往下看，页面风格就像是实习生临时拼出来的：列着一些你听都没听说过的中国应用。页面底部倒是有宝马这样的国际品牌，但总体来说，大型应用和大公司的标志基本缺失，连谷歌自己的核心应用都没有使用 Flutter。初创公司如果在做技术选型，只看这些公开展示，就很可能直接选择 React Native，因为它在生态上显然更成熟。
Gergely Orosz：我问 Meta 的人：“你们人手这么少，为什么成效更好？”他说在 Meta，一切都围绕“影响力”来评估。React Native 团队做的第一件事就是确保它能产生实质性影响。他们把 React Native 优先应用在最核心的产品上，比如 Facebook 和 Instagram。这样自然能吸引其他公司注意，比如 Shopify 就会想：“既然 Facebook 内部有几千个工程师在用，那我们肯定也可以用。”
Steve Yegge：没错。谷歌在移动生态里，承担不起被边缘化的风险。他们不能沦为可有可无的底层技术提供商，这对谷歌来说一直是潜在威胁。因为 Facebook 的应用已经在一定程度上形成了一个平台，开发者可以直接在 Facebook 应用里构建内容。举例来说，如果你是《纽约时报》这样的媒体，要为 Facebook 平台开发内容，根本不会关心底层是安卓还是 iOS。谷歌最怕的就是这个。这也是为什么即使在 AI 热潮之下，Meta 依然没有削减 React Native 团队的预算和人力。他们的态度就是：“安卓你不用管，我们自己来。”这就是 Meta 的战略所在，而谷歌绝对不能对这种威胁掉以轻心。
但不幸的是，Flutter 并不是由安卓团队开发的，这也导致了内部的不满。安卓最初是谷歌收购来的独立团队，他们非常看重对平台的控制权。他们希望所有决策由自己做、责任由自己承担，不愿受制于外部。而 Flutter 的出现，打破了这种主导权，所以安卓团队对它一直很抵触。从 2017 年我开始关注这个问题，到 2018 年，谷歌都没能解决这场内部政治冲突。
Gergely Orosz：关于谷歌，我最大的不解之一，就是为什么他们在云平台这块迟迟没有改变现状。我之前在微软，其实更准确说是在 Skype。那时微软刚收购 Skype，还让我们独立运营。后来我们被并入微软体系，他们要求我们必须迁移到 Azure。我当时并不喜欢这个决定，特别是欧洲那边的基础设施根本没准备好。我坐在数据团队旁边，他们负责 Skype 所有的数据中心，要做迁移大家都很抗拒，觉得这太痛苦了。但鲍尔默就是强推。大家拼命努力，最终还是把系统搬过去了。
但随着时间推移，现在我和微软那边的人聊，他们要么就在用 Azure，要么就选 AWS，总之会选一个。而我跟谷歌内部的人聊，问他们用什么，很多时候答案不是 GCP。我问：“为什么不用谷歌云？”他们就说：“GCP 不够稳定，扩展性差，不适合我们需求。”这就很奇怪了。如果你想成为全球排名前二，甚至未来第一的云平台，结果自己公司的人都不愿意用，那外面的人怎么信服？我还专门去问了在 GCP 工作的人，他们说得含含糊糊，感觉像是在找借口。我实在不明白，为什么就谷歌这一家云厂商，自己的主力产品和服务都不用自家的云。
Steve Yegge：说到底，关键是谁更会包装、更会讲故事。很多公司都声称自己“全都用自家云”，但其实很多是自吹。比如亚马逊，它也没有把 AWS 用到所有核心业务里。
我当时也启用了 AWS。我的意思是，对于零售和广告这种对性能要求不是那么极端的业务，当然他们鼓励用 AWS，尤其是在美国。但真正的核心系统，其实很多都还没迁移过去。就我了解，现在内部用 AWS 还是免费的。
Gergely Orosz：也许现在情况有点变了，他们给那些旧系统起了个名字，看起来是在逐步迁移。但确实，到现在都还是个过渡状态。
Steve Yegge：永远不要低估亚马逊。他们的 AWS 现在也许真的发展到了可以支撑公司自身核心业务的程度。至于谷歌，他们面临的问题更复杂，从某种程度上说，也许我们对他们的批评并不完全公平。因为谷歌的基础设施规模远超其他公司，复杂度也更高。
可以这么说，GCP 本质上是运行在谷歌自己的内部基础设施之上。论规模，它的确是全球最大，这一点确实胜过 AWS。
Gergely Orosz：我其实一直在等谷歌推出他们内部用的那些开发者工具或平台，然后对外说：“我们内部有五万、十万名工程师都在用这套系统，你们也应该用。”就像微软那样，用 Visual Studio、Azure DevOps，这种把内外打通的模式。
也许我们会在 AI 工具方面看到这个趋势，比如用于辅助编程的 AI 工具。你觉得他们会这么做吗？还是说这根本不是谷歌的做事方式。他们可能更倾向于：“我们内部有强大的工具，但我们要单独做一个对外版本。”就像他们有 Borg，后来才做了 Kubernetes 给外部用。
Steve Yegge：我不这么认为。我觉得谷歌从来没有真正理解开发者，甚至到现在都不懂。
Gergely Orosz：讽刺的是，这和他们在“平台思维”上的盲区其实是同一个问题，你要是真懂平台，就必须懂开发者。更讽刺的是，谷歌招开发者招得比大多数公司都厉害。但他们做平台的能力，远没有达到那个水平。
Steve Yegge：没错，虽然谷歌内部确实构建了很多令人惊叹的基础设施，但他们始终没能真正将这些优势转化成对外的开发者平台。
Gergely Orosz：你之前曾有一段时间退休，后来又回归行业。起初是因为加入了Sourcegraph公司，后来又因为人工智能的兴起。是什么促使你重新回到这个行业的呢？
Steve Yegge：这并不是非此即彼的选择，而是一个渐进的过程。最开始，我觉得自己快憋疯了，非常想和人一起工作，所以加入了Sourcegraph，那是我熟悉的领域，就像面向大众的Google代码搜索。不久之后，人工智能开始兴起，我意识到这是技术发展的下一步，于是觉得可能需要暂时重新拾起编程，因为这领域看起来完全不同了。
Gergely Orosz：有意思的是，大约三年前我们交流时，你还是Sourcegraph的工程主管。其实，Sourcegraph的同事告诉我，自从你加入后做了一些改变，大家反响不错，你也带来了一些创新和新功能。后来我听说你写了不少文章，我们之后也会分享相关内容。我很喜欢写作，你曾发文说“我不再担任工程主管，要重新回去编程了”，这让我有点意外。
Steve Yegge：我把这看作是逐步复出的又一步。因为我曾经放弃过编程，觉得已经不值得继续。就像Kent Beck也放弃编程一样，很多老同事都如此。现在环境搭建太复杂了，比如你要开发一个简单的网页应用，可能需要用到25种不同的框架，而这些框架常常相互不兼容、相互竞争。
Gergely Orosz：对啊，一旦你升级到最新的React版本，所有路由都得重新学。
Steve Yegge：就是这样。时间久了，你会感到厌倦，觉得“不值得再做了”。而人工智能彻底改变了这一切。我早就预见到它的到来。当时我心想，“哇，你竟然能写出一个真正能用且相当不错的函数。”后来某种工具出现，我根据指数级增长预测性能，就知道这一天必将到来。随着时间推移，我越来越感到兴奋。
Gergely Orosz：业内常讨论一个话题，虽然很少公开提，但确实存在：人工智能将对初级开发者产生深远影响，也就是所谓的“初级开发者之死”这一争议话题。
有趣的是，很多相关文章标题会让人误以为“初级开发者将失业”，但细读后发现，这些文章其实是在警示初级开发者要做好准备，改变传统的学习和工作方式，否则难以适应未来。那么，你观察到什么现象？有没有哪些年轻开发者在这方面做得特别好，给你留下深刻印象？
Steve Yegge：你问到了一个对我们行业来说非常根本和基础的问题。这个问题正在撼动整个行业。答案是，我认为最简单的理解方式是，人工智能并不容易使用。所以你经验越丰富，就越有可能在人工智能表现不佳、行为不端时察觉到，对吧？这是常识。人工智能会以非常微妙和隐蔽的方式调皮捣蛋。即使它们变得越来越聪明，而且正以指数级速度变聪明，不出一年就会聪明得吓人，但软件的规模总是比它们大，对吧？它们还是会做一些傻事，而且这会更有利于经验丰富的人。
但这其实和资历无关。我们发现，这和初级、高级开发者没什么关系，真正重要的是谁有能力与人工智能良好协作，并在软件开发中取得好的成果。这可能是任何人，比如产品经理。所以我认为会有一场大变革，角色会发生变化，每个人都会更关注他们在构建什么，而不是谁在构建。如果你听说过斯科特·贝尔斯基提出的“堆栈崩塌”理论。
基本上，有一种观点认为，我们过度专业化了，每个人都在各自的领域有极深的专业知识，比如谷歌的一些资深工程师，他们清楚每个版本的Linux内核中融合文件系统驱动程序是如何工作的。但现在不需要这样了，这种过度专业化的情况会消失，因为人工智能让一切变得更加大众化，知识不再能被垄断。
Gergely Orosz：这很有意思，因为一两周前我刚和人聊过，在人工智能出现之前，软件工程就已经发生了变化。以前的软件开发人员有Java开发者、NET开发者、Python开发者等等，这些是不同的人，Java开发者不会去做NET开发，尽管它们很相似，所以以前后端语言是有专业分工的。
但在人工智能出现之前，大概2015年或2018年，情况就变了，比如我在Uber工作时，我们不再在意你是做Java还是.NET开发，只要你懂其中一种语言，就能上手我们正在用的任何语言。当时我的团队同时在使用Go、Python、Node.js等语言。所以我们的专业化程度开始降低。我在想，这种趋势是不是早就开始了，而人工智能只是让它变得更可行。以前前端工程师不会碰后端，他们可能只了解API的概念，但现在他们实际上可以做了。事实上，现在产品经理都能发起完整的请求了。
Steve Yegge：没错，我们现在就看到了这种情况。在Sourcegraph，我们的一位UI设计师现在会直接发起完整的UI请求，而不是让工程师去做。
我认为初级开发者的新角色是指导下一层不太懂技术或与技术相关的人，这些人现在开始提交拉取请求了。初级开发者会帮助他们解决安全问题或其他问题，基本上就是教他们如何使用技术，因为初级开发者毕竟还是经过训练的工程师。所以他们可以教UX设计师或产品经理，向人工智能提出正确的问题，以判断工作是否完成，传授这类技能。
Gergely Orosz：我喜欢这个观点，因为我们都知道情况会发生变化，但很难准确预测具体会怎么变。你显然有坚定的看法，这很棒，在这个领域必须有自己的信念。你在Sourcegraph工作，团队大量使用人工智能，事实上你们有自己的AI工具，并且从一开始就整合现有工具。到目前为止，我听到的大多数非技术人员从事技术工作的故事，都是来自AI公司，这些公司有很多懂技术的人。比如Windsor的联合创始人兼CEO瓦鲁告诉我，他们有个销售人员用Windsor开发了一个销售工具，虽然很简单，没有状态管理，但那个人做到了。我在想，这些非技术人员借助人工智能做技术工作的现象，会不会成为传统大公司未来十年发展的方向？
Steve Yegge：绝对会。我们到处都能看到这种情况。比如有些公司的营销团队自己编写外展营销活动的软件。产品团队也不再依赖供应商，不用和那些糟糕的供应商续签合同，而是自己开发软件，然后让工程师审核，“行，改这两处就行”。所以，会发生很大变化。
Gergely Orosz：我想问你点儿具体的，因为我对此有点怀疑。你有没有见过哪些具体被替换的案例？比如说，像Workday这种企业管理软件，你不太可能替换它，它涉及所有合规要求，涵盖大量州级法规和持续维护。没错，你不会去替换它，但你见过哪些被替换的情况？
Steve Yegge：有一个例子。想象一家公司，面对大量试图潜入网站、非法套现的不法分子。公司有多个团队分别负责不同类型的欺诈和攻击，市面上也有很多专用且昂贵的工具，针对特定领域非常垂直。于是这家公司的产品团队决定让人工智能来开发解决方案。他们给AI明确的需求，使用Python开发了相应软件。虽然这还不是正式生产环境的软件，只是调查不法分子时用的辅助工具，但这样避免了一笔昂贵合同。公司非常满意，因为他们对软件拥有完全控制权，可以随时调整。这只是我能举出的十几个类似案例中的一个。
Gergely Orosz：明白了，那我们接着聊这个思路。你了解我的背景，我们开发过软件，也见过团队做的内部工具。谷歌就以开发各种内部工具著称。那么下一步会怎样？我们能不能继续推进？作为有软件开发经验的人，我们知道这些工具发展到一定阶段会遇到瓶颈。明年如果要添加更多功能，会怎么样？什么时候会碰到瓶颈？这在人工智能出现之前也存在过。比如内部开发者做了工具，到一定程度它成了负担。
Steve Yegge：我大胆预测，会出现一种新的角色，就像电影《低俗小说》里的温斯顿·沃尔夫那样，专门来修复人工智能搞砸的事情。会有一批“修复师”出现，既有小团队，也有大团队。
Gergely Orosz：给他们起个正式的名字吧。
Steve Yegge：叫“修复师”挺好，就像你把事情弄得一团糟时需要的人。我们知道，世界上大约60%的程序员都是系统集成商，他们帮急需解决问题的大公司，让各个系统兼容，但价格非常昂贵。而且70%的项目都会失败，但公司还是会尝试。以前富裕国家会把工作外包给贫穷国家，架构师等岗位也是如此，但现在情况可能彻底改变了，因为我们不知道接下来实际开发工作会由谁来做。是富裕国家公司自己做吗？很多专家正研究这个问题。
Gergely Orosz：别忘了，我们以前也见过外包。上世纪90年代，我就听说所有高薪开发工作会流向印度或亚洲，因为那里的成本低。结果部分是真的，但也不是全部。
Steve Yegge：没错。我的意思是，如果一个人管理10个人工智能来完成项目，让他在越南工作会比在英国便宜得多。
Gergely Orosz：没错，但我们让开发人员和业务人员坐得近，是为了直接交流。我见过这种方式，你们也经常见到。我在Uber时，我们用轮岗制，现在Uber仍在用。比如总部在旧金山，那里招人成本很高；阿姆斯特丹成本是旧金山的一半；印度则是三分之一。所以会轮着招人，先是美国，成本太高就去印度。
我们招了一段时间，发现新人经验不足且沟通有问题，情况糟糕。于是去阿姆斯特丹，距离近且折中。后来又换地方，循环往复。有时不从阿姆斯特丹招，现在又开始从那里招。我觉得，已经过去四年了。
Steve Yegge：外包是很多公司典型的扩张收缩周期，就像质量保证集中与分散，或者胎压监测系统（TPMS）集中与分散一样，两种方式都会尝试，总觉得另一边草更绿，但很难做出最佳决策。
Gergely Orosz：你的新书名叫《字节编码》，是否用这个名字还争论激烈。先说说你如何定义“字节编码”？
Steve Yegge：字节编码就是由人工智能编写代码。这个定义肯定会被认可。你不能在口号里加条件从句。人们想用“字节编码”这个词，但又想加一些限定条件，就像他们现在正在做的那样。
Gergely Orosz：顺便说一下，我同意这个观点。就是不要那些额外的条件。我也听别人这么用过这个词。就像有些人会用相反的表述。关键是，就好像你处于一种顺其自然的状态，我就随它去。这通常是一种自动化模式，它会自动去完成一些事情。但也可能是，我会对它进行一定的控制，但我就像，你知道的，有点任由它发挥，所以我觉得这个概念，很多人会联想到安卓开发者大会、汽车派对，或者推特上的某个定义。我觉得它会成为一种普遍的现象。
Steve Yegge：问题是，它真的能让你兴奋起来吗？因为当你进入某种状态时，你的身体会产生兴奋感。没错，就是那种心流的感觉。你能自然而然地沉浸其中。你知道吗？它真的非常容易让人上瘾。像Claude Code、Sourcegraph等工具，你试试看，哇，它们就像能给你带来多巴胺刺激一样，简直就像老虎机。
Gergely Orosz：确实容易上瘾。肯·贝克也跟我说过同样的感受，我自己也有同感。我有个副业项目，我不太想碰它，因为我想自己搭建应用程序编程接口，能不依赖供应商就不依赖，但这很麻烦。像使用软件包管理器和亚马逊云服务，我都得记住怎么部署，很麻烦。但用Windsurf的时候，我做了一个小的API，让付费订阅时事通讯的用户可以获取复杂代码和Kagi代码。我连接了一个MCP服务器和数据库，我可以直接和数据库交互，我问，有多少人请求了代码？他们会告诉我，比如最近十天的情况，九天前有20、30、1000、2000、3000人。
我就想，等等，这看起来不太正常啊。我就让它分析异常模式，它告诉我是因为存在大小写不同的相同邮箱地址，我需要编写代码来修复这个问题。当时我正要去吃晚餐，通常如果我没有半小时到一小时的时间来编码，我就觉得不值得动手。但我当时只有十分钟，就在这十分钟里我就完成了修复。我去吃晚餐，吃饭的时候也很投入，回来后继续操作，总共三十分钟，我完成了原本就算我上手操作也至少需要两小时才能完成的工作。我就想，等等，我不再担心会打断工作状态了。所以有很多新工具确实能让你更高效。作为一名有经验的开发者，这真的太神奇了。现在我明白为什么肯·贝克说，在他52年的职业生涯中，他从未像现在这样对编写代码感到如此兴奋。
Steve Yegge：现在很多听众可能完全不知道你在说什么，因为他们还没试过Sourcegraph App、Claude Code、OpenAI的Codex或者Klein这些终端应用程序。顺便说一下，一旦本地模型达到Claude connet现在的水平，Klein就会变得非常重要，因为只要合理使用，Claude connet是非常实用的。
我们得面对现实，人们把这事搞砸了，原因在于很难接受这样一个事实：无法直接从人工智能那里得到答案。你能做的只是和它一起逐步得出答案。即便有个智能体自行去做事，你们仍是在共同完成，并且有望多数时候最终能得出正确答案。
有时候得尝试换个模型，很快你就会了解它们认知能力的局限，而这就是你必须应对的限制条件，真的不容易。人们期望它简单，想不费吹灰之力就得到结果。
Gergely Orosz：我第一次用ChatGPT时，感觉太神奇了，简直大开眼界。我想大多数听众都有类似体验。我第一次把我的MCP服务器和数据库连接起来，借助智能体解决问题。我稍微引导了一下，实际上当时有点偷懒，我知道自己想做什么，稍微干预就搞定了，而且速度快得多。那感觉真是太神奇了。
但我感觉ChatGPT带来的神奇感过段时间就会消退。刚开始确实很神奇，但后来就成了日常工作。我觉得很多人在神奇感消失后会感到失望。
我印象最深的是跟西蒙·威利斯的交流，他是个极具创造力的开发者，产出很多为人工智能写的代码。他告诉我，这东西很难用，他用了两年半还在不断学习。对我来说这有点矛盾，我觉得它很容易上手，但他却付出了很多努力。这是怎么回事？
Steve Yegge：这确实是个奇怪的矛盾。感觉它能让你生活轻松无比，但要让它按部就班地运行却不容易。就像让小孩拿着电锯一样。我来告诉你原因，这是Anthropic公司首席安全官杰森·克林顿说的。几周前在吉恩·金的工程领导力大会上，我抱怨Claude把我所有测试删了，还说“测试通过了”。杰森解释说，Claude是按奖励函数训练的，但没被训练成不要钻奖励函数的空子，所以它会毫无顾忌地这么做。现在的情况就是，它会告诉你任务完成了，而你得说“不，还没完成”，然后让它重新开始。
Gergely Orosz：肯·贝克也说过类似话。他把它比作精灵，会满足你的愿望，但方式有时出乎意料。
Steve Yegge：确实。有时候就像猴爪许愿，你得非常注意措辞。想象有一天程序员坐在电脑前，没有打开任何集成开发环境（IDE），但写的代码比以往更多。各位听众，如果你们还在用IDE，看着源代码做那些常规操作，人们会觉得震惊。
Gergely Orosz：在AI编码工具流行之前，我经常讨论开发者生产力的问题。比如是否应该衡量每个开发者的拉取请求数量。在Uber他们这么做过，还挺有用。但最近我跟一家开发生产力工具的初创聊过，他们考虑是否衡量PR数量。我跟他们说：“等会儿，这思路不对。”长远看，问题不在于开发者做了多少PR，而是未来的生产力到底是什么样。现在单看代码产出量没什么意义。比如我坐在某人旁边，真正能说明问题的是他们是否真的审核了代码，是否质疑AI给出的结果，而不是简单认可“看起来不错”就放行。这涉及工程领导的问题。我想问你，如果两年后这些工具越来越好，你觉得高效的软件工程师具体会是什么样的工作状态？不是看指标，而是看他们具体做什么。
Steve Yegge：首先，我得提肯特·贝克的“雪橇类比”。他说，使用这些智能体就像坐雪橇飞速下滑，但很难完全掌控。你可以引导它，但这就是现实。那些积极用这些技术的软件工程师每周要花数千美元。这也是为什么客户端和本地推理变得如此重要，这是让AI辅助编码真正可持续的唯一途径。
Gergely Orosz：我打断一下，你说每周要花数千美元，谁花这么多钱？我看到的多数是用云专业版订阅，每月花一百美元左右。
Steve Yegge：我个人每隔一两天就收到Anthropic公司220美元的账单，太离谱了。
Gergely Orosz：作为专业开发者，你跟团队合作时也看到这种情况了吧，对很多工程团队的情况有所了解。
Steve Yegge：对，我们团队里有人在用，我们知道他们消耗了多少“token”。这些智能体简直就是“token吞噬者”，它们通过暴力破解解决你听说过的所有AI相关问题。比如，它给出错误信息，那就修正；再错，再修，直到做对为止，但费用都由你承担。不过还是比你自己做快得多，所以你很难不采用这种编程方式。
Gergely Orosz：这数千美元的费用，是供应商承担呢，还是有专门成立的公司承担？公开场合我没怎么听到相关讨论，可能主要是独立开发者在社交媒体上分享，大公司可能不太在意。
Steve Yegge：企业开发者这边，你知道现在企业里是谁在用这些编码智能体吗？是首席技术官（CTO）。我们发现一个规律，CTO们往往能正确看待这件事。全球CTO都明白现状，也明白面临的经济权衡：为了让工程师用上AI，得裁掉多少人，因为成本极高。这就是我一直说客户端和本地推理重要的原因。因为很快你会发现，一旦同时运行四个智能体，你就像驾驭海神波塞冬的大海一样，感觉自己神一样高效，一天能写两万行代码，而且能持续一周，但代价极大，你得抢银行才负担得起。
Gergely Orosz：是啊，但这些代码都得放哪儿呢？我最近在推特上看到一个例子挺印象深刻。一人对他的代码助手说：“咱别同时做两件事”，基本是要实现锁定功能。结果代码助手启动了一个新的Redis服务器，添加了新服务，实现了乐观锁或悲观锁。大约4000行代码，是个Rails项目。有人说，等下，可能不用这么复杂。后来我自己在Redis里做了处理。关键是，这人懂Redis，只需要用一个能实现锁定的关键字，然后告诉代码助手怎么做。
关键是，这些代码助手确实能写大量代码。我有两个疑问：一是这种情况可持续吗？AI出现之前，我们见过初级开发者写一堆代码，代码的可维护性怎样？写出来的是好代码吗？是我们真正想要的吗？听说人们用代码助手写初稿后，会回头修改以保持编码风格或更规范。
Steve Yegge：没错，作为专业工程师，现在你可以做所有这些事。如果公司愿意承担加快代码生成带来的问题，你就能通过大量拉取请求。但有些公司不愿加快，很快公司间会出现分化。选择加快速度的公司，会看到既有严重挫折，也有成功案例。
我觉得你得成为“尝试且成功”的那类人。这意味着要冒风险。我能给的建议是，我们的书有300页，写300页关于Vibe编码，真有那么难吗？答案是，我和吉恩花了五个月深入研究如何用不同方式推动大型语言模型和Vibe编码，找出很多反模式和模式，发现这极其困难，这不是凭直觉就能做好的。
没人天生知道怎么做，拥有这种类似人类却明显不同的非人类助手，对人类来说是全新事物。我的最好建议是，给它们最小任务，尽可能细分任务。一次只做一件事，密切跟踪它们做什么，然后对它们提交的每一行代码负责。如果遵循这些规则，会有惊人生产力，同时避免麻烦。
我个人已经因为云端黑客利用奖励机制说“你的测试都完成了”遭遇很多噩梦。这不容易，也不会变简单。这是痛苦，也是大家挣扎的地方。AI会更聪明，不会再利用奖励机制钻空子，但会有其他问题，永远不会有拿来即用的完美状态。这是大家期望和想要的。在黑客新闻网上，有人说“我用AI成功了”，其他人说“我试了但没成功”，他们没意识到现在是能成功的，但这不是免费午餐。这是必须学会如何使用的工具。
Gergely Orosz：书里你举了个例子，说你开始真正相信这些东西了，是关于你一直开发的游戏。我记得你当时疲惫不堪，还宣布做这个游戏，取得了一些进展并发布了。用AI回归游戏开发，具体情况怎样？结果如何？现在进展到什么阶段？对不熟悉的人来说，这是什么游戏？
Steve Yegge：这个游戏叫《飞龙》。这是我1995年开始做的一款休闲游戏。它是一款大型多人在线角色扮演游戏，不过是2D的，全是像素精灵图形。但动画速度非常快，还有魔法飞来飞去的特效。这游戏很有趣，大家都很喜欢它，对它情有独钟。
Steve Yegge：人们真的玩了好几十年这个游戏。现在还有志愿者贡献者在参与开发，他们已经坚持多年。这绝对是一份热爱的事业。疫情期间我说我在做这个游戏，就把它放到了Steam上，对云端进行了全面升级，让它现代化。这一切都很有趣。但玩家群体对此非常兴奋，他们提出了很多功能需求，对吧？作为游戏开发者，我感到不堪重负，被压得喘不过气来。所以我放弃了，那时我真的不想再编程了。然后人工智能出现了，让我重新燃起希望。我意识到，天啊，这东西能帮我处理玩家要求修复的大量漏洞，我还能有多余时间。这就是为什么现在很多人都重新出山了。
Gergely Orosz：然后在这个游戏上，你开始用人工智能实现某些功能了？
Steve Yegge：是的。我一直在Sourcegraph的Cody上做开发，已经有一段时间了。代码助手出现后，我就想在一个旧的遗留代码库上试试。我们现在大多数是全新的代码库，我想试试糟糕的旧遗留代码库。30年的代码库真的很糟糕，很陈旧。所以我一直在做各种事情，清理代码，添加测试，进行迁移，这些都是大公司必须做的事情。因为我在亚马逊和谷歌有很多相关经验。你可以把这个经验放大。我在为《飞龙》做这些事，这就是作为开发者在一年半到两年内，在大型企业代码库工作能获得的经验。答案是，这会非常不同，会很有趣，但仍然非常困难。这是一个完全不同的角色，你不再写代码，而是进行构建。
Gergely Orosz：开发软件。所以在这个游戏上，就像你描述的那样，你告诉人工智能要做什么，它生成代码，你查看代码、进行测试，然后推送代码。
Steve Yegge：是的，这是一个非常复杂的过程，很难详细说明。它本质上建立在不信任基础上。你不能相信大语言模型给出的任何东西，任何东西都不能信。这意味着你要有多重保障、护栏、哨兵、安全措施和实践方法。你必须训练自己说正确的话、做正确的事、寻找正确的东西，这并不容易。这让我更加坚信，真正优秀的开发者会在这个新世界里蓬勃发展，因为这需要你用尽所有技能让这些东西走上正轨。
Gergely Orosz：我理解得对吗？一开始我可能误解你了。就好像公司应该投资这方面，应该去做，否则就会落后。就像早期的谷歌，谷歌当时搭建各种平台，也没藏着掖着。或者亚马逊是更好例子，当时他们构建各种内部API让系统相互通信，当时没人这么做。看起来要做很多工作，似乎没必要放弃现有东西去做这些。但20年后，亚马逊打造了AWS，有了一个大家都通过API交流的组织架构，而有些公司到现在还没弄明白。我们想说的是，这个功能即将到来，但需要付出很多努力。现在就开始吧，因为你需要弄清楚很多事情，不会那么轻松。
Steve Yegge：绝对不能把代码助手交给所有开发者。这对公司来说可能是一场灾难，会产生严重后果。你应该做的是，让部分开发者聚在一起，了解公司需要做出哪些改变。我指的不只是技术和IT方面，还有就业、监控等业务流程。如果代码生成不再是瓶颈，哪些方面需要改变？因为历史上代码生成一直是瓶颈，我们一直让其他方面顺其自然地发展。
Gergely Orosz：没错，这就是我想和你聊聊你游戏的原因。我觉得这对我很有帮助，因为我想弄明白，使用这些东西会是什么样子。我很高兴你说不是所有漏洞都会神奇地一下子被修复了。
Steve Yegge：这将是一项需要多年时间的工作，但速度会快100倍，所以还是很有趣的。
Gergely Orosz：在那本书里，有一点我很喜欢，你对就业受影响的预测。我之前以为你会说工作岗位会减少，但你实际说的恰恰相反。你为什么这么看？会有什么改变？肯定不会和现在一样了？
Steve Yegge：人们很难理解，因为我们正在把软件开发大众化，就像数码相机让摄影大众化一样。现在每个人都能拍出漂亮专业照片，而在80年代这不可想象。
Gergely Orosz：不可想象，这些东西以前得花多少钱啊？就说20年前。顺便说，多年来大家都不看好数码摄影，说这永远不行。
柯达就是因为不相信数码摄影破产了，他们甚至雪藏了自己的数码相机。
Steve Yegge：所以我们又处于类似情况。大家说人工智能永远不行，但他们错了。人工智能会发展到你想象不到的地步。接下来你妈妈、老板、麦当劳员工都会开发软件。我们会发现很多未被发现的真正天才。我的朋友布伦丹·霍珀，他是澳大利亚联邦银行的CTO，他对人工智能带来的精英统治有惊人假设。人工智能就像聚光灯，照亮一切粗制滥造的工作。那些囤积知识保住工作的人没戏了，人工智能什么都知道。
Gergely Orosz：说实话，这说法我一直不太信。
Steve Yegge：这会发生，但只是罕见极端案例。还有一种极端情况是人们会操纵系统获取利益，不管对系统有没有利。人工智能最终会揭露这些。所以真才实学的人会脱颖而出，会有大量工作岗位。开发软件比拍照影响更大。就算每个人都能做视频，那又怎样？但如果每个人都能开发软件，那就不可思议了。接下来大公司会裁很多人，很多人不再为大公司工作，会涌现无数初创公司。
Gergely Orosz：我不是百分百确定，大公司利润高，他们会裁员但会替换岗位，保持优势，留资金对抗初创公司。
Steve Yegge：这种矛盾和平衡会一直存在。但目前形势不利于大公司扩张，我看不到大公司会更大。
Gergely Orosz：我们研究谷歌发现，员工数2022年达到顶峰后缓慢下降，约18.8万人，谷歌盈利和收入都在上升。
Steve Yegge：现在公司简单解决办法是裁员，利用人工智能以更低成本做同样事，更有野心的公司会有更大动作。
Gergely Orosz：以游戏开发为例，过去做酷炫游戏最大门槛是构建3D引擎，这就是《毁灭战士》和《德军总部》火的原因，他们先打造引擎再开发游戏。但那是90年代了。
Steve Yegge：顺便说，我隔壁邻居迈克尔·A·拉什，就是让《毁灭战士》跑得更快，开发了《雷神之锤》的那位。
Gergely Orosz：现在有了Unity和虚幻引擎这类软件处理引擎部分，你可以专注游戏本身。这带来了什么？我采访过一些人，现在很小团队也能做出很酷游戏。我做过Unity教程，当然要付出努力，但不再像以前那么难做出专业水准。我关注游戏行业动向。
大型三A级游戏工作室大多在挣扎，比如《侠盗猎车手6》和EA体育游戏还火，但一些传统大工作室苦苦挣扎。现在有更多独立游戏，比以前多得多。他们难保持成功。我在想我们会不会看到类似情况，因为游戏引擎起了核心作用。
现在除了游戏引擎外，营销、故事很重要，在软件工程也是如此，编码曾是瓶颈。现在这个瓶颈被部分消除，但软件工程的其他方面仍存在。
Steve Yegge：肯定的，这绝对是真的。我们肯定会看到更多软件被开发出来，会有更多小型软件，更多独立游戏和高质量作品涌现。关键是有人能组织这些，就像应用商店组织应用一样。
Gergely Orosz：也许我们会看到一家新的初创公司。
Steve Yegge：对，你搜搜就知道了。几乎每次聊这话题，我们都会想出几个能赚几十亿美元的新点子。这也是我认为未来会有大量工作岗位的原因，因为这会带来真实的GDP增长。不是虚假的，是实打实的价值爆发式增长。人工智能要达到让大众用它开发可靠软件的程度，还需要几个关键转折点，离那阶段不会超过两年。届时会有海量超酷应用让你挑花眼，你还得用人工智能帮你筛选。
Gergely Orosz：那这两年内，不管是经验不足还是资深工程师，你对他们有什么建议？怎样才能充分利用这些工具，成为真正懂AI的工程师？你会给像你们Sourcegraph的工程师什么建议？
Steve Yegge：你知道电影《灾难艺术家》的编剧是谁吗？有人推特问他：“我想写剧本，怎么开始？”他回答：“开始写。”意思是别等了，不要找借口，“我没准备好”什么的，行了，别抱怨，立刻去学。
大概三四周前，我和达里奥·阿莫迪聊了半小时。达里奥是个消息极灵通的人，他对未来的看法比公开说的更隐晦。他和首席安全官杰森·克林顿都说过很严肃的话，比如到2026年年中，会有具备资质的AI员工和你竞争。人工智能的摩尔定律说它每18个月智能提升4倍，现在智商10，三年后可能达到160。达里奥说，这对人类来说将难以应对。
他说社会像一座无法移动的大山，而科技和AI是无法阻挡的力量，它们不会停，两者会碰撞，场面惨烈。这股力量推动社会前进的速度超过了社会愿意承受和接受的极限。我们已经看到有人抵制AI，有人发推说“受够了”，代表一代人听腻了这些。但你以后会一直听到这些。
所以我的建议是，别偷懒了，现在就去学。开始尝试用AI辅助编程，学会怎么用。有很多东西要学，要培养新的思维方式，很多事不会按预想发展。但现在开始，你就能做好准备。达里奥称2026年为“终局”，他说这话很平淡，但你明白这事影响有多大。软件工程师会最先受影响，所以你得跟上潮流，抓住新出现的机会，软件工程师2.0版，利用AI完成非凡工作。你必须成为其中一员，否则会被彻底淘汰。
Gergely Orosz：这个发展让人联想到云计算的普及。15年前AWS刚出来时，很多银行业人士说永远不会用公共云，只用自己的数据中心。但AWS认证一度非常吃香，拿证就能涨工资。这说明AI基础设施也一定会普及到各行各业，包括非科技公司和政府，只是时间问题。虽然我们对具体时间看法不同，但我认同你说的，现在就行动很重要。
我看到一个例子，詹比在Coda想进AI团队，公司说没经验不要，后来她自学五个月，成为顶尖成员。关键是别被末日论吓住，要有动力。我们回头看，会发现这就是行业的拐点。
Steve Yegge：正是，我们身处其中。很有意思。我现在更多是在修复漏洞和添加功能，不怎么写新代码了。
Gergely Orosz：写代码时你知道预期结果，修正起来有很多元编程成分。
Steve Yegge：对，我一天得读十万行代码，累得很。要仔细，不然漏问题。吉恩·金，我的合著者，也很激动AI辅助编程，虽然很多人悲观，因为不想改变工作方式。
Gergely Orosz：我也经历过怀疑。当看到大变革来临，感觉工作受威胁。我们习惯用自动化替代客服岗位，但这次不同，软件工程师的工作本身被威胁。
不过和尼肯聊过后，我意识到如果你是优秀工程师且愿意学习新技术，会更抢手。现在有很多AI工程师，既懂用又懂非确定性的软件工程师，他们开始深入机器学习。过去15年行业有些停滞，管理占比多。现在被迫变革，你做得很好。
Steve Yegge：是啊，别把身份认同绑在脆弱的事物上。软件项目就像《帝国反击战》的死星，庞大且复杂。即使有编码速度快20倍的机器人，项目仍要几年完成。
Gergely Orosz：还需要架构师监督。
Steve Yegge：没错。机器人帮忙加速，但死星还是死星，项目周期长。工作机会不同形式存在。我退休是因为觉得自己停滞了。
Gergely Orosz：我负责的《悖论》报道行业趋势，没AI时我们讨论如何拆分单体应用、衡量生产力、管理团队规模。
Steve Yegge：会不会转用Rust这类内存安全语言？
Gergely Orosz：是的，感觉有点无聊。现在则是重大变革。接下来是快问快答，关于AI，你最喜欢的编程语言？
Steve Yegge：哇，现在都无所谓了。
Gergely Orosz：以前呢？
Steve Yegge：AI变得无关紧要前是TypeScript。很灵活强大。
Gergely Orosz：最喜欢的AI编码工具和非编码工具？
Steve Yegge：编码工具用Sourcegraph AMP，昨天刚发布，速度快，挺棒。非编码的试过Operator，希望它能帮我编辑Google文档，但处理很慢，结果删段内容。
Gergely Orosz：软件领域会大爆发，得靠我们开发这些工具。除了你的书，有无推荐？
Steve Yegge：推荐《安全终结人类》（Safety Ends Man），非常棒。
Gergely Orosz：好极了。感觉这趟对话像坐过山车，有起伏但结局好。
Steve Yegge：变革让人害怕，但我看这是积极的变革。
Gergely Orosz：是的，很多人怕是因为没经历过。和肯、格雷迪聊过，他们说过转向微处理器时，大家生活变了但又没完全变。
Steve Yegge：说得对。以前没人有电脑，突然人人都有电脑，这是很有趣的进步。
Gergely Orosz：以前程序员得去有大型机的公司，现在人人都能做。
Steve Yegge：个人电脑开启了大繁荣。我们现在也是大繁荣开端，有很多赚钱机会。
Gergely Orosz：对我们软件工程师来说是好事。谢谢Steve，这次交流太棒了。
（文：硅星GenAI）