代码成本为零时，工程领导力的新定义

Eric 介绍了 Intuit 如何在整个组织范围内推广 Claude Code，为什么产品经理现在开始合并自己的 PR，以及当产品和工程角色开始趋同时，这对工程文化意味着什么。Eric 和 Ben 深入探讨了在 AI 优先的行业中，哪些工程技能最为重要，以及为什么培养初级人才变得更加困难。

Eric 还分享了他个人如何使用 AI 管理收件箱、综合整理规格说明，以及执行晋升流程（但也解释了为什么他不再允许 AI 代替自己发送电子邮件）。

可以在 LinkedIn 上与 Eric 联系。

大家好，欢迎收听 Leaders of Code。如果你是第一次加入我们，这是 Stack Overflow Podcast 的一个栏目。在这里，我们会邀请资深工程领导者齐聚一堂，与他们讨论正在开展的工作、如何组建团队，以及目前摆在他们面前的最大挑战。我是 Eira May，Stack Overflow 的 B2B 编辑。今天和我一起的仍然是我的同事 Ben Matthews，他是 Stack Overflow 的工程总监。Ben，感谢你再次回到节目中。

感谢邀请。很高兴来到这里。

当然。今天的嘉宾是 Eric Anderson。Eric 是 Intuit 的工程总监。Eric，非常感谢你加入我们。最近怎么样？

非常好。我特别期待和大家交流。谢谢你们。

太棒了。我就直接进入正题。我知道我们有很多一直想讨论的话题。我想先从一个 Stack Overflow 最近始终高度关注的问题谈起，那就是相较于编码速度，人类批判性思维的重要性。当 AI 工具让代码生成几乎可以瞬间完成时，我认为我们需要以不同的方式看待人类的批判性思维、上下文和监督。因此，Eric，我想先问问你：在与团队合作的过程中，你如何权衡 AI 工具带来的速度优势与人类批判性思维的必要性？

我认为，现在是整个行业一个极其有趣的时期。我在这个行业已经工作了几十年，可以说，一行代码的增量成本从未像现在这么低。实际上，在软件开发涉及的所有工作中，真正生成代码几乎已经成为成本最低廉的事情。

这带来了一种非常有趣的局面。过去，无论从进度安排、风险管理、发布还是回滚的角度来看，编码始终是最令人担忧的环节。而现在，我们开始真正思考应该如何重塑工作方式。真正构建一个功能意味着什么？什么是系统设计？组织中的工程师需要具备哪些技能才能取得成功？因为即使你是一名顶尖程序员，在这个新时代里，这也不一定能让你成为一名顶尖的软件工程师。

所以，我认为现在是成为软件工程师的一个非常令人兴奋的时期。不久前，很多人还在问：“软件工程会消失吗？”但我认为，我们现在每天创造的软件比以往任何时候都多。我看到人们对软件开发、软件架构、软件韧性、支持和工程等各个方面的需求都在不断增长。

回到你问题的核心，所有这些工作的中心仍然是人。人必须依靠高度的判断力，决定以什么方式组合这些代码最好，并确保它能够为客户创造价值。

我很喜欢这个观点，尤其是你从成本角度进行的分析。如今，每行代码的成本从未如此低廉。我认为，这一点影响深远：我们看待事物的思维方式或许必须随之改变。

我认为现在各处都面临着一个很有挑战性的大问题：我们该如何衡量有效性？如何衡量一名工程师的表现？如何衡量产品的质量？我们看到很多公司引以为豪地宣称，仅通过 AI 就已经生成了数百万行代码。这确实令人印象深刻，我无意否定这一点，但这真的是应该衡量的指标吗？Intuit 是如何看待这个问题的？

我们在这里使用了很多指标，包括 PR、CR、评审数量、代码行数，以及各种传统指标。我认为这些指标依然有意义，也值得关注。但归根结底，过去最重要、现在也仍然最重要的指标是：我们通过技术完成的工作是否为客户创造了价值，以及我们该如何衡量这种价值。

现在，我们能够以更快的速度将功能投入生产环境，并探索同一事物的不同变体。Intuit 内部会进行大量实验，例如比较这个版本的体验是否比另一个版本更好。我们已经不必再二选一了。我们能不能做两个实验？能不能做五个实验？能不能做九个实验？能不能做 900 个实验？实际上，我们进行实验的可选择空间已经大幅扩展。我认为这非常令人兴奋，因为现在我们不再只是说：“好吧，这些都是很棒的想法。”

我们怎样才能真正把这些想法全部试一遍？怎样才能快速完成这些尝试？怎样才能配置正确的指标和监测手段？现在，完成这些事情已经容易得多。归根结底，我们真正想做的是为客户创造价值。

我认为，这仍然是五年前、十年前、今天、明天乃至五年以后都不会改变的指标。我们构建所有这些技术，是为了让某个人的生活、工作或活动变得更好、更快乐、更轻松，并真正带来改善。所以我认为，核心其实仍然没有变化。

这也回到了我们这次对话的核心：人类始终处于软件工程的中心。因此，我认为现在比以往任何时候都更加重要的是，工程师必须真正具备同理心，了解自己的客户是谁，以及什么对客户而言最重要，因为工程师现在能够比过去更轻松地影响客户体验。

是的。我尤其喜欢这个观点：我们来到这里，是为了创造人们愿意使用的东西。当你说这仍然是一种人类体验时，我认为，无论是我们消费它的方式还是创造它的方式，都仍然在很大程度上是一场人类的探索。

这让我想起一件非常暴露年龄的事：当 IDE、各种集成工具以及其他工具刚刚出现时，人们曾经想过：“现在还有谁算得上工程师？作为工程师，我还能做什么？”而工程师的角色一直在持续演变。

我认为这只是演变的又一个阶段。我们必须弄清楚工程师现在到底要做什么，需要具备哪些技能。工程师现在是否更像一名教练，负责协调自己的智能体开展工作？其中又有多少工作取决于对系统的理解？

所以，当你提到速度是最令人兴奋的部分时，你认为新的瓶颈会是什么？过去，生成代码的速度通常是一个经典瓶颈——当然并不总是如此，但通常如此。你认为接下来会出现什么新的瓶颈？

几周前，我的组织刚刚进行了一次大型规划活动。我们最初启动规划流程时说：“我们来制定一份 Q4 的季度路线图吧。”但随后我们又说：“先别这么做。我们应该重新设想一下，要交付这份路线图究竟需要什么。”

因为当我开始查看各个团队的待办事项列表时，我意识到，我们对能够完成的工作设想得太保守了。实际上，我们完全可以看着这些工作说：“是的，这些我们都能完成，而且还能做得更多。”

因此，对话的重点开始真正发生变化：设计进展到哪里了？我们是否有足够多的设计方案？如何更快地完成设计迭代？产品工作进展到哪里了？产品需求在哪里？我们真的需要非常复杂的产品 PRD 文档，把各种细微之处和所有细节都完整记录下来吗？还是说，我们只需要画出想尝试内容的草图，然后由产品经理和工程师共同开发，针对某个具体功能设计出多种不同的方案？

所以，我认为瓶颈在哪里？真正的瓶颈在于构思过程——如何从“嘿，这是个很酷的想法，它能解决客户的问题”，走到“这是一个已经在生产环境中运行的东西”。我们需要弄清楚，如何重新调整许多协作关系、工作体验和交接流程；在一个设计随时可以改变、明天就能重新构建的时代，“设计完成”究竟意味着什么？其实没关系，我们明天可以修改设计，再构建一个新版本，完全没问题。因此，我认为瓶颈更多地存在于软件构建流程本身。

我还记得，Scrum 成为软件工程主流方式时，我们开始有产品负责人和 Scrum Master。它确实带来了变革，推动我们从瀑布式方法转向更加敏捷、迭代的方法。而现在，我认为我们已经进入了一种新的工作模式，但坦率地说，我们还不知道怎样才能把它做好。

我们正在这个过程中不断试验和学习，但在我看来，如今的瓶颈很大程度上就是流程本身——它正在拖慢我们的速度。因此，团队不得不回过头来重新调整工作方式，而且具体方式取决于团队所做的事情。如果他们构建的是前端商店体验，可能可以快速做出无数个版本……他们需要用一种方式思考。如果是一个后端团队，主要负责大规模数据管道和关键任务型数据摄取，那么他们可能必须采用另一种方式。

所以我认为，我们再次处在一个非常有趣的时期，正在重新想象：要成为一个真正成功的软件组织，究竟需要具备什么。我们已经从一种工具转向了一种完全不同的工具，它让生产各种类型的应用体验变得容易得多。

是的，说得太好了。我特别认同，真正将要演进的是流程。我非常确信，四五年后，当我们回头看今天使用这些工具的方式时，会觉得自己当时是多么天真。流程仍在成形，我们还在探索新的常态会是什么样子。我认为，许多试图突破边界的组织都会说：“让我们重新思考一切，离开这条铺好的道路，开辟新的路径。”

我也很想进一步探讨，你会以怎样的心态应对这件事。因为我觉得你正在以一种非常开放的态度重新评估这些问题。这是否仍然要回到试验上？不仅仅是在代码层面试验，也要在流程层面试验？你又该如何让其他利益相关者和其他部门与这种做法保持一致？

以 Intuit 为例，我们拥有一种高度协作的文化。团队成员会带着各自专业领域的观点走到一起，包括设计、产品、数据科学、应用科学、软件工程等，然后真正从客户问题出发，反向推导解决方案。过去几个月里，有很多人走进我的办公室。我们已经向整个组织推广了 Claude Code，一位设计师来找我说：“我已经配置好了 Claude Code。现在应该把代码提交到哪里？”

我说：“好吧，我们想解决什么问题？”

他们回答：“我不知道。我只是需要知道，既然现在有 Claude Code 可以帮我做这件事，我应该把代码放在哪里。”

所以我认为，从很多方面来说，真正重要的是明确预期：我们认为其中一些流程可以在哪些地方发生根本性的改变。

现在，我们的产品经理会创建 PR，提交到代码库，由工程师审核，然后以实验的形式发布。这很好。实际上，除了审核 PR 以外，工程师在这里没有做任何其他工作，这完全没问题。与此同时，我们也仍然有工程师在完整地构建功能。

我认为，对我们而言真正重要的是保持这种试验和学习的心态，并理解事情会发生变化、会不断演进。我们今天并没有所有答案；今天我们认为很棒的东西，明天可能会变得完全不同，这也完全没问题。因此，每个人都需要在思考问题的方式上保持灵活。

我还认为，我们不一定需要去挑战什么，但必须真正接受这样一种观念：不同角色正在融合。因此，产品经理现在可以成为工程师，工程师现在也可以成为产品经理。

我一直非常赞同这样一种观点：工程师和产品经理只是同一枚硬币的两面。既有技术能力很强的产品经理，也有产品思维很强的工程师。在非常小的组织里，这两个角色往往由同一个人承担；在更大的组织中，他们会变得更加专业化，但仍然拥有某种共同的理解。我认为，这些工具确实为此类工作体验开辟了许多新的路径和可能性，这非常棒。

我也一直向团队强调：归根结底，对我来说，这与我们从 eMax 和 VI 转向 Eclipse 和 IntelliJ 并没有本质区别，明白我的意思吧？只不过现在的工具更加强大，更有能力生成高质量、结构化的技术代码。

但你仍然要对它的实际运行负责。它仍然必须经过 CICD 部署流水线；仍然必须具备可支持性、可维护性和可观测性；我们仍然必须拥有指标，并关注性能。

所以，回到你提出的“如何让所有人都认同这些事情”这个问题，与其说这是在争取认同，不如说是在拓宽大家的视野，让所有人重新理解：全面构建关键任务型、高质量软件究竟意味着什么。

工程师正在学习产品，设计师正在学习代码，产品经理正在学习卓越运营，以及所有这些东西如何结合到一起。整个过程非常棒。它确实帮助人们理解了团队中存在的某些约束，以及为什么有些事情做起来会如此困难。我认为，它也帮助人们建立了更深入、更广泛的跨领域、跨技能共情。

这种共情实际上加快了许多沟通。因为现在人们会说：“哦，我现在明白为什么这件事特别难了。好，那我们换一种方式做。”

对方就会说：“完全同意，就这么做。”

是的，我认为“共情”是一个非常准确的词。它拉开了帷幕，让大家看到某些职责和挫败感究竟存在于哪里。正如你之前提到的，构思过程正在演进，以前不那么懂技术的人现在也能够参与技术实现。

尤其是在构思过程中，我现在经常获得非常令人满足的体验。过去，当我们试图转译业务需求或者表达想做什么时，往往会遇到困难。现在，产品经理或设计师可以说：“这样吧，让我马上拼一个东西出来。”然后，他们真的能够迅速展示交互效果，展示自己希望它呈现出来的样子，其他人也可以亲手操作。

我会把那段代码发布到生产环境吗？可能不会。但它能不能成为一条快捷路径，让我们迅速得到一个实际存在的东西？当然可以。这确实是一个令人兴奋的时代。

你刚才提到同时运行 9 个实验或 900 个实验，我认为这也关系到我们能够同时处理多少事情。我经常在和领导者讨论这个问题时向他们提出挑战：“我们需要更少的工程师吗？”

好吧，如果你现在确实只需要更少的工程师，那么问题在于，你想不出足够多值得构建或推进的事情。这才是真正的挑战：我该如何充分利用这些如今已经被极大增强的工程师？我认为，从跨职能协作的角度看待这个问题，甚至让设计或产品人员直接着手处理，都是让所有事情持续推进的一种非常令人兴奋的方式。

是的。我们 Intuit 的 CTO Alex，我认为他对此总结得非常好。他说，自己已经在这里工作了很长时间，但从未见过待办事项减少。业务要求我们完成的工作积压，从来没有变短过。

所以他的意思是，当我们真的觉得可以用更少的人完成所有这些工作时，那才是一个值得讨论的话题。但今天，我们实际看到的是创意的爆发。我认为，这是一个非常令人兴奋的时刻。现在，每个人似乎都摆脱了过去那些限制——比如“天啊，要让软件真正构建出来并交付出去实在太难了”。

现在这仍然很难，但我们的速度和完成更多工作的能力已经大幅提升。我们现在生产的软件比以往任何时候都多。我认为，随着时间的推移，这种趋势还会继续放大和加速。

太棒了。是的，那么从更宏观的行业层面来看，既然开发速度，甚至把想法变成实际成果的速度，已经不像过去那样构成瓶颈了，如果现在面对所有工程师，你会怎样回答这些问题：“那我应该专注于什么？如果擅长调试、CICD 或某个特定细分领域所带来的差异化优势已经不再那么明显，那么我应该重点培养哪些特质，才能让自己从其他工程师中脱颖而出？”

我会把这一点告诉我的所有领导、团队、团队负责人，尤其是负责招聘的人。我认为，我们通常会从两个方面进行评估：一是职能技能，二是你开展工作的方式，而我认为，开展工作的方式与职能技能无关。那么，你是否会深入钻研问题？当事情没有按预期发展时，你是否能展现出强烈的主人翁意识？在思考问题时，你是否始终以客户为中心？Intuit 有一套价值观，其中包括“让速度成为习惯”。你能否自己扫清障碍，找到前进的道路？这与 clog CLI，或者你懂我的意思，Quota 之类的东西是相互独立的。至于职能技能，我仍然认为软件工程是一套技能，是一套职能技能。

我会把它分成三类。第一类是理解算法的人，第二类是懂得如何以技术思维解决问题的人，第三类是懂得如何组织和模块化事物，并将其拆解成更小组成部分的人。过去这些年里，在面试软件开发工程师时，你可能会让对方完成一道编程题，并评估：他们写出的代码是否符合逻辑且易于维护？他们能否创建类、结构和接口？他们是否理解方法，以及无论使用哪种语言，这些东西是如何组合到一起的？我认为，如今理解这些仍然很重要，但理解如何实现模块化甚至更加重要，因为如果你要生成一个包含 12,000 行代码的 PR，就不能把这 12,000 行全塞进一个类里。那是不可接受的。同样，我们仍然需要理解算法的人。比如数据库查询、ETL 之类的大数据处理流水线，这些仍然是需要通过算法解决的问题。

你仍然需要知道 OVN 是什么意思，以及如何在不同类型的实现中达到这一复杂度。我认为还有一些通用的问题解决概念，比如，互联网上有无数这样的问题：如果你在这里买入股票、在那里卖出，那么买卖股票的最佳时机是什么？你懂我的意思吧？这种思维方式仍然必须存在。因此，我仍然认为，在如何成为一名优秀工程师这件事上，我们依然会从这三个职能领域评估工程师。那么，你是否应该懂调试？当然。是否应该懂 CICD？绝对应该。这些仍然是软件工程中的概念。但在基础层面，如果你无法理解算法，就不可能取得成功。不存在什么 Claude CLA 能帮助你在这方面取得成功。

我们还没有达到那个阶段，也许未来某个时候可以，但今天还不行。而这正是我觉得……非常有意思的地方。当我想到我们最资深的工程师，包括 Staff、Senior Staff 和 Principal 工程师时，这些人通常都能看到……最近，我在一次一对一沟通中听其中一位告诉我，在使用 CLA 之后，他的生产力达到了以前的 100 倍。而且我确实相信他。他说：“我可以极快地推进事情，因为我知道它是如何运作的，也知道如何构建所有这些东西。”至于经验更少的初级工程师，我不想说我对此感到担忧，但我认为整个行业确实需要给予更多关注。因为我成长的那个时代，软件工程师对工程这门学科的学习，是通过坐在那些比你写过更多代码的人旁边完成的。你会逐渐理解，这几乎就像成为一名橱柜木工或水管工，是一种通过工匠式途径进行学习的方式。

可以说，是那种亲身实践的经验。

没错。我认为，这正是我们必须弄清楚的事情：如何随着时间的推移传授这些经验，因为要让这套方式奏效，你需要控制措施、护栏以及诸如此类的一切。我们正在深入思考这个问题：一方面，如何让最优秀的开发者将生产力提升 100 倍——这当然很好；另一方面，如何确保那些刚刚开始职业生涯和/或正在学习的人，能够以一种有益于其职业发展、健康且富有成效的方式追赶上来，并逐渐获得这种经验？

尤其是在代码所有权，以及必须理解算法和代码运行原理这件事上。我之前其实去过一所大学——暂时不说是哪所——有机会旁听一些学生展示他们能做什么。我们出于善意向其中一位学生指出了一些问题，比如：“哦，你能否在代码中换一种方式实现这里？这里似乎存在一些隐患。”对方回答：“嗯，这只是 Claude 输出的内容。”这几乎是在推卸对代码的所有权。我当时就想：“啊，这是一种我们必须解决的心态。”我们必须把这些东西视为工具。你仍然对自己构建的东西拥有所有权，也仍然必须对最终发布的内容负责。此外，我们还需要思考如何指导这些正在成长的初级工程师。我也听到其他组织说：“好吧，现在我们只需要能构建这些东西的高级工程师了。”

也许这是真的，但你知道高级工程师是从哪里来的吗？是从初级工程师成长而来的。你最终必须培养他们。那么，人们应该通过什么途径进入这个行业？我还记得自己曾有过那样一个顿悟时刻：因为我编写了代码，屏幕上的某个东西真的动了起来。自那以后，我便迷上了开发。如今，由于人们会进行一些凭感觉编程之类的事情，这种体验可能已经变得有些平淡了。那么，你认为应该如何培养下一代工程师？首先，如何让他们进入这个行业，有成效地学习，并获得你提到的那种亲手实践的体验？在常规激励机制之外，又该如何持续指导他们？

是的。从某个角度来看，我觉得我们已经拓宽了接触软件工程能力的人群范围。我年轻时也有过类似的经历。当时我还是个青少年，在自家地下室里摆弄 Visual C++，心里想着：“哇，这也太酷了。我以前甚至不知道还能做到这种事。”那段经历最终引领我走上了自己的职业道路。我认为，现在有很多人会觉得：“哇，我可以直接动手做一个网站，或者做一个小工具，或者做出某个能够解决问题的东西。”从很多方面来看，这让我回想起自己的童年。当时的软件还远没有发展成今天的样子。市面上只有为数不多的程序，你得去商店购买，把软盘插进驱动器，然后进行安装。

而如今，一个人可以直接制作一个应用并使用它，这种想法真的极具赋能作用。我认为，这实际上会吸引更多人想成为软件开发者、想成为软件工程师。我觉得，接下来我们会重新回到这样一个问题：好吧，你可以