内容概要
Dhanji R. Prasanna 是 Block（前身为 Square）的首席技术官，在过去的两年里，他管理着超过 4000 名工程师。在他的领导下，Block 成为了世界上最具 AI 基因的大型公司之一。在成为 CTO 之前，Dhanji 曾向 CEO Jack Dorsey 撰写了一份“AI 宣言”，点燃了整个公司的转型之火（并使他晋升为 CTO）。在这期播客中，我们讨论了 Block 内部的开源智能体 Goose 如何每周为员工节省 8 到 10 个小时，公司如何衡量技术和非技术团队的 AI 生产力提升，哪些团队从 AI 中受益最多（答案可能出乎意料），以及一项比 AI 工具更能提高生产力的“无聊”组织变革。我们还探讨了代码质量与产品成功的关系，如何在整个组织中推动 AI 的采用，以及从构建 Google Wave、Google+ 等失败产品中汲取的教训。
目录
-
介绍 Dhanji
-
AI 宣言：说服 Jack Dorsey
-
转型为一家更具 AI 基因的公司
-
如今工程团队的工作方式有何不同
-
Goose：Block 的开源 AI 智能体
-
衡量跨团队的 AI 生产力提升
-
Goose 是什么及其工作原理
-
AI 在工程和生产力方面的未来
-
人类品味的重要性
-
构建软件 vs. 购买软件
-
AI 如何改变招聘和团队结构
-
在部署 AI 工具前亲自使用的重要性
-
Goose 如何帮助解决个人收据问题
-
Goose 的独特之处
-
Dhanji 在成为 CTO 前希望了解的事情
-
产品开发中反直觉的教训
-
为什么受控的混乱可能对工程团队有益
-
核心领导力课程
-
失败角
-
闪电问答与最终思考
介绍 Dhanji
Lenny: 关于 AI 带来的生产力提升有很多讨论。有一派人觉得这被过分夸大了。
Dhanji: 什么都没用。没有人真正在大规模采用这个。
Lenny: 我们看到了显著的收益。我们发现，那些非常、非常 AI 优先的工程团队报告每周大约能节省 8 到 10 个小时。
Dhanji: 每当我听到这样的数据时，我都会想，一个重要的因素是——这已经是它最糟糕的表现了。这现在是基线。
Lenny: 事实是，它的价值每天都在变化。所以你需要紧跟这股浪潮。
Dhanji: 我在另一个播客上听你分享过一个故事，有个工程师让 Goose 观察他。他可能正在 Slack 或邮件上和同事讨论
Lenny: 他们会讨论某个他们认为值得实现的功能
Dhanji: 几个小时后，他会发现 Goose 已经尝试构建了那个功能，并在 Git 上为它创建了一个 PR（拉取请求）。
Lenny: 哪个级别的工程师从这些工具中受益最多？
Dhanji: 令人惊讶且真正了不起的是，非技术人员正在使用 AI 智能体和编程工具来构建东西。
那些能够接受它、并针对自己特定的工作日和任务进行优化的人，正从这些工具中展现出最大的影响力。
Lenny: 你认为未来几年工程师的工作方式会与今天有何不同？
Dhanji: 所有的这些大语言模型 (LLM) 在夜间和周末都处于闲置状态，而人类却不在。这完全没必要。它们应该一直工作。它们应该尝试预判我们的需求来构建东西。
Lenny: 在构建产品或团队方面，你学到的最具反直觉的教训是什么？
Dhanji: 很多工程师认为代码质量对构建成功的产品很重要。这两者之间毫无关系。
Lenny: 今天，我的嘉宾是 Dhanji Prasanna。Dhanji 是 Block 的首席技术官，他管理着一个超过 3500 人的团队。在 Dhanji 的领导下，Block 已经成为世界上最具 AI 基因 (AI native) 的大型公司之一，并且基本上实现了许多产品负责人正试图在他们公司实现的目标。
在我们的对话中，我们聊到了他们内部的开源智能体，叫做 Goose。据他们估算，Goose 平均每周为员工节省 8 到 10 个小时的工作时间，而且这个数字还在上升。我们谈到 AI 具体是如何让他们的团队更有效率，以及哪些团队受益最多——有趣的是，并非工程团队。
我们还聊了将公司文化转变为 AI 导向需要付出什么，他们内部做的一项非常“无聊”的改变所提升的生产力甚至超过了任何 AI 工具。此外，还有从构建 Google Wave、Google+ 和 Cash App 中学到的教训，以及更多内容。
这一集适合任何对一个高度 AI 优先、技术驱动的大型公司是什么样子以及如何运作感到好奇的人。如果你喜欢这个播客，别忘了在你的播客应用或 YouTube 上订阅和关注。这对我帮助极大。
如果你成为我付费时事通讯的年度订阅者，你将免费获得 16 款出色产品的一年使用权，包括 Devon、Replit、Lovable、Bolt、NANA、Linear、Superhuman、Descript、WhisperFlow、Gamma、Perplexity、Warp、Granola、Magic Patterns、Raycast、Chapardd 和 Mobin。请访问 lennysnewsletter.com 并点击“Product Pass”。
接下来，在赞助商的简短介绍后，我将为您带来 Dhanji Prasanna。
本集由客户通信云 Sinch 赞助。关于数字客户通信，你需要知道一点：无论你是发送营销活动、验证码还是账户提醒，你都需要它们可靠地触达用户。这就是 Sinch 发挥作用的地方。
全球有超过 15 万家企业，包括全球排名前 10 的科技公司中的 8 家，都在使用 Sinch 的 API 来将消息、电子邮件和通话功能构建到他们的产品中。在消息传递领域，有一件产品团队需要了解的大事正在发生：富通信服务 (RCS)。
你可以把 RCS 看作是短信 2.0。你的用户将看到你经过验证的公司名称和 Logo，而无需下载任何新东西，而不是从随机号码收到短信。这是一种更安全、更具品牌化的体验。此外，你还可以获得交互式轮播和建议回复等功能。
为什么这很重要？因为美国运营商正开始采用 RCS。Sinch 已经在帮助全球主要品牌发送 RCS 消息。他们正在帮助 Lenny's Podcast 的听众在热潮席卷美国市场之前率先完成注册。访问
了解更多并开始使用。网址是
。
本集由 Figma Make 的开发者 Figma 赞助。当我在 Airbnb 担任产品经理时，我还清楚地记得 Figma 刚问世时的情景，以及它极大改善了我们团队的运作方式。突然之间，我可以让整个团队参与到设计过程中，非常迅速地对设计概念给出反馈，这让整个产品开发过程变得有趣得多。
但 Figma 似乎并不适合我。它很适合在设计上提供反馈，但作为一个构建者，我想创造东西。这就是 Figma 打造 Figma Make 的原因。只需几个提示，你就可以将任何想法或设计变成一个功能齐全的原型或应用，任何人都可以对其进行迭代并与客户一起验证。
Figma Make 是一款与众不同的“Vibe Coding”工具。因为它完全集成在 Figma 中，你可以使用团队现有的设计构建模块，轻松创建出外观精美、感觉真实，并与团队构建方式相连接的输出。不要再花费那么多时间告诉别人你的产品愿景，而是直接展示给他们看。使用 Figma 快速制作带代码的原型和应用。请访问
查看。
Dhanji，非常感谢你来到这里，欢迎做客播客。
Dhanji: 谢谢你，Lenny。很高兴来到这里。
AI 宣言：说服 Jack Dorsey
Lenny: 我想从一封信开始，我听说你曾写信给 Jack Dorsey，试图说服他和 Block 公司需要更严肃地对待 AI。我想你称之为你的“AI 宣言”，而且这封信似乎真的奏效了。我们会聊到很多因此而来的改变。所以，我想问问你，你在这封信里说了什么？你发信给他之后立刻发生了什么？
Dhanji: 大约两年半前，Jack 真的觉得事情需要改变了。我想他感觉到行业正朝着一个不同的方向发展。于是，他每周把公司大约 40 位高管召集到一个房间里，他们会一起讨论所有正在发生的事情。他也把我加进了那个小组。
在某个时刻，我观察到我们虽然在谈论很多深刻、相关的事情，但似乎没有人真正关注 AI。就在那时，我写了那封信。说实话，它现在已经有了自己的生命力。但信里其实没太多内容，无非是“我认为我们应该做这件事。我认为我们应该集中力量去做。我们必须走在行业前沿，成为一家 AI 基因的公司，因为这正是行业的发展方向。”
Lenny: 我得指出，那时候你还不是 CTO。你当时只是一位高级工程师，对吗？
Dhanji: 实际上，我当时是兼职，因为我刚有了孩子，正在逐步回归工作，帮助一个工程团队。然后 Jack 飞到悉尼，和我待了两天。我们都喜欢长时间散步，所以我们绕着悉尼走了个遍，把所有事情都谈透了。然后，他就给了我这份工作。我认为这是一个千载难逢的机会，所以我接受了。
Lenny: 这就像是“小心你擅长的事”那种情况。
转型为一家更具 AI 基因的公司
Lenny: 好的。那么，在 Jack 和 Block 的高管们都表示同意，认为“这完全正确，我们需要在 AI 如何改变我们的构建方式以及我们应该如何构建上投入更多、思考更深”之后，你们做出了哪些较大的改变？从其他公司倾听者的角度来看，他们应该考虑做些什么？
Dhanji: 一开始，我的主要重点是让 Block 像一家科技公司一样思考。在很长一段时间里，我们有点……我称之为“身份漂移”。也许我们在说自己是一家金融服务公司。有些人叫我们金融科技 (fintech) 公司，诸如此类。但是，当我刚开始在当时还叫 Square 的公司工作时，我们一直被认为是一家科技公司，就像谷歌、Facebook 或其他公司一样。
所以我想让我们回归本源。我做的第一件事就是尝试建立一系列专注于此的项目。从把公司顶尖的个人贡献者 (IC) 聚集在一起互相交流，到启动一大堆特别项目。我们为每个项目配备了大约两到五名工程师，总共有大约八九个不同的项目。我们还恢复了全公司范围的黑客周 (Hack Week)。
所有这些就像点燃了一点火花，让大家觉得：“嘿，我们又在构建技术了。我们又在尝试推动前沿了。”这就是开始。在那之后，还有一系列步骤，我们从事业部 (GM) 架构转变为职能型组织 (functional org) 架构，我认为这是我们转变为一家更具 AI 基因的公司的关键。
Lenny: 好的，多谈谈这个。这是什么意思？它看起来是怎样的？为什么它如此重要？
Dhanji: 当然。当公司处于成熟阶段时，Square 已经是一项非常大的业务，运转良好。然后我们启动了 Cash App，它也遵循了同样的路径。我们几乎是把它们作为独立公司的组合来拆分的，我们称之为 GM 架构。所以，它们实际上是作为一系列独立公司来运营的，它们有自己的 CEO，都向 Jack 汇报。虽然仍是同一个执行团队，但他们有各自独立的工程实践、独立的设计团队。除了像法务、部分平台等共享资源外，他们在几乎所有方面都是独立的。
我认为这对于我们当时所处的公司阶段非常有用。但是，当你真的想在技术上深入发展，当你真的想把握这些正在发生的、足以改变行业的事件时，你需要一个单一的焦点。
我们改变了组织架构。现在，所有工程师都向一个统一的团队汇报。所有设计师也向一个统一的团队汇报。我们有统一的工程负责人、统一的设计负责人，等等。这就是我们做出的重大转变。这意味着我们可以真正推动 AI、推动平台以及整体的技术深度。
Lenny: 对于那些可能正为此挣扎或试图弄清楚该怎么做的公司来说，我听到了两点。一是开始将自己视为一家科技公司。这不一定适用于每家公司，但一个重要因素似乎是：“我们是构建技术的。我们不是金融公司。我们不是房地产公司。我们不是抵押贷款公司。我们是一家科技公司。”
第二是，组织团队的方式应该是让工程师向工程领导者汇报，而不是向一个可能不太懂工程、或者不够重视工程的 GM 汇报。
Dhanji: 是的，这差不多就是我们所做的。而且，我不想过度解读，但这正是乔布斯回到苹果时所做的事情。他把苹果重组为职能型架构。
我们并不是在遵循什么剧本。这是我们在探索如何让这些团队更注重技术、如何让我们的基因回归本源时发现的。我们的本源就是真正地把工程和设计放在首位，这对我来说就是“技术优先”的含义。所以，是的，我会对其他公司说，找到你们的基因，并真正尝试以一种简单明了的方式去优化它。
如今工程团队的工作方式有何不同
Lenny: 好的。所以你做了很多改变。你发表了那份宣言，所有人都同意了。你做了很多改变：职能型、技术优先。那么，对比现在和两三年前，你们的工程团队的工作方式最大的不同是什么？
Dhanji: 并非所有人都同意。我得告诉你，那是一个相当痛苦的转型。
我认为，在这个过程中我学到的最重要的事情之一是康威定律 (Conway's Law) 的力量真的非常、非常强大。这条定律基本上是说，你交付的就是你的组织架构。所以，你在团队、协作小组以及运营模式上的组织方式，对你构建出什么产品至关重要。
我认为这本质上是最大的变化。过去，我们在 Cash App、Afterpay、Square 甚至我们的音乐流媒体服务 Tidal 等各个业务孤岛中都有很大的惯性。没有人真正在互相交谈。没有人真正在技术战略上保持一致，甚至对于“作为一个集体团队，我们五年后想成为什么样”也没有共识。
现在所有这些情况都不同了。我不是说现在已经完美了，我们面前还有很长的路要走，但至少我们使用同一种语言。我们所有人都能使用相同的工具。我们共享相同的政策。比如，某个级别的资深工程师在整个公司范围内意味着同样的事情。人们可以从一个团队流动到另一个需要帮助的领域。
所有这些都大不相同了。但总而言之，我想说我们现在以技术为中心，并且我们专注于将提升技术卓越性作为一个目标，这在两三年前是完全谈不上的。我的意思是，那时候我们有其他需要优化的东西。
Lenny: 也许可以再深入一层，谈谈人们日常工作的具体方式。如果你观察一个工程团队，比如一个平均水平的工程团队，也许还有一个最优的工程团队，他们今天的工作方式与几年前相比，在细节上有什么不同？
Dhanji: 某些非常、非常 AI 基因的团队，或者那些在所有地方都优先构建 AI 的团队，他们的工作方式与以前大不相同，因为他们在使用“Vibe Code”（基于氛围或直觉编程）工具，并且基本上是在不手写代码行的情况下进行构建。
这在两三年前是完全不存在的。我认为在全世界任何地方都不存在。所以，这在那些仍在使用非常沉重的遗留代码库的团队中，差异是巨大的。虽然情况没那么普遍，但他们也正在接触这些后台的 AI 流程。
我们有些工具是 7x24 小时运行的，或者在 CI（持续集成）管道中运行，它们会分析漏洞。它们甚至会查看工单 (ticket) 上提交的 bug，并在工程师睡觉时尝试构建补丁。所以工程师第二天来上班时就可以直接查看了。
所以，我想说它们在很多方面都不同了，但不同的团队根据他们与这些工具的接近程度，以不同的方式进行了调整。
Goose：Block 的开源 AI 智能体
Lenny: 好的。那我们来深入聊聊 AI 这部分，我认为这是你们公司遥遥领先于其他许多公司的地方。你们构建了自己的……我想你们称之为“智能体” (agent)，叫 Goose。关于 AI 带来的生产力提升有很多讨论。有一派人觉得，“你根本不明白 AI 能带来多大的生产力提升。这是未来。一切都将这样运作。我们都在 10 倍速前进。”但也有一派人觉得，“这被过分夸大了。什么都没用。人们只是说说而已。所有这些试点项目都失败了。没有人真正在大规模采用这个。”我感觉你可能属于第一派。从 AI 工具中，你们团队实际获得了什么样的收益？
Dhanji: 我们的首要任务是自动化 Block，这意味着让 AI 和各种形式的 AI 自动化贯穿我们整个公司。我们觉得，这仅仅是所有这些大语言模型发挥效用的开始。我认为我们将继续看到这种情况的改善。
但即便是现在，我们发现那些非常、非常 AI 优先、每天都在使用 Goose 的工程团队，报告每周大约能节省 8 到 10 个小时。这是他们自己报告的，然后我们也有一些核查指标来尝试验证这一点。所以我们会看 PR（拉取请求）、看功能的吞吐量，我们会看很多东西，然后让我们的数据科学家得出一个复杂的公式，试图把所有这些提炼成有意义的东西。
我们感觉在整个公司范围内，我们可能正朝着节省 20% 到 25% 的人工工时迈进。我认为这仅仅是这一切的开始。我确实觉得，那些更具 AI 基因的公司在实现这一点上做得更好，主要是那些从一开始就以 AI 为核心的创业公司。
但“AI 不是万能药”这种说法也有一定道理，它的能力也仍在增长，对吧？所以你需要紧跟这股浪潮。我认为很多公司没有意识到这一点。他们会说：“价值在哪里？”而事实是，价值每天都在变化。所以你需要保持适应性，着眼于今天的价值，并规划明天的价值。然后慢慢地扩展到那些最有效的领域。
我给你举个例子。我们发现一个它真正擅长的领域是，让非技术团队为自己构建小型软件工具。这是 Goose 在 Block 内部最令人惊讶和振奋的用途之一。比如，我们的企业风险管理团队构建了一整套用于企业风险自服务的系统。这将数周的工作压缩到了几小时。
在过去，他们需要等待内部应用团队之类的去构建这个，然后团队会把这个放进他们第二季度的路线图里，每个人都得束手无策地等待，直到一切就绪。但现在，你直接就可以去做了。所以，在很多这类用例中，我们看到了巨大的生产力提升。
另一个让我非常兴奋的领域是，我们有另一个叫做 Gling 的工具，它实际上是移动端的 Goose。它使用辅助功能 API (accessibility API) 在原生级别操作你的安卓操作系统。我们用它来自动化 UI 测试。以前，你可能需要雇佣一大批承包商或 QA（质量保证）人员去点击每一个屏幕，但现在我们可以把这些纳入自动化测试，并在最后给你一份报告。所以我们在这些类型的领域看到了很多优势。
但是，在那些需要大量深度和很多非常强大的人聚集在一起的领域，我认为 AI 的表现仍然不如人类。这一点未来可能会改善，但这也是我们作为人类应该加倍努力的地方。
所以，当你有一些非常资深的工程师，他们在思考架构、设计、竞争条件 (race conditions)、编排 (orchestration) 之类的事情时，这仍然是 AI 尚未达到的领域。我认为那些没有在 AI 上感受到成功的公司，正试图把这些工具扔给他们庞大的代码库，并期望好事发生。
但这并不会奏效。最终，我认为它会达到那个水平，但现在我们仍处于早期的实用阶段。
衡量跨团队的 AI 生产力提升
Lenny: 天啊，你刚才分享的信息量太大了。我至少有五点想跟进。
好的，第一点是你提到的那个指标，也就是你们如何衡量 AI 在团队中的影响。你说的是“节省的人工工时” (manual hours of humans saved)，是这样描述的吗？
Dhanji: 是的。
Lenny: 目前，一个工程师大约有四分之一的时间被 AI 工具节省下来了。
Dhanji: 这个指标是涵盖所有团队的。所以这包括我们的支持团队、法务团队、风险团队，所有这些团队加在一起。
Lenny: 哇。
Dhanji: 然后在工程方面，差异非常大。因为就像我之前说的，这取决于代码库有多大、多复杂。所以，如果你在构建一个全新的“绿地”代码库 (green fields codebase)，或者在为新平台构建应用，那么我们确实看到了那些相当可观的收益。但在那些已经存在的、非常复杂的代码库中，这种收益还没那么明显。
Lenny: 这太惊人了。每当我听到这样的数据时，我都会想，人们需要考虑到的一个重要因素是——这已经是它最糟糕的表现了。
Dhanji: 这是最低点。这现在是基线了。
Lenny: 是的。所以，这可能听起来还不算太疯狂，但它将会变得疯狂。
Goose 是什么及其工作原理
Lenny: 好的。你谈到的另一件事是 Goose。你还没解释 Goose 是什么。这可是个大事。请解释一下 Goose 是什么，以及它对你们为什么如此重要。
Dhanji: Goose 是一个通用的 AI 智能体 (general purpose AI agent)。你可以把它想象成一个桌面工具或一个程序，你可以下载并安装到你的电脑上，然后它有一个用户界面 (UI)。你可以像和聊天机器人一样和它对话，你可以说任何话，从“嘿，Goose，按类别整理我的照片”，它就有能力查看你的照片，如果有很多树，它会把它们归类为自然照片，如果人很多，它会归类为人像，诸如此类。它还可以为你编写软件。所以它可以完成所有这些任务。
我们能够做到这一点，是通过一种叫做“模型上下文协议” (Model Context Protocol, MCP) 的东西，你们的听众中很多人可能听说过。这是 Anthropic 公司提出的，我们是它的早期贡献者之一。
模型上下文协议非常简单，它只是围绕现有工具或现有能力的一套形式化的封装器 (wrapper)。所以，如果你在企业中使用一些工具，无论是 Salesforce，还是 Snowflake 或 SQL，任何这些东西，你都可以用 MCP 把它们封装起来，然后这就把它们暴露给了你的大语言模型 (LLM)，让模型能够去操作它们。
在那之前，LLM 除了聊天之外，真的做不了太多事情。但是 Goose 给了这些“大脑”手臂和腿，让它们能够在我们的数字世界中行动起来。这就是我们发现它产生最大影响的地方。它构建在这个相当开放的协议之上，任何人都可以实现它。现在 MCP 已经呈爆炸式增长。顺便说一句，Goose 是完全开源的。所以你们任何人都可以下载它、扩展它、编写自己的 MCP。这就是我们通过 Goose 取得的核心成功。
Lenny: 好的。所以这本质上就像是 Claude Code，但它是在 Claude、OpenAI ChatGPT 和一系列开源模型之上，构建了一个带 UI 的桌面应用。是这样吗？
Dhanji: 是的，它可以使用任何模型。我们有一个可插拔的提供商系统 (pluggable provider system)，你可以带上你自己的 API 密钥，使用 Claude 家族的模型或 OpenAI 家族的模型，或者你也可以使用开源模型。你可以下载它们，然后直接使用，或者通过 Ollama 和其他一些工具来使用。
但本质上，它是利用了这些模型生成文本和理解文本的能力，并将它们应用于真实世界的场景。我非常喜欢的一个例子是，你可以让 Goose 去为你生成一份营销报告。它有 MCP 可以连接到 Snowflake、Tableau 和 Looker。所以它会编写 SQL 从那里拉取数据。它会做一些 CSV 分析，所以它可以在你的桌面上编写 Python 代码来完成这一切。它会使用它知道的某个 JavaScript 图表库生成一些图表。最后，它会把所有这些放进一个 PDF 或 Google Doc 或其他什么文档里，它甚至可以帮你把这个用邮件发出去或上传到某个地方。
顺便说B，它做所有这些都是自主的。没有人坐在这里指挥它。你只是说：“嘿，我想要这份报告。我想把它用邮件发到这里。我想要这些漂亮的图表。”它就在所有这些系统之间进行编排 (orchestrating)。
Lenny: 所以在 Block 内部，大家不再直接使用 Claude 或 ChatGPT，甚至也不用 Cursor 或其他这类应用，他们用的是 Goose？
Dhanji: 我们允许我们的工程师和全体员工使用他们想用的任何工具。Goose 是与我们所有系统集成得最好的一个，因为它构建在 MCP 之上，而且为现有系统创建一个 MCP 非常容易。
举个例子，如果你在用一个工单追踪工具 (issue tracking tool)，你想给它增加一些 AI 自动化功能。在有 Goose 之前，我们的团队必须等待这个工具的供应商把 AI 功能构建进去，或者也许 OpenAI、Anthropic 或 Google 会提供某种通用能力，让我们能把它们接入进来。
但有了 Goose，这就不再是必需的了。只需要几行代码（一个 MCP 所代表的），所有这些系统几乎一夜之间就可以通过 AI 进行编排。而且 Goose 还可以编写自己的 MCP。所以它的引导启动 (bootstrappable) 能力也很强。
Lenny: 而且这是开源的。基本上你们花了所有时间构建了这个东西。现在任何其他公司都可以拿去用，并在你们所有工作的基础上继续构建。
Dhanji: 是的。我们有很多公司在非常活跃地使用 Goose。我不想点名太多，但从我们的竞争对手到我们的紧密合作伙伴，很多都在他们的团队中相当频繁地使用 Goose。我知道 Databricks 经常谈论它，但基本上，你能想到的这个中等规模技术公司梯队里，大家都在以某种形式使用 Goose。
Lenny: 这太疯狂了。这感觉本身就可以成为一个巨大的业务。就像……世界上增长最快的一些公司，这基本上就是他们的产品，而你们把它构建出来并免费送出去了。
Dhanji: 我们相信开源的力量。我们的核心使命之一就是增加开放性 (openness)，这意味着为开放协议和开源做贡献。作为一家科技公司，我们是建立在大量开源软件之上的。我认为几乎每家科技公司都是如此，无论你谈论的是 Linux、Java 还是 MySQL，或是其他任何这些基础组件。所以我们觉得我们有强烈的责任去回馈。我们想构建的东西，不仅对我们和我们的客户有益，而且能够比 Block 存在得更久、成长得超越 Block。这一直是我们的核心价值观，从一开始就是如此，甚至早在 AI 阶段之前。所以，Goose 延续了这一光荣传统。是的，我们为它能取得这样的成功感到非常兴奋。
Lenny: 顺便问一下，Goose 这个名字有什么故事吗？我忍不住想问。
Dhanji: Goose 是在致敬《壮志凌云》 (Top Gun)。
Lenny: 好的。
Dhanji: 提出这个名字的工程师，他本人长得也和 Goose 一模一样。如果你把他们并排放在一起，简直太疯狂了。
Lenny: 我分享这个他可能会很尴尬，但这就是为什么叫它 Goose 的原因。然后我们就顺着这个鸟类的主题发展下去了。
Lenny: 太不可思议了。我听你在另一个播客上分享过一个故事，说有一个工程师把这个发挥到了极致，他让 Goose 观察他。谈谈那个故事吧。
Dhanji: 是的，当然。他非常、非常专注于 AI，他正试图从 Goose 身上挖掘出所有这些疯狂的想法。Goose 不仅能通过与工具的特定交互来完成我描述的所有事情，它还能直接观察你的屏幕。它能通过截图理解如何处理图像和它所看到的东西。
所以他构建了这样一个系统，Goose 基本上时时刻刻都在观察他做的一切。他可能正在 Slack 或邮件上和同事讨论，他们会讨论某个他们认为值得实现的功能，几个小时后，他会发现 Goose 已经尝试构建了那个功能，并在 Git 上为它创建了一个 PR。
还有各种其他古怪的事情。比如，如果他开会超时，下一个会议快迟到了，它会尝试把他从当前的工作流中“推”出来。它会想出这些他没有编程、也没有为之编写提示词 (prompt) 的创意，但它认为这些创意能帮他提高效率或改善他的工作日。
所以，是的，这挺疯狂的。你必须得有这个承受能力，才能和你的工作工具绑定到这种程度，但这也向你展示了这类工具的可能性。
Lenny: 很明显，一旦这个技术足够好，未来就是这个方向。我喜欢这个家伙，他只是在尝试。所以，它基本上是在看他工作，预测他应该做什么，并帮他完成初稿。这样他就会觉得，“哦，我们刚在会上讨论的这个东西，PR 已经完成了。”
Dhanji: 太不可思议了。
Lenny: 没错。
Dhanji: 它现在有多好？如果让你从 0 到 100 打分，100 分是“你只需要思考和说话，它就能完成你的工作”，它现在在哪个水平？
Dhanji: 是的，语音是它的另一大块。它有语音处理能力。所以它也总是在听他说话，并试图理解。
我想说这主要还是个实验。因为他本身就在我们的 Goose 核心团队，为 Goose 做贡献。他有自己的日常工作。这（指被 Goose 观察）是他业余时间开发的东西。
一旦这个功能演变成 Goose 本身或我们企业中使用的其他工具的更原生的特性，我认为它会大有可为，但它现在已经相当不错了。我的意思是，它可能帮他减少了巨量的繁杂工作。
举个例子，他会说：“哦，我有个会议冲突。那个时间去不了。”或者“我得去接我的孩子。”Goose 会自动帮他重新安排那个会议，而他根本不需要坐在日历前点来点去。
Lenny: 是的。这些事情，我们以前可能都在等日历工具的供应商把它们作为功能内置进去，但我们现在不再需要了，因为 AI 能够为我们编排这些。
Lenny: 这不是那个在四家不同创业公司同时干四份工作，并能把他所有工作都并行处理的家伙吧？
Dhanji: 不，不是他。他是我合作了很长时间的人，他在 Block 待了很久。他只是热爱实验，他体现了那种实验文化，就像 Goose 的创造者一样，他也做了同样的事情。
AI 在工程和生产力方面的未来
Lenny: 那我们来顺着这个思路聊聊。你正在窥见事物发展的未来。你在 Block 的很多方面都走在了前沿。你认为未来几年，工程师的工作方式、产品团队的工作方式，会与今天有何不同？
Dhanji: 我认为这在很大程度上取决于 LLM 性能的提升。但我可以告诉你我正试图改变我自己工作的方式，以及我正试图改变我们直属团队的工作方式。
我认为“Vibe Coding”（氛围编程）一直是一件有趣且令人兴奋的事情，你基本上是在和一个聊天机器人对话，它就去为你构建软件。但我认为这有很大的局限性。它非常像打乒乓球：你做点什么，然后等上三四分钟，它给你一个半成品。你必须去推动它、引导它、打磨它，才能让它达到要求。
我认为我们将看到更强的自主性 (autonomy)。我们正在用 Goose 的下一个版本做几个实验，我们真的在推动它去工作，不只是每次两三分钟或五分钟。我们现在（在 Goose 上）的中位会话时长是五分钟，平均是七分钟，但我们正试图把它推向几小时。
我们想说的是，嘿，所有这些 LLM 在夜间和周末都处于闲置状态，而人类却不在。这完全没必要。它们应该一直工作。它们应该尝试预判我们的需求来构建东西，就像我们之前聊到的那样。
而且我认为，它们应该能够以一种前所未有的方式去构建。以前，我们作为人类，资源有限、带宽有限，还有大量的协调开销。所以我们必须在实验中选择那条最好的路径去尝试。
我认为我们不再需要那样了。相反，我们应该能够非常详细地描述多个不同的实验。然后也许我们去睡觉了，早上醒来时，所有这些实验都构建好了。我们可以扔掉其中的五六个。
我每天都写代码，我经常做的一件事就是扔掉巨量的代码。这对我来说有点难，因为我以前从没这么做过。很明显，工程师都喜欢删代码，但这是两码事。这是指你构建了一个全新的系统或一个全新的功能，然后你觉得，“啊，感觉不太对。我还是删了重来吧。”所以，我认为你会看到越来越多这样的工作方式。
我认为，未来我们可能不再是去重构 (refactoring) 一个应用，让它有不同的 UI 或进化到新版本，而是会直接从头重写那个应用。
我正在推动我们团队思考的一件事是：如果我们每次发布新版本时，都 rm -rf（删除）掉整个应用，然后从头重建它，我们的世界会是什么样子？
我们今天还不能真正做到这一点。但我认为这向你展示了未来可能性的一些方向，以及这些工具将把我们带向何方。
Lenny: 有趣的是，在软件工程和产品领域，有一条常见的规则：永远不要重写。不要试图重写你的东西，因为你会忘记过去这些年里所有的微小改进、调整和 bug 修复。你以为这会是一个简单直接的事情，结果却花了一年甚至更长时间，才让你回到原来的状态。AI 现在让这成为可能，而你所说的是，这也许正是你未来应该的工作方式，这真的很有趣。
Dhanji: 我是这么认为的。我认为这里的诀窍是，让 AI 尊重所有那些渐进式的改进。
Lenny: 是的。
Dhanji: 并且把那些（改进）作为规范 (specification) 的一部分融入进去。
Lenny: 是的。
Dhanji: 还有，你提到关于智能体的观点，你给它一堆想法，它一夜之间把它们构建出来，然后你就可以看到了。我能想象它甚至会向价值链上游更进一步，它自己提出想法，然后开始构建它们，然后你就像：“哦，那是个好主意。我现在可以在同一个工作流里立刻看到它了。”
Dhanji: 是的，没错。我上周就真的在尝试你说的这个。我正在开发一个新版本的 Goose，我让它为“如何改进自己”提出想法，并在一夜之间实现它们。
Lenny: 自我修复问题。
Dhanji: 是的。有时候它会完全偏离脚本，你必须得把它拉回来一点。所以我认为我们还没有完全进入那个它能完全自我改进、完全自主的时代。
但我确实认为我们正处于一个过渡阶段。我们可以给它一点推动，说：“嘿，这是我希望你能做的 10 件事的愿望清单。去找出最好的方法来实现它们。”
如果这些功能被描述得足够好，它在大概 60% 的事情上是成功的。但在剩下的 40% 上它会遇到困难，你就必须介入并打磨它。
Lenny: 是的。哦天，我只是在想象那个未来：你给它的目标是“推动收入和增长”，然后它就说：“好了，所有人都被解雇了。这是你们的工资单。接下来我接管了。”
人类的品味的重要性
Dhanji: 我不认为我们会到那一步。老实说，我确实认为我们需要大量的人类品味 (human taste) 来锚定 (anchor) 这些 AI，让它们不至于偏离脚本。这确实是我们的设计负责人和设计团队正在推动我们去思考的方向。
我认为这是一个差异化因素，它将推动我们超越现在这个“AI 废料” (AI slop) 泛滥的时代。所以，是的，这很像是把它锚定在对人们重要的事情上，锚定在有品位的、有用的、有价值的事情上。
Lenny: 能否让这个更具体一点？有没有一个例子，比如 AI 试图做什么，或者一个团队试图提议什么，而你必须站出来说：“不，这是人类需要介入、让事情保持正轨的地方。”
Dhanji: 我会说这更多地是围绕像流程自动化这样的事情。很多时候，我会收到这样的请求，某个团队会说：“我们需要从这个供应商那里购买这个新工具，因为我们现在的工具做不到 X、Y 和 Z。”然后另一个团队会说：“不不不，我们可以用 Goose 构建一个应用，用一半的时间或更少的时间就能为我们做同样的事情。”
然后，作为一个人，你坐在那里思考：这有必要吗？如果我们只是改变一下流程，我们是不是根本不需要考虑构建工具？
这就是 AI 不擅长的事情。它无法拥有这种全局性的判断 (portfolio judgment)，或者说无法从全局角度判断什么是重要的、什么才是关键的。
所以很多时候，我会告诉团队，尤其是我们的信息安全 (Infosec) 团队，去质疑那个最基本的假设。因为他们有时候会为了保护某个东西而把自己绕进去，然后你就会说：“好吧，你直接让构建那个东西的团队换种方式去做，或者如果它不重要，就干脆不要构建它。”这样你就不必增加保护它的（安全）攻击面了。
所以我认为，在这些领域，由人类来运用判断力会更好，而 AI 在这方面做得并不好。
构建软件 vs. 购买软件
Lenny: 你提到了关于“构建自己的软件、自己的工具，而不是购买东西”的观点。这是关于 AI 的一个大问题。它会取代所有这些 SaaS（软件即服务）应用吗？Salesforce 是不是要完蛋了？你们有没有感觉到，通过构建自己的东西到底节省了多少钱？或者，你们是否对现有的、每个人都在使用并花费大量金钱购买的 SaaS 软件产生了新的敬意？
Dhanji: 我认为，偏离你作为一家公司的核心目标是一个陷阱。我们的核心目标是经济赋权 (economic empowerment)。所以，要让客户、商家或艺术家能够完成一笔销售、支付他们的租金，或者把他们最新的创作上传到 Tidal。
我认为，任何服务于这个目标的事情，我们都应该鼓励并投资。但如果我们只是纯粹地在比较“金钱 vs. 金钱”，那就像是把我们从那个目标上拉开了。用内部构建的东西替换掉一个供应商工具，所节省的成本，很可能抵不上你因此失去的脑力带宽 (mental bandwidth)，以及团队技术焦点被分散的代价。
所以，是的，我会说，还是要不断回归到那件对你作为一家公司真正重要的事情上。剩下的，自然会随之而来。
Lenny: 是的，我想人们忘记了维护一个你构建出来的东西需要多少工作。就像，“酷，我们一个周末就把它构建出来了。”然后接下来是长达数年的无尽维护、需求和支持。
Dhanji: 而且，回到你的观点，这感觉又回到了那个古老的座右铭：只专注于你的核心竞争力 (core competencies)，然后购买其他一切。
Dhanji: 这是个经典的 80/20 问题。我们在为客户构建应用时也经常遇到这个问题。比如，我们会构建一些非常能引起共鸣的出色实验，然后我们就必须花费大量时间去解决那些长尾问题 (long tail of problems)。
以 Cash Card 为例，我想说，我们大概在一个周末，或者说一周的集成和工作之内，就构建了 Cash Card 的全部功能。但之后花了很长很长时间才解决了所有那些边缘情况 (edge cases)。比如，有人会给账单金额两倍的小费，然后这会彻底搞垮后端的某个东西；或者人们在加油站用它，而加油站有不同的扣款方式。
所以，是的，就是这么回事。回到你的观点，我总是会回归到：“我们做这个的理由是什么？为什么它对我们和我们的客户很重要？”如果它不能明确地满足这一点，我就会把它当作一个没意思的事情推开。
AI 如何改变招聘和团队结构
Lenny: 围绕 AI 的讨论中，最大的一部分是关于招聘、工作岗位之类的话题。我这里有一个两部分的问题。
第一，所有这些 AI 工具的兴起和生产力的提升，是如何影响你们规划招聘名额 (headcount) 和进行招聘的？
第二，既然 AI 在你们的工作方式中扮演了如此重要的角色，你们现在招聘时，会寻找哪些与以往不同的特质？
Dhanji: 我不认为事情已经发展到了从根本上影响“你需要多少人才能构建一个像 Cash App 这样规模的应用”的程度。
我认为，对我们来说，改变是截然不同的，而且与 AI 无关。这就是我们早些时候谈到的：从 GM 架构转向职能型架构。
在我们的 GM 架构中，我们的激励机制总是倾向于将工程招聘名额视为一种商品 (commodity)。所以，如果我们想构建更多功能，我们就会增加更多工程师。这是经典的《人月神话》(Mythical Man-Month) 的陷阱。
我认为转向职能型架构彻底改变了这一点。你会想：“好吧，我们可以利用公共的平台、公共的模块。我们可以从整个公司引入专家，为我们如何更好地做这件事提供建议。”
所以我认为，是这些因素极大地改变了我们的招聘方式。我们不再把工程师看作是一种商品，不是为了去构建 Cash App 的下一个产品就增加 100 个人。
但在 AI 方面，我们非常希望寻找那些拥抱这些工具、并渴望从中尝试和学习的人。我们并不是在寻找从一开始就是顶尖 AI 从业者的人。我想我们有那样的人，如果他们愿意和我们一起工作，我们当然感兴趣。但我更倾向于寻找那样的大学毕业生，他们真的渴望了解这些工具，并对此持开放态度；或者甚至是那些已经拥抱并掌握了这些工具的资深人士。这才是我们优化招聘的方向，而不是去寻找一套特定的技能。
Lenny: 所以本质上最大的变化就是寻找那些拥抱 AI 的人，而不是那种说：“不，我不需要这些东西。我是一个了不起的工程师。我不需要用 Cursor 或 Goose 或所有这些东西”的人。
Dhanji: 我会称之为“学习型心态” (learning mindset)。这是我们的 CEO Jack 经常谈论的事情。他希望我们成为一家“学习优先” (learning first) 的公司。我们做的每件事、我们交付的每个实验，我们能从中学到什么？我们是否觉得自己已经尽了最大努力？
我认为，对他来说，这甚至比每次都得出正确的商业答案更重要。
Lenny: 那么面试的时候呢？你们会鼓励工程师在做练习时使用 AI 工具吗？在过去一两年里，这方面有什么变化？
Dhanji: 是的，我们现在开始这么做了。传统上，我们只是用 CoderPad 之类的工具，在白板上讨论一个问题，甚至是用伪代码或接近伪代码的方式来编程。
但现在我们正在考察：你能否使用“Vibe Code”来构建东西？你对这些工具的熟悉程度如何？或者你如何看待与它们一起进化？
但这还处于早期阶段。我想说，目前我还不太清楚，一个人是否知道如何使用（无论是 Goose、Cursor 还是其他任何工具），与他是否是一名优秀的工程师有多大关系。我仍然认为，我们过去面试时所看重的那些东西——批判性思维 (critical mindset)、真正深入理解问题技术本质的能力——仍然远比“你是否是一个完全 AI 基因的程序员”要重要得多。
Lenny: 另一个我一直在思考、很多人也在想的问题是：哪个级别的工程师从这些工具中受益最多？你可以说，是初级工程师，因为他们现在可以完成所有这些工作了。你也可以说，是高级工程师，因为他们对事物如何运作有更深的理解，他们可以指挥成千上万的智能体来执行他们的命令。根据你的观察，哪个级别受益最多？
Dhanji: 是的。对此有两个答案。
第一，你说的绝对没错，越是资深和越是初级的工程师，他们越愿意或越渴望采用这些 AI 工具。我认为这背后有多种原因，包括你提到的一些。比如，我认为资深人士真的在很深的层次上理解一切是如何运作的。所以，当这个工具出现，能帮他们去完成那些他们已经做了一百万遍、懒得再做的事情时，他们几乎是松了一口气。
而初级工程师则像是……我的侄子侄女们在用黑莓手机（不，是早期的 iPhone）一样，他们飞快地处理各种事情。当我还得在键盘上费力地“搜索并摧毁”（指打字慢）时，他们已经闪电般地发出了短信。这暴露了我的年龄。
所以我认为有这个因素。但我认为，非技术人员使用 AI 智能体和编程工具来构建东西，这才是真正令人惊讶和了不起的。
我认为这预示了未来这些角色将如何演变。法务、风险、工程甚至设计之间的界限将变得模糊。
所以我认为，那些能够拥抱它、并针对自己特定的工作日和特定任务集进行优化的人，才是真正从这些工具中展现出最大影响力的人。
Lenny: 这是一个很有趣的观点。没人谈论工程生产力的那个方面，那就是——减少了来自公司所有其他部门的、要求构建各种一次性功能的请求。这对工程师来说，感觉是巨大的生产力提升。
Dhanji: 这是巨大的。不过我认为，这有点像那个比喻：如果你建了一条更宽的高速公路，你只会在路上看到更多的车。所以我认为，事实是，每个人都在构建软件，这意味着有更多的软件需要被构建，有更多的协调需要发生，每个人都更渴望更快地交付成果、取得更大的成就。所以我们只是看到整体的速度在提升，对更多功能的需求也在增加，如果你明白我的意思的话。
Lenny: 是的，完全明白。这也和你之前说“你们没有减缓招聘”的观点联系起来了。我听到的是，对更多工程师、更多产品人员的招聘名额需求根本没有减缓。基本上，就好像 AI 根本不存在一样。
Dhanji: 我们只是在更深入地思考这个问题。就像我说的，在 GM 时代，我们把它视为一种商品。而现在我们是职能型架构，这就更少地关乎“我们需要多少工程师，作为 Square 或 Cash App 功能数量的一个函数”。在职能型组织架构中，我们更多地思考：优化的领域在哪里？我们可以在哪里构建深度？什么能通过模块化、复用和深入平台来真正加速我们的优先事项？
Lenny: 我喜欢这个“热辣”的观点：如果你想提高效率，忘了 AI 吧，直接重组为职能型架构。
Dhanji: 在某些方面，这并没有错。这里还有另一个非常有趣的例子，我们正试图缩短我们的构建时间 (build times)，我们也在使用 Goose 和许多其他工具来帮助我们。
它们做出了非凡的成就。我们有一个非常酷的工具，它会分析我们的测试套件 (test suites)，并为所做的更改选择正确的测试来运行。通过这种方式，我们减少了大约 50% 的测试运行。这相当了不起，我们也减少了因浪费在不必要测试上的 CPU 周期而给地球带来的升温。
但是，像“把测试卸载到云端”或者“干脆删除那些不再有意义的测试”这样的事情，可能为你节省了（比 AI 工具多）两到三倍的时间。
所以，你仍然需要一个“组合拳”的策略 (portfolio approach)。这就像我之前给你举的那个例子：我们是应该购买一个供应商工具，还是应该在内部构建它？问题其实是：我们到底需不需要这个流程？
所以在某些方面，结构 (structure) 远比你所拥有工具的效能 (efficacy) 更重要。
在部署 AI 工具前亲自使用的重要性
Lenny: 很有智慧的观点。这让我想起埃隆·马斯克 (Elon) 有一个关于如何优化事物的完整流程，其中一个步骤就是：“在我们开始优化和自动化它之前，我们真的需要这个东西吗？”
在我把话题拉远，询问你职业生涯中学到的普适经验之前，关于 AI 还有什么你认为可能对那些试图更深入拥抱 AI、或者只是想帮助团队更具前瞻性思考的人非常有价值或有用的吗？
Dhanji: 我会说，一定要自己去尝试使用这些工具。
我认为，我们能够推动（AI）被大规模采用的主要方式是：Jack 在用 Goose，我在用 Goose，我们的高管团队都用过 Goose，并且经常使用它，也使用其他 AI 编程工具和助手。
我们每天都在这样做。因此，我们对自己工作流程的改变有了很多了解。这比你去看 LinkedIn 或《哈佛商业评论》上的各种思想文章，然后再试图让你的团队照做，要有效得多。
所以，我认为我们对所有事情都是这样做的。去感受它，亲自使用产品，感受它，了解它的优点、缺点和人机工效 (ergonomics)，然后再弄清楚如何把它应用到你的团队中。
Goose 如何帮助解决个人收据问题
Lenny: 我发现这样做很有帮助，我完全同意你的观点，那就是别再只是阅读相关信息了。别再听我们谈论它了，直接去构建一些东西。我发现真正有帮助的一点是：要有一个你想为自己解决的具体任务或问题。
Dhanji: 是的。
Lenny: 因为那真的能激励你，让事情变得非常真实。举个例子，就在前几天，我试图从一个 Google Doc 里把图片提取出来。你知道，Google Doc 就像我心中的“加州旅馆”。你把图片放进去，但除非你做一些疯狂的操作，否则根本拿不出来。所以我就去了 Lovable（一个 AI 应用构建工具），说：“帮我构建一个应用，我给你一个 Google Doc 的 URL，让我能轻松地把图片下载下来。”然后“砰”，搞定了。
Dhanji: 是的，非常好的例子。几个月前我也做了类似的事情。我儿子需要接受很多治疗，他有一些额外的需求。所以，我试着收集所有这些治疗的收据，然后分享给我的妻子，她好去向保险公司报销。
我做这件事的时候非常费劲，因为它们格式各异。有些是截图，有些是 PDF。所以我让 Goose 来做这件事。它们都在我的笔记本电脑上。Goose 发现它可以把所有这些收据放进我的苹果备忘录 (Apple Notes) 应用的单个笔记里。
它把它们转换成了 HTML，这样就可以无缝同步到我的手机上，然后我就可以从手机上发邮件或分享给她了。这是我以前绝对想不到的。它是用 AppleScript 做到这点的。它就在后台帮我控制了我的电脑。
所以，是的，这些工具帮助我们的方式是出人意料的。就像你说的，你越是用它们来解决真实的问题，你就越能理解它们的优势在哪里，以及你可以把它们部署在什么地方。
Lenny: 我喜欢这个例子。所以，你当时是直接去跟 Goose 说：“我有这么个问题。你会怎么解决它？”吗？
Dhanji: 差不多。我说：“我所有这些收据都在 Google Drive 里。”（我们有相似的源头问题）“我需要把它们整理成单一的格式，并且我需要把总额加起来。”
它一开始尝试了几种方法。它试图下载它们，试图用 PDF 阅读器去读，等等。关于 Goose（我想很多其他 AI 智能体也从我们这里学到了这一点），它的特点是，如果它尝试了几件事都失败了，它会退一步，尝试一条不同的路径，它会一直尝试下去，直到取得一些进展。
它就是这么做的。然后它选择了 AppleScript 作为实现方式，因为它有那个 MCP 扩展，可以控制我的电脑。
这和我们之前谈到的那个工程师用来观察他屏幕的（技术）是同一个东西。但这是一个非常聚焦的问题，它成功地做到了。所以，是的，这些工具能做到的事情是令人惊讶的，而允许它们拥有这样做的灵活性，是学习如何使用它们的重要一环。
Goose 的独特之处
Lenny: 太酷了。顺便问一下，作为一个普通人，我能运行 Goose 吗？我能直接下载 Goose 来替代（其他工具）吗？
Dhanji: 当然可以。是的，你完全可以从我们的 URL 下载它。我们可以在节目笔记里分享出来。
你可以安装它。它支持 Mac、Windows 和 Linux。我相信它是一个 Electron 应用，所以都能用。它也有一个命令行（界面），所以对于那些更习惯用命令行的用户，我们也有那个 UI。
Lenny: 哇，你们这真的是在和那些大型基础模型公司竞争啊。把 Goose 和其他东西做个最简单的比较，它是什么？它最像的是 Claude Code 吗？还是别的？
Dhanji: 我认为它和 Claude Code 有点不同，因为 Goose 的核心是一个实现了 MCP 的平台。MCP 赋予了它这种动态可扩展的特性。所以，它能为你做所有这些事情，无论是像我们刚才谈到的那样，自动化 Google Docs 和备忘录之类的东西，还是使用其他 MCP（比如索引代码）为你执行纯粹的编程任务。
所以，它更像是一个可扩展的平台。我会说，它介于那种你只能问它“今天天气怎么样？能帮我算算从这个日期到现在过了几个月？”的经典 AI 助手，和那些更专注的（工具）如 Cursor 和 Claude Code 之间。
Lenny: 基本上，它就是所有东西的结合体。天啊。而且是免费的。
Dhanji: 你需要为 LLM 的 token 付费，但是的。
Lenny: 是的，可以用开源模型。我的天，这太疯狂了。在 Block 构建 Goose 的团队一定很酷。你们一定玩得很开心。
Dhanji 在成为 CTO 前希望了解的事情
Dhanji: 哦，天啊。
Lenny: 好的，让我把话题拉远一点。你担任 CTO……我正在看你的 LinkedIn，差不多快两年了。如果你能回到几年前，在你的耳边低语几句建议、技巧或教训，有什么是你希望在担任这个角色之前就知道的？
Dhanji: 我想大概有两件不同的事情。
第一件就是康威定律 (Conway's Law) 的力量。就像我们之前谈到的，如果你不改变组织中人与人之间的关系结构，要想改变产出是多么困难。我想我以前在某种程度上是知道这一点的，但真正发自内心地去体会它，是件大事。
另一件我（也许是）通过惨痛教训才学到的事情是：你只会在事情出错的时候才听到消息。所以，当事情进展顺利时，你会陷入一种诡异的沉默。你会想：“我做的事情对吗？我关注的问题对吗？”
所以，你真的需要腾出时间来后退一步，从全局看待事物，你需要有这样的判断力。这些是你必须定期去做的事情，我希望我在刚接任这个角色时就知道这一点。
Lenny: 回顾你在 Block 的时光……我总是差点说成 Square，因为这么多年已经习惯了，但我知道 Block 是整个公司的名字，而 Square 只是……（我这么说只是为了让人们理解）Square 是 Block 内部的一个业务单元、一个产品。
Dhanji: 没错。我们有 Square、Afterpay、Cash App 和 Tidal，这是我们的四个主要品牌。然后我们还有 Bitkey 和 Proto，它们专注于为我们做比特币相关的业务，它们是硬件产品。
Lenny: 好的，太好了。我觉得有些人可能会想：“你们到底在说什么？”好的，酷。
产品开发中反直觉的教训
Lenny: 那么，回顾你在 Block 的时光，关于构建产品或构建团队，你学到的最具反直觉的、与大多数人所相信的（比如常见的创业智慧）相悖的教训是什么？
Dhanji: 我认为一个是代码质量。作为一名工程师，我很早就意识到了这一点，而且它一次又一次地被验证。
很多工程师认为代码质量 (code quality) 对构建成功的产品很重要。这两者之间毫无关系。
我最喜欢的例子是 YouTube。我在 YouTube 被收购前后在谷歌工作。我只记得当时公司内部充满了各种焦虑，都在说 YouTube 的代码库有多糟糕，他们的架构有多烂，他们居然用 MySQL 里的 blob（二进制大对象）来存储视频，等等。
但是，你可以说 YouTube 是谷歌迄今为止最成功的产品，对吧？它可能比他们其他很多产品的总和还要成功。所以，这真的和它当初的架构有多好没什么关系。
因为反过来看，Google Video——我不知道是否还有人记得这个产品，它在 YouTube 之前就存在了——它支持更多格式、支持更高分辨率、你可以上传长达一小时的视频。YouTube 什么都没有。它只有那种一两分钟的快速短视频。但它遥遥领先，完胜了它的竞争对手。
所以我认为，要把这一点牢记在心：我们为什么要去构建这些工具、应用或产品？它们是为了人们去解决一个特定的问题。在我们的案例中，是为了让一个 Square 商家能完成一笔销售，卖给你一杯咖啡，或者卖出他们制作的东西。
这才是真正重要的。我们的安卓平台性能有多好，其实并不重要……除非它服务于那个需求。
所以我认为，这在我整个职业生涯中都是一个很难（但很深刻）的认知。我不断地遇到有工程师认为“我们需要重构 (refactor)。我们需要用一种更好的方式来做这个。我们需要……”然后我就会说：“不，所有这些代码明天可能都会被扔掉。所以，只专注于我们试图构建什么，以及我们为谁而构建。”
Lenny: 这是一个令人难以置信的洞察和教训。YouTube 这个故事太有趣了，也是个绝佳的例子。你是说他们把视频……内容，存在 MySQL 的一行一列里，作为 blob 数据？
Dhanji: 是的，这是……这是……我的意思是，我没有真的去看过代码，所以我无法验证。但这是当时普遍的说法。而且他们用的是一个纯 Python 的技术栈，与谷歌当时已经高度优化的、最先进的 C++ 和 Java 服务器相比，它慢得令人难以置信。
Lenny: 太搞笑了。这也让我想到了公司……当你在一家公司内部，如果你在那工作，你只会觉得：“这里简直是纯粹的混乱。没人知道发生了什么。这一切马上就要分崩离析了。”而这基本上就是每家成功的、高速增长的公司的常态。
Dhanji: 是的，这在某种程度上是真的。
Lenny: 所以我认为，这再次说明了，对于一个企业的成功而言，有太多更重要的东西。就像你说的：你是否在为人们解决一个真实的问题？你能不能把（产品）交到他们手中？你能否持续为他们解决真实的问题？这与代码质量无关。这与你内部运作得有多好无关。
Dhanji: 绝对如此。
为什么受控的混乱可能对工程团队有益
Dhanji: 我认为在 Cash App 上我们也是如此。在 Cash App 早期，我是工程负责人，从我们大概只有 10 个工程师开始，一直到 200 多人，带着它做到了大概 1000 万还是 2000 万用户。
那里也有非常相似的情况。从外部看，一切似乎都非常混乱。比如，人们会构建各种随机的实验，然后就发布了。看起来我们并没有在诸如软件生命周期之类的事情上遵循严格的政策。
这在某种程度上是真的。我的理念一直是：我们拥有所有这些才华横溢的工程师，如果我试图把他们束缚在非常严格、狭隘的领域里，那我造成的伤害将远大于带来的好处。如果他们想花点时间，去构建一些完全是浪费时间的东西，但与此同时，他们反过来也能交付那些令人惊叹的成果，那我几乎会允许那样做。我会接受的。
这是一个微妙的平衡，因为如果你放任不管，工程师真的会钻进兔子洞里。
但是，是的，混乱 (chaos) 中会孕育出一定程度的创造力 (creativity)，你必须知道如何在某种程度上构建“受控的混乱” (controlled chaos)。所以，你必须创建一个不会轻易破裂、不会出现重大可靠性问题、或者（在我们的案例中）不会让你亏钱的基础。
只要这些事情得到了保障，你允许你的工程师拥有实验、迭代、做那些能激励他们的事情的自由——这就是理想状态。
Lenny: 说到“受控的混乱”，你在 Block 期间，有一个头衔……我猜这是你在 Square 的时候……叫做“疯狂科学家” (Mad Scientist)，持续了四年半。
Dhanji: 是的，那段时间我主要是兼职，因为我的孩子们还很小，有很多额外的需求。我在各种不同的项目上担任顾问，试图帮助一些古怪的事情启动起来。我真的很感谢 Block，他们给了我在职业生涯中拥有那样一个角色的自由。
核心领导力课程
Lenny: 在我们进入“失败角”（我稍后会解释）之前，也许还有最后一个问题。你分享了一些你在职业生涯中学到的教训。还有没有其他……比如说，你学到的核心领导力课程，你认为这些课程对你成功完成你所做的工作非常重要？
Dhanji: 我认为，做任何事情都要“从小处着手” (start small)。
“如果你想为了泡一杯茶而烧开整个大洋”，我不知道这是谁说的，但这是一个非常有用的短语，我时常会想起它。你永远也达不到目的。所以，如果你要泡一杯茶，那就只泡那杯茶。你不需要把所有的水都烧开。
Lenny: 那听起来是杯非常难喝的茶。海水……
Dhanji: 是的，我想还有另一个（说法）……卡尔·萨根 (Carl Sagan) 好像说过：“如果你想从头开始做一个苹果派，你必须先发明整个宇宙。”所以，（关键是）把你的范围缩小到你面前的、可实现的事情上。
我认为这非常重要，这一直是我们的核心原则之一，甚至在我们早期还只是 Square 的时候就一直是。从小处着手。
Lenny: 有没有哪个例子，是这个原则运用得特别好，或者可能没奏效的？
Dhanji: 有，Goose 就是从小处着手的。它一开始只是一个工程师在用自己的时间，试图构建一个有用的、能满足他所持有的一个论题的东西。Goose 的创造者 Brad，他在很早（早于我们听到这个流行词）的时候就相信，智能体 (agent) 将是我们从 LLM 中释放价值的方式。
他构建了一个概念验证 (proof of concept)，并分享给了一群人。他分享给了 Databricks 和 Anthropic，让他们也兴奋起来，并从他们那里学到了很多。所以它就是从那里开始逐步积累势头的。
甚至在内部，情况也非常相似。Cash App 本身也是如此。Cash App 最早或多或少也是一个黑客周 (Hack Week) 的点子，然后越长越大。所以我们的很多项目都是从这些小实验开始，然后我们试着在它们的基础上继续构建。
我们成为了第一家推出比特币产品的上市公司。那又是一个黑客周的点子，是 Jack、我和另一个工程师一起做的。
Lenny: 那就是黑客马拉松的团队？你、Jack Dorsey 和一个工程师？
Dhanji: 是的，就我们三个。
Lenny: 难以置信。
Dhanji: 那很棒。我们去 Blue Bottle 买了一杯咖啡，是用 Cash Card 上的比特币买的。
Lenny: 哇。
Dhanji: 我得告诉你，现在回想起来，那可能是史上最贵的一杯咖啡。
Lenny: 当时比特币多少钱？大概 6000 或 7000？
Dhanji: 好像是。
Lenny: 哦不。现在大概 12 万了。太棒了。
Dhanji: 通货膨胀啊。但这就是一个例子，说明了如果你先专注于一件小事，然后再去构建，你是如何能得到一个对人们有用的工作产品的。
Lenny: 这与“好吧，我们有个大想法，我们直接往上堆资源，马上就大干一场”的做法是相反的。
Dhanji: 是的，完全相反。我也待过那样的团队。我职业生涯中曾在谷歌为一个叫 Google Wave 的产品工作过。它试图成为所有人的所有工具。在我们它甚至还没有任何谷歌之外的用户之前，我们就已经有七八十个工程师在构建它了。
所以我认为，这是一个“起步就很大、试图第一天就做大”的例子，它可能缺少了那种与大地的接触……缺少了与现实的连接，以及据此调整的能力。
Lenny: 我还记得 Google Wave。它很漂亮。炒作得很厉害。我不记得它具体是干什么的了，但它看起来真的很好。
Dhanji: 是的。我从那个项目中学到了很多。
Lenny: 还有其他重大的教训吗？
Dhanji: 那两个是最大的。但我还会说：质疑所有事情的基本假设。
你知道，有时候我们会陷入陷阱，作为专业人士，我们过度专注于我们那天、那周、那个月在构建的东西。而我们没有停下来想一想：我们到底应不应该构建这个？或者构建这个的目的是什么？我们能不能构建一些完全不同的东西，对我们的核心存在理由更重要？
所以我会说，是的，质疑那些最基本的假设。这有点老生常谈，但你真的需要不断提醒自己去应用它。
Lenny: 我以前在播客上请过你的一个同事，Ayo，你俩一起在 Cash App 工作过。
Dhanji: 是的。
Lenny: 他是我的朋友。他很了不起。他当时也引用了类似的话，我记不太清了，但大意是：“深入到你正在做的事情的‘裸金属’ (bare metal) 层面。”就像，去触摸你正在构建的东西，深入它的最底层，去真正理解发生了什么。我猜这在构建 Cash App 和 Cash Card 时非常重要。
Dhanji: 是的，Ayo 是我合作过的最棒的产品人之一，他也是我最好的朋友之一。所以，在这一点上，我完全同意他和你的看法。
失败角
Lenny: 好的。我要带你进入播客的一个固定环节。我称之为“失败角” (Fail Corner)。你已经分享过一个你参与过的、失败了的产品例子（指 Google Wave）。我好奇是否还有另一个？
这个问题是：你参与过的一个失败了的产品是什么？因为听这个播客的人，总是在节目里听到所有这些了不起的、成功的人，分享他们各种成功的故事，无尽的成功。但他们没有听到那些事情不顺利时的故事。
所以问题是：你参与过的一个失败了的产品是什么？它教会了你什么？
Dhanji: 这是一个很有价值的观点。我的意思是，我的职业生涯基本上就是一连串失败产品的叠加。
Google Wave 的例子算一个。我还在 Google+ 短暂工作过，那是另一个史诗级的失败。
Lenny: 这个好。
Dhanji: 我曾在一家叫 Secret 的社交网络创业公司工作，它曾昙花一现，然后就爆炸了。然后还有一个我们做的电子邮件创业公司，也曾非常有前景。
Lenny: Canva 的联合创始人（注：指 Cameron Adams，Dhanji 的前同事，Canva 的 CPO）和我一起做的那个。所以，有过一连串的失败。
但在每一个节点，我都学到了一些东西。我学到了，我需要永远不再犯那一类的失败或错误。
所以 Cash App 可能是我（职业生涯里）的巨大成功，那是我很早就参与的一个产品，它成长为……一个人们喜爱的巨型业务和产品。
所以，是的，这就是我的职业生涯：本质上就是从所有这些失败中吸取教训，并在这个过程中变得谦逊。带着……愿意倾听他人观点、批判性观点的态度，而不是总认为自己拥有一切答案。
Lenny: 我敢打赌，所有这些失败的产品，都有非常漂亮的代码。很多非常好的架构决策。
Dhanji: 有些是……有些是在各个方面都很糟糕。所以它们失败的理由太多了。
Lenny: 太不可思议了。
Dhanji，在我们进入激动人心的“闪电问答”环节之前，你还有什么想分享的，或者想再次强调的吗？
Dhanji: 我想说的是，你知道，我们正处在一个充满巨变的时代。人们对未来的走向感到害怕、迟疑或不确定。
我认为，你应该关注那些对你重要的事情。你知道，对我们来说，是开源、开放协议、为每个人增加（成功的）机会。
在我的职业生涯中，我一直非常幸运，只参与那些要么免费、要么几乎免费、要么有免费版本然后你为某些高级服务付费，并且是所有人都能使用的产品。
就像，任何人都可以成为 Square 商家。我记得，甚至在早期，人们用它（指 Square）来互相转账，作为 P2P（个人对个人）的转账系统。这就是我们构建 Cash App 的原因，它在此基础上取得了巨大的成功。
所以我认为，真正要做的，是关注那些对你重要的事情……并为之优化。技术趋势往哪个方向发展，其实并不那么重要，因为技术是为我们服务的。如果我们有一个重要的存在理由和一个重要的目标，那么我们就可以让技术为我们服务。这远比……深入掌握技术或站在每一个趋势的最前沿要重要得多。
Lenny: 这是一个非常棒的建议。在有这么多事情需要关注、这么多事情正在发生的当下，（这种建议尤为可贵）。你会感到压力很大，觉得：“我根本不知道所有的事情。我在 AI 上发生的事情，并不像我在社交媒体上看到的那些人那么厉害。我感觉自己落后太多了。”
我从你这里听到的是：到底什么对你才是真正重要的？去做那就行了。不要觉得你需要成为所有正在发生的事情中最好的那个，也不需要了解所有最新的 AI 新闻。
Dhanji: 是的，完全正确。而且，如果这件事没有意义、没有乐趣，那你可能根本就不应该做它。
闪电问答与最终思考
Lenny: 带着这个观点，Dhanji，我们来到了非常激动人心的“闪电问答”环节。我为你准备了五个问题。准备好了吗？
Dhanji: 好的，放马过来吧。
Lenny: 我看到你身后有那么多书，所以我很喜欢第一个问题。我很好奇你会选什么。有哪两三本书是你最常推荐给别人的？
Dhanji: 是的。我非常……我持有的观点是，你不应该读那些关于你日常工作或职业生活的书。
我读小说、读经典、读诗歌、哲学、历史。这些是我真正喜欢的书。我认为这能拓展你的思维，给你创意的灵感，帮助你质疑关于人类境况 (human condition) 的问题。这远比读那些关于……如何成为一个好的工程经理的自我提升书籍要有价值得多。
话虽如此，《大师与玛格丽特》(The Master and Margarita)，作者是米哈伊尔·布尔加科夫 (Mikhail Bulgakov)，这是我非常喜欢的一本。它是俄罗斯文学的杰作。
然后……我一直很喜欢丁尼生 (Tennyson) 的诗。我发现在我最不确定或悲伤的时候，丁尼生的诗歌总能与我产生共鸣，帮助我找到内心的平静。
Lenny: 哇。这两个推荐我以前从没听过。我非常期待去看看。对于一个大型科技公司的 CTO 来说，（这个推荐）非常酷。
你最近看过的电影或电视节目中，有没有特别喜欢的？
Dhanji: 《异形：地球》(Alien: Earth)。我觉得非常棒。它的作者是诺亚·霍利 (Noah Hawley)，他也拍了《冰血暴》(Fargo) 电视剧。所以，这就像是……一个拥有所有这些高雅艺术电影制作技巧的人，在拍一部低俗科幻 (pulp sci-fi) 剧集。
它看起来令人惊叹，感觉也令人惊叹。它捕捉到了所有那些“异形”的精髓……那种让它变得如此有趣和好玩的低俗感。所以我非常喜欢。
我还在看《流人》(Slow Horses)，我认为这是电视上最好的剧集之一。
Lenny: 我爱《流人》。新的一季出来了。我想就在我们录制的这一天，第五集刚播出。我超爱那部剧。
《异形：地球》，我也刚看。太诡异了，到处都是黏糊糊、爬来爬去的小生物。让人很不舒服。
Dhanji: 我就是喜欢它的美学。他们抓住了原版《异形》的精髓。他们做到了……《异形：地球》的每一个场景都感觉像是在看一幅画，或者在听别人给你读小说。它展开得非常……深思熟虑。
Lenny: 我这辈子从没看过任何《异形》相关的内容，但我真的很喜欢《异形：地球》。不过我得说，结局让我觉得有点……感觉节奏慢下来了。我就想：“好吧，我大概猜到它要往哪里发展了。”但观看过程真的很有趣。
好的，下一个问题。你最近有没有发现什么特别喜欢的产品？可以是一个应用、一个小工具，或者某个厨房用品。
Dhanji: 嗯，我是一个游戏玩家。我爱玩游戏。所以对我来说，是 Steam Deck，Steam Deck OLED，这是他们的最新版本。它是一个非常华丽的硬件，让你能玩上现在最棒的那些游戏，但它又是完全可扩展和可定制的。
在这个时代，大型科技公司不断地告诉我们，我们需要把一切都锁起来。我们需要锁定用户体验和可定制性，才能让东西为人们所用。
但我认为 Valve（Steam Deck 的开发商）证明了，这完全没必要，也完全是错的。你可以构建……在 Steam Deck 上，你可以安装竞争对手的应用商店，你可以在上面安装 Windows，你可以把它当作一台电脑来用，在上面编写程序（我就这么干过）……
所以，是的，我认为它是一个不可思议的东西，它看起来很美，用起来也很棒。我是它的忠实粉丝。
Lenny: 你有没有什么最喜欢的人生格言，无论是在工作还是生活中，你经常会想起的？
Dhanji: 如果你早上醒来时，没有对你那天在职业生活中要做的事情感到精力充沛，那就改变点什么。如果实在不行，那就辞职。
或者，找到一种新的方式来做你正在做的事情。不要只是接受别人分派给你的东西。我一直努力这样做，有时候管用，有时候不管用。但，是的，这是个值得问自己的好问题。
Lenny: 我非常喜欢这个建议。但对很多人来说，这真的很难做到。有没有什么东西帮助你克服了那种恐惧，比如：“天啊，我要辞掉这个工作了。我不知道我接下来要去哪里。”
Dhanji: 最主要的是告诉你自己：一年后，你再回头看现在这个看起来天大的问题、改变人生的事情时，你会觉得：“哦，那太微不足道了。”
你知道，很多时候我们都会陷入这样的陷阱：我们过度思考某件事，或者对做出改变感到非常紧张。但事后看来，那些事情似乎都没那么大不了。从那以后流逝的时间和发生的所有事件，都在教导你这个世界远不止于此。而且，去做有用的事永远不晚，为你自己、为提升自己去做事也永远不晚。
所以，是的，我认为只要记住：事情并不像当下看起来那么重大、那么黯淡或那么具有决定性，这总是很重要的。
Lenny: 最后一个问题。你在 Square 当了很多年的“疯狂科学家”。在流行文化或现实生活中，你有没有另一个最喜欢的“疯狂科学家”？
Dhanji: 这是个有趣的问题。我脑海中总是浮现出的形象是……《回到未来》(Back to the Future) 里的布朗博士 (Doc Brown)。
我觉得他就是……至少是我这一代人心中“疯狂科学家”的典范。虽然在电子游戏之类的（领域）里也有很多，但他就是那种：“我就是要去做这件疯狂的事，因为我内心有这种燃烧的渴望和需求，无论我想不想，我都必须建造这台时间机器。”然后他花了整部电影……去修复它制造出来的问题。但，是的，他对我来说一直是个非常有趣的角色。
Lenny: 你知道我想到了谁吗？我想到了《粉红鼠和大脑》(Pinky and the Brain) 里的“大脑”(Brain)。（注：此处 Lenny 口误，Pinky 是助手，Brain 才是疯狂科学家）。
Dhanji: 那个也不错。
Lenny: 哦天啊，Dhanji，这期节目太棒了。你太出色了。非常感谢你来到这里。在我们真正结束之前，还有最后两个问题：如果人们想联系你，或者想了解更多关于 Goose 或 Block 的其他事情，他们可以在哪里找到你？以及，听众们能为你做些什么？
Dhanji: 我是说，去看看我们在 GitHub 上的页面吧，Goose 和我们在 Block 的所有其他开源项目都在上面。那里有很多有用的东西。我们在安卓开源方面也做了很多，所以也去看看那些。
你总能在 LinkedIn 上找到我，所以随时来加我好友。我很高兴能和大家联系。
至于人们能为我做些什么……我想说的是，你知道，再次回到我们所处的这个充满变化和不确定性的时代，我认为，那些对他们的公司、对他们的雇主、对他们的团队提出更多要求的人……要求一些更好的东西。
比如在 Block，我们总是会问：“我们能不能默认把这个开源？”“我们能不能为那些不仅仅是我们或我们的客户的人构建这个？”“是不是每个人都能受益？”
我认为这在 AI 时代尤其重要，因为每个人都在把自己锁在“围墙花园”(walled gardens) 里，试图抢占这个正在兴起的平台的一部分。
所以，是的，就是对人们提出更多要求。你知道，互联网被创造出来时的承诺是，为了所有人的利益，开放地共享信息。我认为 AI 应该为我们实现这一点。所以，是的，去对人们提出这个要求吧。
Lenny: 这是一个非常美好的结束方式。Dhanji，非常感谢你来到这里。
Dhanji: 谢谢你，Lenny。我非常享受这次对话。
Lenny: 感谢你。大家再见。
Dhanji: 非常感谢您的收听。如果您觉得本期节目有价值，您可以在 Apple Podcasts、Spotify、Overcast 或任何您收听播客的地方订阅本节目。
