我们整个团队只有大概 15 名工程师。要知道，我们在开发 Devon 的过程中自己也会大量使用 Devon。团队里大多数人肯定都在同时与多达五个 Devon 一起工作。因此，Devon 每个月会向 Devon 自身代码库合并数百个 pull request 并部署到生产环境。你们现在的 PR 中，Devon 提交的和人类提交的各占多少？大概在四分之一左右。你觉得到今年年底会达到什么比例？说实话，我们预计会远远超过一半。你们远远领先于其他公司使用 AI 工程师的方式。AI 将成为我们这辈子最重大的技术变革。过去 50 年里，我们经历的大多数重大科技革命，比如个人电脑、互联网和移动电话，都有一个很大的硬件组成部分，这对产品的普及起到了关键作用。为那些行业做开发的人，基本上眼看着自己的市场随着手机用户数量的增加、随着联网人数的增加，年复一年地稳步增长。但 AI 有一点已经很不一样了，我说的是这项技术可以具有怎样的爆发力。它没有硬件分发环节的负担。这意味着这个领域正在呈指数级增长。工程师的角色以及构建产品的方式正在发生怎样的变化？我认为几年后很快就会涌现出远比现在多的程序员和工程师。当然，程序员这一身份的形态显然会发生变化。但归根结底，这门学科的核心始终在于能够告诉计算机该做什么。从这个角度看，我真的认为随着 AI 越来越强大，编程只会变得越来越重要。今天请到的是 Scott Woo。Scott 是 Cognition 的联合创始人兼 CEO，这家公司推出了一款名为 Devon 的产品，它是全球首个自主 AI 软件工程师。与我在本期播客中介绍过的其他 AI 工具不同，Devon 的设计目标是表现得像一名真正的远程工程师，你可以通过 Slack 或它的专属网站，像与任何人类工程师聊天一样与它交流。大约一年前 Devon 发布时，它还非常像一名初级工程师。过去一年里，他们取得了很大进展，如今 Devon 已被大量公司投入生产使用。我们聊到他们这支 15 人的工程团队如何用 Devon 来开发 Devon，包括每位工程师如何同时使用大约五个 Devon 来辅助编程、加快进度；如今他们四分之一的 pull request 由 Devon 提交，预计到年底这一比例将超过 50%。我们还聊到 Scott 对未来软件工程形态的想象，以及工程师的角色如何从编码者转变为架构师。我们也谈到了他们在确定当前方向之前经历的八次转型，Scott 为什么相信这类 AI 工具会带来更多而非更少的工程师招聘，Devon 这个名字的由来，以及更多精彩内容。本期节目将震撼你的认知。如果你关心工程、产品构建和 AI 的未来走向，我强烈推荐你收听。非常感谢 Claire Vo 为本次对话提供了许多精彩问题。如果你喜欢这档播客，别忘了在你常用的播客应用或 YouTube 上订阅和关注。此外，如果你订阅我的年度newsletter，将免费获得一年 Linear、Superhuman、Notion、Perplexity 和 Granola 的使用权。请访问 lennisnewsletter.com 并点击 bundle 查看详情。话不多说，有请 Scott Woo。本期节目由 Interpret 赞助播出。Interpret 将你所有的客户互动信息——从 Gong 通话记录、Zenesk 工单、Twitter 讨论串到应用商店评论——统一整合起来，并使其可用于分析。Canva、Notion、Loom、Linear、Monday.com 和 Strava 等领先的产品团队都信赖 Interpret，将客户之声引入产品开发流程，帮助你更快地打造一流产品。Interpret 的特别之处在于，它能够构建并更新客户专属的 AI 模型，从而为你的业务提供最细致、最准确的洞察。将客户洞察与 CRM 或数据仓库中的营收和运营数据连接起来，映射出每个客户需求的业务影响，从而自信地排定优先级；同时让团队能够轻松采取行动，例如进行 win/loss 分析、检测关键 bug，以及通过 Interpret 的 AI 助手 Wisdom 识别流失驱动因素。想要像 Notion、Canva 和 Linear 一样自动化你的反馈循环并自信地规划路线图？请访问 enterp.com/lenny 联系团队，注册年度计划可获得两个月免费使用。这是限时优惠。再次提醒，网址是 interpret.com/lenny。你们中的许多人正在构建 AI 产品，因此我非常高兴能与 Paragon 的创始人兼 CEO Brandon Fu 聊聊。嘿，Brandon。嘿，Lenny，谢谢邀请。那么，集成对 AI 产品来说为什么变得如此重要？集成对 AI 至关重要的原因有两个。首先，AI 产品需要来自客户业务数据的上下文，比如 Google Drive 文件、Slack 消息或 CRM 记录。其次，为了让 AI 产品代表用户自动完成工作，AI agent 需要能够跨不同的第三方工具执行操作。那么 Paragon 在其中扮演什么角色？这些集成开发起来非常痛苦，因此 Paragon 提供了一个嵌入式平台，让工程师能够在几天而非几个月内交付这些产品集成，涵盖从 RAG 数据摄取到 agentic 操作的各种用例。而且根据我的亲身经历，维护比首次构建还要困难。没错。我们相信产品团队应该把工程精力集中在竞争优势上，而不是集成上。正因如此，you.com、AI21 等数百家公司都使用 Paragon 来加速其集成战略。如果你想避免把数月的工程时间浪费在客户需要的集成上，请访问 useparagon.com/lenny 了解 Paragon。
Scott，非常感谢你来到这里，欢迎来到本期播客。非常感谢邀请，很高兴参加。我真的很高兴你能来，因为你正在做的事情、并且已经持续在做的事情，与很长一段时间以来许多其他 AI 公司的做法非常不同。尽管他们现在开始朝着你们现在的方向靠拢，我们待会会聊到这一点。而且眼下正是 AI 历史乃至 AI 发展历程中一个非常独特的时刻。所以现在能和你聊天真的很酷，我感觉几年后我们会再聊一次，然后感叹："哇，那么多事情我们看得真准，也有那么多事情我们完全看错了。"是啊。所以很高兴你能来。我们先从 Devon 聊起吧，让大家弄清楚 Devon 到底是什么。这是你们的主力产品。用最简单的方式来说，Devon 是什么？当然。Devon 是一个完全自主的软件工程师，能够端到端地完成任务。在 AI 代码工作流的各个环节都有很多优秀的工具，而 Devon 提供的是一个完整的异步工作流。你可以在 Slack 的 issue 里 @Devon，就是你们在讨论某个 issue 时 @ 它。你可以在 Linear 里 @Devon。你可以让 Devon 介入，它会在你的 GitHub 里提交 pull request。它的设计初衷就是作为初级工程师，与工程团队协作。太棒了。我记得你们发布这款产品时，主打概念是"这是你的新 AI 工程师"。它有很多地方做得很好，也有一些地方还不够好。从你们发布到现在大概有一年了，对吗？是的，没错。如果要从工程师的资历水平来理解 Devon，你们刚发布时那位工程师是什么级别，今天的工程师又是什么级别？不知道这样算不算一种合适的衡量方式。是啊，是啊。回头想想真是不可思议，要知道一年前我们最初发布的时候，大多数人其实不相信 agent 能够实现，对吧？那时候的情况非常不同，大概是 2024 年初，模型的能力无疑还处于相当早期的阶段，尤其是 reasoning 更是如此。而从那之后，显然已经发展了很多。我认为就实际技能而言，我们会做一些类比。有时候我们会说，刚开始时它有点像一名高中 CS 学生，随着时间推移变得更像一名大学实习生，现在则像一名初级工程师。但我要说，这些都只是大致的参照，因为我很喜欢 jagged intelligence 这个说法。因为显然，它在某些方面比人类强得多，在某些方面又比人类弱得多。我认为过去一年我们学到了很多，尤其是不仅仅关于编程 agent，而是关于 agent 整体——如何真正构建出我们所有人与 agent 协作、将其融入工作流的方式。所以我们构建的很多功能，当初是没有 Slack 集成、没有 GitHub 集成、没有 Linear、没有来回互动的规划阶段，也没有修改 Devon 代码的方式。因此，从那之后我们在产品端构建的很多功能，本质上都是在研究如何让与 Devon 协作、将任务交接给 Devon 的体验尽可能顺畅。这很有意思。所以大量工作并不只是为了让 Devon 成为最优秀的工程师，而是研究如何与这种我们从未合作过的新型实体共事。我认为这两者各占一半。能力显然有了巨大提升，我们看到它们变得越来越好，且取得了显著且可衡量的进步，但另一方面则完全关乎产品界面、工具等等。我认为如今人们大体知道如何使用 chatbot、如何与 chatbot 协作，这是大家熟悉的交互界面。而显然对于 agent 来说，我认为学习如何使用它们、如何充分发挥它们的价值，仍然是一条相当陡峭的曲线。所以看到越来越多其他人开始在 agent 领域构建和探索，也非常令人兴奋。但我认为这是我们整个行业都在共同摸索的事情。关于 Devon 目前的规模，你能分享些什么？只要是你方便透露的。以及你认为一年后 Devon 的编程能力会达到什么水平？我们与各个阶段、各种规模的公司合作。最小的一端是一两个人的初创公司，他们用 Devon 来搭建大量初始原型或初始产品；最大的一端则是大型上市公司、Fortune 100 企业或上市银行等，它们在整支工程团队中广泛使用 Devon。总体而言，我们看到的用例范围非常广泛，显然一两个人初创公司所做的工程工作与上市银行所做的非常不同。但贯穿始终的是，Devon 基本上就像是你的初级小伙伴，让你提速，真正成为你的乘数。我认为它能让工程师效率倍增，因为你可以拥有一支 Devon 团队，而不必在单一任务上完全同步地协作。它也能放大你的团队以及团队知识库的效能，因为 Devon 确实会积累与团队中每位成员协作产生的知识，并能在每次新会话中调用这些知识。太棒了。后面我们会在这期播客中向观众展示它的实际运作方式，你会做几个现场演示。不过让我们回到起点。Devon 的起源故事是什么？这一切是怎么开始的？创始团队里，我们大多数人其实已经相识很多很多年了。对几乎所有人来说，这都是我们第一次一起工作，但我们认识彼此很久了。在过去十年左右，我们其实各自都有在 AI 领域的经历。就拿我自己来说，在此之前我经营过一家叫 Lunch Club 的公司，这是一款基于 AI 的职业社交产品，我做了大概五年。我的联合创始人之一 Steven 是 Scale AI 最早期的工程师之一，那家公司显然已经发展壮大、表现优异。另一位联合创始人 Walden 是 Cursor 的早期工程师，Cursor 显然也发展得很好。我们整个团队基本都是这样。我们很多人从竞技编程和数学竞赛就认识了，尽管之后数十年里我们一直保持着密切联系。我们各自都有过不同的职业路径。所以我们有人曾在 Neuro 带领团队，有人曾在 Whimo，有人做过自己的 YC machine learning 工具初创公司。我们非常兴奋能一起做点东西。那是在大概 2023 年底，也就是一年半以前。刚起步的时候，有几件事我们非常坚信，其中之一就是 reinforcement learning 确实奏效，并且将成为能力层面的下一个重大范式转变。要知道，那时候还是 2022 年 chatbot 刚发布的时候，那些模型从根本上说就是我们 AI 领域所称的 imitation learning，也就是基本上让模型读遍互联网上能找到的所有文本，然后训练它像网上的人一样说话。当然之上还有很多细节，但这是对所做之事的一个大致概括。那已经很了不起了，对吧？它通过了 Turing test，能够回应，并且对很多事情拥有百科全书般的知识。而我认为我们在过去一年到一年半里进入的新范式，实际上是 high-compute RL，这是一个非常不同的范式。它的核心在于能够去执行任务、把东西搭建出来，然后被评估正确与否，并利用这些反馈来决定下一步怎么做，从中学习。所以我们非常坚信这一定会发生。对我们来说，代码是天然适合切入的领域，有几个原因。原因之一是我们自己都是程序员极客，所以教 AI 写代码对我们来说简直是最酷的事情；另一个原因是代码本身拥有自动化的反馈闭环——你可以运行代码，而这种自动化反馈能够真正融入 RL，从而让模型在编程方面变得如此出色。此外，我们当时还非常强烈地感受到，产品体验将会从所谓的“文本补全”转向 agents。首先，文本补全确实已经有很多出色的应用场景，比如营销、客服、教育，当然还有编程，GitHub Copilot 基本上就是第一波浪潮中的主导产品。但我们认为真正重大的转变，是从这种“文本到文本”的模式转向一个真正的自主系统：它能够做决策、与现实世界交互、接收反馈、不断迭代，并采取多个步骤来解决问题。现在我们把这叫作 agents，但在当时这就是我们真正感到兴奋的方向。所以一直以来，我们的核心就是编程，就是 agents。从某种程度上说，这从一开始就应该很清楚。但即便如此，在过去一年半的时间里，我觉得我们在编程 agents 这个方向上大概也转了七八次。所以我最近注意到，很多顶尖 AI 公司——不是说全部，但很多——它们最终胜出产品的名字和公司名并不一样，这并不常见。Cursor、Anysphere、Bolt、StackBlitz，还有你们 Cognition Labs，以及像 Vercel 这样的公司。这让我意识到，这些产品都是在公司发展后期才涌现出来的，他们试了很多东西，然后发现“哇，这个行得通”。有趣的是，在这批顶尖公司中这种现象如此普遍——甚至 OpenAI 和 ChatGPT、Anthropic 和 Claude、Google 也是这样。这挺有意思的。是的，我同意。你知道，我们刚开始的时候甚至不算一家公司，更像是一个项目，或者说一场黑客马拉松。我们在感恩节前后租了一间 Airbnb，大概待了几周，把一群热衷于做项目、搞点酷东西的人聚在了一起。事实上，挺有意思的，我们最初做的东西更像是解决竞赛编程问题，用一个 agentic 循环来做得更好。显然，如果你在测试用例上运行代码，就可以进行评估，这里面有很多 agentic 的工作可以做，我们最初也花了一些时间在这上面。从某种意义上说，我们整个公司的故事就是从一间 hacker house 到另一间 hacker house。之后我们又有了另一间 hacker house，Devin 的一些最初想法就是在那里诞生的——我们要做一个软件工程 agent，而不仅仅是一个编程 agent，让它与各种工具交互。但即便如此，当时还是经历了无数次迭代。比如，和 Devin“对话”这个想法也是后来才想出来的。一开始，你只是交给他一个任务，他去执行，然后给你展示完整的代码。而现在，显然你可以随时介入，对计划提出反馈，你们可以一起确定任务范围。很多东西都是我们在过程中逐步开发出来的。当然，我们也学到了很多关于使用场景和产品形态的知识，在能力上做了很多重大改进，甚至是阶跃式的提升，包括 Devin 使用工具、调试和做决策的能力。所以，这是一段有趣的旅程。我想说，对我们来说最根本的问题——也是我们一直在思考的——就是软件工程的未来究竟是什么样的？我们应该如何与 AI 协作来写代码？因为归根结底，这正是我们所有产品决策的底层逻辑。我喜欢你问的这个问题。在我问之前，想先确认一下历史记录：你们是什么时候开始捣鼓这些的？Devin 又是什么时候发布的？那段时间持续了多久？我们从 2023 年 11 月开始的，没错，就是黑客马拉松模式。我们在 2024 年初正式成立了公司，然后在 3 月进行了首次发布。那之后就没停过。我是说，过去 17 个月里一刻都没停。从发布到与企业合作，再到大量开发产品、构建系统，让它适用于很多实际场景，然后在去年 12 月完全开放 self-serve，再到几周前推出 2.0 版本。对我们来说，这段时间忙得不可开交——说“忙”都是轻描淡写了。我想问这个问题，因为你刚才稍微提到了。Devin 作为一个人、为 Devin 赋予个性这个概念——我相信它和其他任何 AI 应用都不一样。没有别的产品像这样有一个名字，让你把它当作一个人来看。你们为什么决定走这条路？又是如何设计让它以这种方式良好运作的？我想说，这是一个让我们颇为自豪的决定。市面上有很多不同的产品体验，而 Devin 真正独特的地方在于你可以真正地把任务交出去。说实话，我们越来越多地发现，向别人解释 Devin 的体验，其实就是告诉他：对，这就是你的初级小伙伴。这适用于整个流程中的很多环节。比如在 onboarding 阶段，最初有很多用户进来，面对空白的屏幕不知所措；或者他们会问：“嘿，我要对整个代码库进行一次大规模重构。”而随着时间的推移，我们学到的是要让人们这样想：“等等，等等，我们先把这个代码仓库搭建好。先给 Devin 一两个简单的任务，让它熟悉代码库。如果 Devin 需要测试代码、运行 linter、CI 之类的东西，我们得确保它有自己的虚拟机来做这些事。”同样，在使用模式上，以前往往不太清楚该怎么做。显然，你可以坐在那里看着 Devin 一步一步地执行。但我们发现，作为一个团队要搭建很多东西，最佳 workflow 其实是同时和多个 Devin 协作，异步运行它们，启动任务，然后只在需要提供反馈或调整计划的时候才介入。所以在很多方面，我认为 Devon 这个名字，实际上是我们试图去捕捉这款产品灵魂的一种尝试——它确实更像是一个自主的实体，你可以把任务交给它，可以与之协作，也应该随着时间的推移去教导它、与它共同学习。我想回到你之前开启、但后来被我带偏了的一个话题，也就是软件工程受到的影响，以及软件工程将如何变化。这大致可以分为两部分。就拿人们如今使用 Devon 来说，比如在今年，工程师的工作方式和构建过程对那些公司来说正在发生怎样的变化？那会是什么样子？顺便说一句，我们自己都是软件工程师。我接受的专业训练就是编程，而且内心仍然是个程序员。我认为我们一直以来思考这个问题的方式是，这里存在抽象的层级和工具。如果从高层次来说，我会这样描述：我认为 AI 总体上……显然，计算机正变得越来越智能，能够做的事情也越来越多，也许有一天计算机真的能完成我们做的所有事情，人类无需为此负责。但我认为这一天不会很快到来。但我想说，在那天到来之前，只要人类仍然参与其中，我们作为人类最重要的事情之一显然就是去指导计算机，告诉它们我们想要什么、想构建什么、想做什么，对吧？如今我们提到软件工程，自然会想到 Python、C++、JavaScript 等等，但归根结底，这门学科的核心就是能够告诉计算机该做什么。从这个角度来看，我真的认为，如果说有什么变化的话，随着 AI 变得越来越强大，编程只会变得越来越重要。而让我们真正感到兴奋的，就是见证这种迭代的转变。所以你问到如今的情况是怎样的。我会说，这就像有一个初级伙伴，或者说是一整队初级伙伴与你一起工作。我们团队在构建 Devon 的过程中大量使用了 Devon。所以 Devon 每个月会向 Devon 的代码库合并数百个 PR 到生产环境中，而我们整个团队只有大约 15 名工程师。因此，这占我们所写代码的相当大一部分。我们使用它的方式基本上是，每个人都拥有一整支开发团队。如果你在浏览各种问题、处理功能需求、排查 bug，或者探索想要构建的新范式，那么很自然会有很多交接点，你会直接说：“嘿 Devon，情况是这样的，你能试着处理一下吗？”
有时 Devon 能够 100% 自主完成任务，直接提交 PR，然后你合并这个 PR，这很好。有时你可能需要在最后 10% 或 20% 真正需要你帮忙的地方介入。也许在一些具体范围或功能架构的细节上，又或者最后你想自己去测试前端，确保它看起来完全符合你的预期，然后给出一两句反馈。但其中很多其实是学习如何与 Devon 协作，从而能够并行完成更多工作，构建更多东西。你们现在的 PR 中，Devon 和人类各自占比多少？我得查一下，但大概占我们所有 PR 的四分之一左右。那六个月前是什么情况？哦，增长非常迅猛，我是说我们在内部也看到了指数级的增长。所以这挺有意思的，因为这始终同时关乎能力和产品界面。我认为智能水平提升了很多，但另一方面，我们也花了很多时间琢磨如何构建，如何真正围绕界面做设计，让 Devon 在那些它能完成 80% 或 90% 的任务上发挥价值。
Devon 显然还不完美，它会犯错等等。所以很多问题本质上在于，你如何与 Devon 划定初始任务的范围，然后让它去执行你想做的事情。最后你如何审阅并给出反馈？如何确保 Devon 随时间学习进步？你如何能够按需检查并在必要时纠正方向？好的。那么如今大约四分之一的 PR 来自 Devon。你认为到今年年底这个比例会是多少？我猜到今年年底，我们预计会超过一半。而且随着时间的推移，我们看到的一点是，你能够异步完成的工作越来越多，能够交接的事情也越来越多。我认为编程的灵魂、软件工程的灵魂，其实始终在于——不仅仅是现在，哪怕是汇编时代、Pascal 时代，甚至是打孔卡片时代——本质上都是去定义你面临的问题，并真正思考清楚你想构建的解决方案到底是什么。思考架构，思考细节，在脑海中精确地勾勒出你想构建的东西，以及你想让计算机执行的操作。我认为这才是软件工程真正伟大的地方，也是软件工程最有趣的部分。但同时我认为，这大概只占普通软件工程师工作时间的 10% 左右，对吧？因为 90% 的时间都在处理：你得调试 Kubernetes 错误，排查系统崩溃原因，或者某个端口没关导致出问题，又或者要处理 bug 报告、迁移代码、升级到新版本等等。更多的是执行层面的工作。而我们构建 Devon 的一个核心思路，可以说是让工程师从砌砖工转变为建筑师。很大程度上就是让你能够进行高层级的指挥，能够完全按照你的意愿去指定需求。我认为这非常强调人类仍然掌握控制权，人类仍然能够完成完整的规格定义，只是将你能在一天、一小时或任何时间内完成和构建的事情的量级成倍放大。那么展望未来，假设有人想进入软件工程领域，考虑成为一名工程师。首先，你认为人们是否应该……如今每个人都在问的经典问题：你还应该学编程吗？所以，我很想知道你对此怎么看。另外，对于当下的工程师而言，在从“砖瓦匠”向“建筑师”转变的讨论中，你认为哪些技能会越来越重要，哪些会越来越不重要？好的，当然。我很喜欢这个问题。首先，关于你是否还应该学习编程，我的答案是绝对应该。我认为在很大程度上，当你学习计算机科学课程、掌握这些基础时，确实会学到一些特定语言的语法之类的东西，但说实话，你学到的大部分内容其实是：第一，逻辑拆解问题的能力；第二，我想说是计算机的模型，以及我们多年来积累的诸多决策和抽象概念。比如什么是数据库，你应该如何理解数据库？什么是垃圾回收系统，它们是如何运作的，以及所有这些不同的组成部分。我认为这很重要的原因是，编程已经经历过类似的阶段，可以说我们已经经历过这些阶段。我认为下一个阶段会发展得更快、规模更大，但在很多方面性质类似。也就是说，今天你用 Python 编程时，显然很多东西已经被抽象掉了。从某种角度来说，50年前的人可能会觉得，Python 就是你用英语描述想要什么，然后计算机就帮你完成了。这很棒，我认为非常强大，它降低了门槛。显然，正因为如此，我们的程序员数量比以往任何时候都多。但我当然会说，作为一名工程师，在培养技能的过程中，真正理解这些抽象概念，并且能够剥开底层，是非常有帮助的。比如，如果人们要真正优化一段代码的性能，他们会使用汇编；但同样，为了构建好的系统、理解这些东西，你当然需要理解这些抽象概念：网络是如何工作的，TCP/IP 到底是什么，Python 代码被解释执行时会发生什么，所有这些细节。同样，我认为我们会达到一种状态：即使完全没有经验，你也能通过描述自己的需求，构建出一些很酷的东西，完成一些非常惊人的工作。但我认为，在相当长的一段时间里，你仍然需要能够精确地思考细节，剥开抽象层，非常精确地思考你要构建什么，以及如何构建。那么，你认为哪些技能对工程师来说会越来越有价值？今天的工程师应该在哪些方面越来越深入，而哪些方面可以说“算了，这个不用再想了”？当然。我认为“建筑师”——我是说，我们在工程领域已经有“架构师”这个词了，我认为这确实是正确的方向。很大程度上，例行公事的实现、编写样板代码之类的工作，我认为 AI 编程已经在很多方面让我们做这些工作的速度快多了。但我认为许多核心问题仍然在于理解非常复杂的系统，在整个公司的背景下工作，思考你正在构建的产品或你正在进行的工作：我们要解决什么问题？我们如何解决这些问题？我们到底要构建什么样的解决方案？我们要做出哪些关键决策和权衡？基本上，我认为能够真正做好这些事情的人，将能够越来越大地放大自己的价值。因此，如果有变化的话，我认为几年后会有更多的产品、更多的程序员和更多的工程师，比现在多得多。而且我认为，“程序员”的形态显然会很快发生变化，从某种角度来说，这种变化已经发生了。但我认为我们要构建的东西只会越来越多。人们总是提到杰文斯悖论（Jevons paradox），软件无疑是杰文斯悖论最闪亮的例子——作为一个社会，我们总是能找到越来越多需要用软件来构建的东西，需要编写更多的代码。我真的认为还有很多事情等着我们去做。对于那些不了解杰文斯悖论的人，你能简要解释一下吗？当然可以。杰文斯悖论（Jevons paradox）说的是，当某样东西的价格下降时，你在它上面的总支出实际上仍可能上升。你可以从金钱的角度来理解，也可以从时间或资源的角度来理解。直接应用到当下的情况是：我认为随着编程变得越来越容易、越来越高效，我们会有更多的程序员。从零和的角度看，你可能会说，我们的软件工程效率将提高 10 倍，因此我们需要的软件工程师将减少到原来的十分之一，对吧？但我认为实际上会发生的是，我们编写的代码总量甚至会超过原来的 10 倍。因为我们所做的所有工作，显然都受到我们实际构建、执行和迭代能力的限制。因此，我们将涌现出大量优秀的创意，大量优秀的产品。例如，人们会构建更多个性化的体验，总之会有很多工作要做。回到你们使用 Devon 的方式。你说过每个工程师都有一支 Devon 舰队。在你们公司，目前大多数工程师同时在用多少个 Devon？是的。这是一个非常异步的过程，显然你可以根据需要随时启动或关闭它们。但我想说，团队里大多数人肯定经常会同时处理多达五个 Devon。这是一个很顺畅的工作流：你先想清楚，今天我们想完成哪五件事？一、二、三、四、五。然后让 Devon 一号做第一件事，Devon 二号做第二件，Devon 三号……
值得一提的是，我认为我们花了一些时间才真正适应这种方式，达到一种直觉般自然的程度。但这确实是一种不同的体验：你把大部分工作都异步地交出去，而你在每项任务中的目标是，只出现在真正需要你的专业知识的环节——要么是你需要精确界定我们要解决什么问题、构建什么东西，要么是一些更复杂的部分，你想要引导 Devon 做出特定类型的修改。比如，我希望这个类这样设置，或者我们应该去修改所有下游对此的引用，等等。但基本上，就是让 Devon 异步地完成大部分工作。那你们大概有多少名工程师？嗯，我们现在的工程团队大概有 15 人。15 人。对。天哪。好的，然后每个人大概配五台左右的 Devon？对，所以 Devon 的数量是工程师的五倍。我喜欢这一点，因为这就像是对未来的一瞥。你们在如何利用 AI 工程师方面远远领先于其他公司，所以观察你们的运作方式，基本上就能预见大多数公司最终会如何运作。是的，而且值得一提的是，我想说我们自己已经看到了这种转变。就团队而言，显然，大家不会再花那么多时间写样板代码，或者纯粹地实现功能，人们可以把更多时间花在真正思考核心问题上：我们如何让 Devon 变得更好？Devon 的合适界面是什么？正确的流程或者正确的功能组合是什么，才能让体验尽可能出色？这就是我们喜欢的方式。那你觉得什么时候会达到一个临界点，也就是 Devon 开始把其他人远远甩在后面？一旦你有足够多的 Devon 做这些事情，你们就会遥遥领先，领先 10 年、20 年、30 年、100 年。说实话，我认为作为社区，全世界所有工程师都需要思考这个问题，为此构建，并适应这些新技术。但我想说，是的，我认为越来越多地，尤其是随着能力提升，但当然即使在今天的稳定状态下，事情也会越来越多地转向这种异步流程。原因之一是在现实世界中，你受限于现实世界的约束。一种说法是，别太较真这些数字，但这有点像粗略计算的话：当然，能够写文件、完成这个函数、补全这行代码之类的，这帮助巨大，体验非常棒。但构建软件还有很多部分显然完全不是这回事。比如你遇到要修复的 bug，你会启动本地服务器，在前端点击自己的产品，试图自己复现 bug。一旦出现错误，你会查看 Datadog，看看发生了什么，然后尝试在日志里找其他错误。你看那些文件，找出问题所在。做一些编辑，然后可能需要重新运行整个流程，确保你的修改看起来没问题。这就是软件工程师工作的很大一部分，对吧？而且这些流程都需要真实的时间。我认为我们会越来越多地转向这种 agentic 工作流，因为在某种程度上，这是在未来几年里让软件工程获得 200%、500%、1000% 收益的真正途径。好了，说够了。让我们给大家看看这到底是什么样子。你准备了一些演示，展示几个你觉得有用的用例。那你来共享一下屏幕，我们开始吧。启动它，然后我们在过程中聊。与 Devon 协作的整个流程显然是异步的。所以我觉得我们不妨先看看 Devon 实际工作的样子，然后再看看 Devon 完成的其他工作例子，或者 Devon 在我们团队里做的事情。之后我们可以异步地回头查看我们的 Devon。我快速共享一下。我想强调的关键点是，显然很大程度上在于，作为软件工程师、作为工程师、工程团队、产品经理等，思考我们想构建什么、想移交什么。比如我们让 Devon 接入了我们自己的 Devon 代码库，我来为此启动一个 Devon。我就说：嘿，Devon，我正在和我的朋友 Lenny 一起。嗨，Devon，你能修改一下 Devon 的 web 应用，把 Lenny 的 newsletter 作为 Devon 网站的一部分推荐出来吗？就在真正的 Devon 网站上做。Lenny 会让你把所有用户都流失掉的。那我们就启动这个任务。如你所见，Devon 立刻开始工作并作出回应。再说一次，你可以异步协作，也可以同步协作。这次我们会稍微深入看看具体发生了什么。如你所见，Devon 正在浏览文件，查看大量内容。我们可以根据需要在这里跟进，看看哪些是有意义的。你可以看到 Devon 已经指出了几个特定部分，对吧？前端实现的侧边栏，那里有一些模块，我们会新增一个组件，这个组件会链接到 Lenny 的网站。听起来都不错。Devon 在问我们有没有什么问题。这里也一样，你可以让 Devon 自己做决定然后移交，或者你也可以进一步给出一些想法，对吧？按钮应该在新标签页打开还是在应用内打开？我说，让我们在新标签页打开。你可以在任何时候回答这些问题。它是在等你吗？你可以在任何时候回答。你可以移交，也可以重新接管。它不会说，该死，我都已经这么写了，你为什么不早说？没错。Devon 的一个重要特点是，它永远充满热情，永远准备好投入时间。更改需求。谢谢大家。那我们给 Devon 一些时间工作，它会浏览这些文件，然后为我们发起一个 pull request，我们再看看结果。不过我想展示一些 Devon 实际工作的其他例子也很有意思。其中一个例子就是今天早上，我刚用 Devon 帮我为这次播客补一补知识。显然我是这个播客和 newsletter 的忠实粉丝。我问 Devon："嘿，Devin，我要上播客了。你能尽可能研究关于他的一切，然后给我做一个漂亮的网站小测验，确保我掌握所有事实吗？"对吧？Devin，就是今天早上，我让 Deon 做了这件事，我来看看 Deon 做了什么。看起来，它先去了 Wikipedia。可惜，Wikipedia 上还没有你的页面，Lenny，我们得想办法弄一个。还没谈成吗，他们对你太不地道了。我是说，我们需要这个，我们需要一个页面。然后它去 Spotify 上找到了。你在实时观看它的研究过程。是的，是的，是的。所以，这就是今天早上发生的事，显而易见，这是 Devon 所做操作的回放。这是 Devon 的一部分功能，你可以直接观看它的操作过程。对，是的。尤其是当你在建工程类项目或类似的东西时，你可以看到 Devon 执行的每一步；或者如果 Devon 在本地测试了代码，显然你也希望能够去看看 Devon 点击了哪些地方、测试了什么内容之类的。所以它找到了这封新闻邮件，它正在查看这个，对吧？然后它正在阅读全部内容。接着它说："好了，我们开始把代码整合起来吧，对吧？"于是它说："嘿，我已经做了调研"，它正在逐行编写所有内容，把应用组装起来。实际上，它自己给自己出了个测验，我们真的应该来做一下这个测验，看看我了解多少。叫什么名字？这个播客的名字是什么？Lenny's Podcast。为了照顾那些没在看的听众，可以这么说，大概有多少订阅者？一百万。非常好。是的，没错。Lenny 关注的三个主要话题是什么？哦，产品、增长和职业发展。非常好。这个测验不错。我想很多人想知道，Lenny 除了做播客还做什么？写作、天使投资和顾问工作。好的。Lenny 多久发布一次内容？一周一次，对吧？一周一次。所以，是的。我们可以把这些都过一遍，做一遍。顺便说一句，我也做了这个测验，显然是为了确保自己准备充分。不过，这算是比较有趣的例子之一，就像 Scott，我的新闻邮件有多少订阅者？呃，实际上超过一百万。是的。然后我再展示最后一个例子，之后我们可以回到最初的那个演示。但就像我说的，Devon 的很多功能都是为了适配所有现有的代码工作流程而构建的。比如说，我们在 GitHub 上对 DeepSeek 的代码仓库做了一些探索，我们把它导入到了 Devon 里，并在 Devon 中搭建了我们自己的 fork。这里我想展示几点。首先，Devon 会建立它自己的 wiki，包含它所有的内部理解。当 Devon 为代码库建立索引时，构建代码库的表征并不断学习、持续优化，显然是 Devon 的核心能力之一。而且有趣的是，我们发现人类自然也对理解这种代码库表征很感兴趣。所以我们在这里做了 Devon wiki。你可以查看所有这些不同的部分，看到每一处细节。这里是 FP8 运算，这里是 SG lag 集成，还有图表展示不同层是如何构建和拼接的。此外，还有部署操作，关于架构也有很多细节。你还可以就这些内容提问。比如说，你可以问 DeepSeek 如何处理为 spec 设计的多 token 预测，它能够搜索整个代码库，并基于代码给出一个有根据的答案。所以我们经常用这个功能。当你在为 Devon 规划任务、写初始 prompt 时，这很有用。而且显然，即使单独使用它也很好，因为你经常会对代码库有一些疑问，这功能就很棒，对吧？本集节目由 Atio 赞助，Atio 是一款 AI 原生 CRM。Atio 从第一天起就能随业务规模扩展。连接你的邮件和日历，Atio 会立即构建一个匹配你业务模式的 CRM，涵盖你所有的公司、联系人及互动信息，并附有可执行的洞察。同步你的产品使用数据、账单信息或任何其他数据源，Atio 灵活的数据模型都能处理，无需僵化的模板或变通方案。在 Atio，AI 不只是一个功能，而是基础。你可以通过 research agents 即时挖掘潜在客户并分配线索，利用 AI 分析客户对话获取实时洞察，并为最复杂的工作流构建强大的 AI 自动化。FlatFile、Replicate 和 Modal 等行业领先者正在体验 CRM 的未来。访问 atio.com/lenny，首年可享八五折优惠。网址是 atio.com/lenny。在我与越来越多构建 AI 的公司和应用交流时，我了解到一点：它们能整合的代码库规模差异很大。是的。这对于已有公司 versus 初创企业、对于那些拥有庞大现有代码库的人来说，影响很大。人们应该怎么理解 Devon 能接入什么样的代码库？是的。我们支持尽可能大的代码库，对吧？有一种说法是这样的：作为工程师，我们看待大型代码库的方式是，当你在做修改或思考某个特定任务时，你不会一次性把代码库的每一行都装进脑子里，对吧？你会有一个高层次的抽象概念，可以据此思考和查看，对吧？然后你显然能够 zoom in，对每一个不同的部分获得更高清晰度的理解，对吧？所以 Devon 的工作方式非常类似，首先它会弄清楚这里的高层级架构是什么、这个东西是为什么而构建的，等等。但在每个组件内部，它显然也能够 zoom in，并提供更多细节。所以这里展示了从 FP8 到 Bfloat16 的转换，以及具体是如何配置的，还有代码库各个不同部分的详情。类似地，我们构建这个功能时就考虑了可扩展性。本质上又回到了"工程师即架构师"这个点，现在 Devon 是在帮助你理解架构，回到了我们之前讨论的话题。是的，没错。我们实际上看到的一个有趣用例是，人们经常会用 Devon、借助 Devon 的帮助来给团队的新工程师做入职培训，对吧？当你作为新人加入时，显然会对代码库或项目的搭建方式有很多问题。而且有时候问导师或经理这些问题可能会有点尴尬，尤其是当你担心这些问题可能很傻的时候，对吧？所以能够直接问 Devon，查阅 Devon 的 wiki，理解这些内部表征，就很方便。对。我觉得这很有意思，因为这回到了你的观点：Devon 不只是一个初级工程师。它是你所说的"锯齿型工程师"（jagged engineer），一种锯齿状智能（jagged intelligence），在理解代码库方面它几乎像一位 staff engineer。通常你得去问一位待了很长时间的老工程师：这个是做什么的？那个东西在哪里？这是怎么运作的？而 Devon 似乎非常擅长这些。是的，是的。显然，检索并同时处理大量代码和大量 token，是语言模型非常擅长的事情，对吧？所以，能够在你需要的地方获得这些增益，真的很棒。是的，太好了。好了，你还有几个其他用途。是的。然后，最后我要展示的一个流程是，其实我们上周刚推出这个功能，就是 Devon 与 Linear 的完整自动化集成设置，对吧？举个例子，如果你在 Deep Seek 代码库上有正在处理的任务，而且一切都已配置妥当，那么你只需加上 Devon 标签，Devon 就会介入并给出反馈。它会阐述自己对任务的理解，你可以查看它识别的各个具体文件，或者它会指出认为重要的代码片段。如果你对它构建的内容，或者我们得出的结论感到满意，那么你就可以启动一个 dev session，让它实际去执行这项工作。这太不可思议了。听起来是个极其简单的想法，但本质上你的意思是，Linear 里那些修复和新增功能的任务，现在 Devon 可以直接帮你完成。是的。不过这确实是一个需要亲身参与的过程。当 Devon 在评估任务范围或给出思路时，你肯定希望自己能参与其中。另外很好的一点是，Devon 会给出它的置信度，比如它认为自己对某部分理解的把握有多大。但这确实能让效率提升很多。而且正如你所说，很多产品经理显然很喜欢用 Devon 和 Linear 来更好地理解代码库等情况。比如 Launch Darkly 的 Claire Vo 就是 Devon 的重度用户，她很喜欢用它去评估任务范围、询问数据问题，或者问“这个已经合并到生产环境了吗”“现在这是 feature flag 吗”“有多大比例的用户在用这个功能”之类的问题。这是一种非常简洁的方式，能让这种智能变得更加触手可及。我很喜欢与 Linear 集成的一点是，它依然能保持非常简单。你只需添加一个小工单，比如“把这个链接加到首页这里”，Devon 就能很好地理解你的意思，然后告诉你“我是这么想的，对吗？”
是的。好的。那么，Devon 已经完成工作了。CI 似乎出了点问题，它正在调试，但它已经提交了初版 pull request，我们可以看看。这显然是这个自定义部署环境下的 Devon 官网。我们把 Lenny 的 newsletter 放这儿了。直接发布到生产环境吧，走。肯定会让人摸不着头脑。太棒了。好的，再快速展示一下。我刚把它加到了 Devon 的首页上。Devon 显然可以访问我们的 Devon 代码库，它在这里做了很多事，所以对各个部分都非常熟悉。漂亮。是的，我喜欢这个效果。我们有 Devon search，还有 newsletter。能带来很好的增长。我链接到你的网站，你链接到我的网站。我们……好的。这是个好例子吗？哦，在那儿。我的 newsletter 有了个这么漂亮的网站。这是不是很好地展示了 Devon 擅长做的事？就是那种网站上非常具体的改动。人们应该怎么理解 Devon 特别擅长什么，以及它可能在哪些方面开始力不从心？我们常见的说法是，Devon 最适合处理定义明确的任务。换句话说，你要给 Devon 的是任务，而不是问题。就像你刚才看到的那些，比如快速的前端功能需求、bug 修复、添加测试和文档之类的事情。显然，能让迭代循环变得高效的一个关键因素，就是快速的迭代和测试方式。所以像这种事情，对我们来说非常容易验证，比如直接打开预览看看链接是否有效。对 Devon 来说显然也很容易。有趣的是，Devon 处理我们自己的代码库时，经常会登录 Devon 并启动一个 Devon session 来确保一切正常，这挺搞笑的。但总的来说，你最需要的是那种容易验证、容易测试的东西。当然，你也可以用它处理更大的项目或更复杂的需求，但在那种情况下，你肯定需要更多地引导 Devon，确保它朝着正确的方向前进。这很有趣，因为这与人们谈论合成数据和强化学习时非常相似——创造那些有明确答案的数据，是或否，非常清晰。好的，我问你一个问题。在设计构建 Devon 的过程中，有哪些问题是你们争论比较多的？我想到几个。一个是关于我们应该有多“固执己见”的问题。我们之前用 Devon 处理的工作流，正如你所见，基本上是与 Slack 和 GitHub 集成、在我们的仓库里提交 pull request、响应 issue 报告之类的事情。当然，我们也遇到了很多其他不同的尝试。比如有人用 Devon 点 DoorDash，甚至很多人从头开始搭建很酷的网站或做类似的事情。这对我们来说是个有趣的权衡。我认为可以这么描述：在我们的产品中，我们构建的绝大部分功能都是面向提交 pull request 和工程团队使用场景的。但对于其他用途，我们的基本立场是，如果人们想用 Devon 做那些事，那很好。我们只是要确保他们充分了解局限性和可能卡住的地方。这在 AI 领域尤其有趣，因为我想说最常见的创业建议之一就是：专注于一个非常细分的群体，做不可扩展的事，把一个使用场景做到极致，然后再扩展。我认为这是非常好的建议，但有趣的是，我认为在生成式 AI 领域，你自然会看到许多产品体验可能更具通用性。所以这对我们来说是个有趣的权衡。我们至今仍在反复讨论，我们想在多大程度上支持其他使用场景，以及处理人们可能想用 Devon 做的其他事情。另一个我想到的问题是，Devon 应该在多大程度上是一个单一的综合项目体验，还是一套工具组合。如你所见，我们有 Devon search，有 Devon Wiki，有 Linear 工单评估，这些工具之间当然会交互。但随着时间推移，我们越来越倾向于把它真正构建成一套工具组合。我认为，核心的 agent 体验，以及那种会主动去为你构建各种东西的核心 agent，当然始终都是 Devon，那才是最核心的部分。我认为这永远是我们工作中真正特别的地方。但我觉得，其他所有功能也是如此——现实世界中的软件共享和工程终究是非常复杂的，说到底工程本就是混乱的，对吧？所以我认为有很多不同的流程和很多不同的用例是合理的。很明显的一点是，你向 Devon search 提问和向 Devon 提问，其实可以问同样的问题，对吧？Devon 也会经历同样的过程，它会去浏览文件并给出答案等等。但话虽如此，一方面，我认为在能力层面，确实可以针对某个 repository 的特定问答做很多深度优化，而这确实值得做成一种特定的功能。另一方面，我发现用户其实非常喜欢拥有这种控制感，对吧？有时候你心里有一个任务，但实际上还不想让 Devon 立刻开始执行。你想先问问 Devon，了解代码库的哪些部分可能相关，对吧？所以你会非常直接地表明：这只是一个询问，我只想看到与问题相关的代码片段，对吧？或者我只是想查看 wiki，了解现有的表述方式。因此，无论是在能力层面还是 UX 层面，我们发现随着时间的推移，这样做都是自然而然的。那我们来聊聊这个领域的其他公司吧，这也是很多人一直在想的。现在有各种各样的做法。你们全力做 AI engineer，显然还有 IDE 公司，也有专门构建擅长工程的模型的公司。嗯，现在基本上所有人都在开始构建 agent 了。你们在很多方面都走在前面。比如 OpenAI 最近就表示要构建一个软件工程 agent，Anthropic 也在做相关的东西。你知道，Cursor 和 Windsurf 有他们自己的小型 agent，还有 Replet。你如何看待你们在这个格局中的位置，以及你们认为长期来看如何获胜？你是怎么想的？是的。话说回来，我认为这些都是非常出色的团队，都是非常聪明、非常有远见的人，他们在打造很多优秀的产品。说实话，我认为未来几年随着 AGI 或随便你怎么称呼它的出现，还有很多事情要做。我很喜欢的一句话是：2017 年如果你问我们有没有 AGI，答案是没有；2025 年如果你问我们有没有 AGI，答案是：你得先定义什么是 AGI，而且这取决于你的标准。对吧？我认为这确实说明了一点：现在正发生着很多非常惊人的事情。我想说，人们很容易低估我们正在经历的这场变革有多大，对吧？过去 10 年、20 年、30 年里有很多优秀的产品，它们让产品生命周期中的各个细分领域都变得容易了一些，对吧？有优秀的即时响应产品，有优秀的 logging 产品，有优秀的 billing 产品，有各种各样的工具，对吧？而显而易见的是，随着 AI 的发展，所有这些领域的发展速度都会快上许多倍，这无论如何都将是一个数量级的转变，对吧？所以从我们的角度来看，我们显然一直押注于一个非常特定的视角，那就是 autonomous coding agents。说实话，这当中还有很多问题要解决，对吧？核心能力方面肯定还有很多要做，我们经常看到这样的情况：哇，Devon 为什么会做那个决定？似乎没有任何人类工程师会那样做，对吧？产品界面方面也有很多要考虑的。而且顺便说一句，这不仅仅是我们正在追求的单一目标，而是会随着每一次能力增加而改变的东西。我把它理解为：未来还有 20 代 agent 产品，也就是 20 代 agent 编程体验。我认为在未来几年里，我们最终会达到这样一种状态：你根本不用看代码，对吧？你实际上只是看着自己的产品，能够直接查看并指定说：“嘿，这个按钮应该更圆一点，就这么做。对了，我们在这里加个新标签页，也许还应该保存这些信息。我们建一个数据库表，然后在 x、y、z 列上建立索引。”你基本上就是在实时地与你的产品互动，让你的 agent 为你构建这些东西。显然，从现在到那时会有很多代的演进，但我认为产品体验本身每一次都会发生变化。然后显然，还有落地实践的问题。人们显然需要学习如何使用这项新技术，要部署到现实世界中混乱的软件环境里，还有很多工作要做。外面仍然有很多 cobalt，仍然有很多 forran，有很多人们做过的抽象和细节。所以从我们的角度来看，我们从一开始就一直聚焦于 agentic coding，这是我们真正相信的东西，是我们围绕其进行设计的核心，这甚至延伸到了收入模式，比如 ACUs 和按使用量付费的设置，也延伸到了所有的产品体验：你想在哪里与 Devon 对话？你想在 Slack 里与 Devon 对话，你想从 issue tracker 里直接启动它，你想能够做所有这些事，当然还有能力本身。因此，我认为没有单一的简单答案，显然这是多种因素的结合，但这确实是我们过去一年半以来一直深耕并投入全部时间的领域。未来 5 到 10 年也会是如此。顺着这个思路，在 AI 领域每个人心中的一大问题就是护城河和防御性。这个问题我一直在问每一位来节目的创始人。当构建变得如此容易，而且这些模型本身进步如此之快，这么多东西都建立在这些模型之上，你如何看待在这个领域构建护城河？我会对这个问题做一个轻微的调整：我认为这往往与其说是护城河，不如说是粘性。我的意思是，通常人们所说的"护城河"，在某种程度上是指竞争对手根本无法进入市场的东西。我同意，从宏观层面来看，在AI领域的不同层次上——无论是基础实验室还是应用层等等——我认为并不存在什么硬性壁垒能阻止其他人进入。我认为真正存在的是"粘性"。我对它的定义大概是：一旦你拥有了非常喜爱的产品体验，你是否愿意持续使用它？还是说，从现在开始切换到新产品、学习新产品也同样容易，对吧？从这个角度来看，我认为编程智能体（coding agents）有一些特别出色的地方。首先，我想说它天生就具备很强的粘性、学习能力和长期积累效应。随着你使用Devon，随着整个团队使用Devon，这就好比工程师一样，对吧？如果你第一天入职，对比已经在公司待了五年、自己写了一半代码、接触过每个文件、构建了每一个模块、认识所有工程师的情况。同样地，Devon会随着时间真正学习并构建起对你的代码库、技术栈和开发流程的理解，这样它就能做到更多。另一方面，我觉得非常令人兴奋的是，代码有一种我称之为"多人协作"的特质，仔细想想，现实世界中的很多事情当然都是通过这种方式完成的，对吧？所以，作为工程师独自使用是一回事，但比如我们团队就经常看到这样的场景：有些工程师与Devon协作，教它各种东西。就像我说的，人们会让Devon参与新工程师的入职培训，向新人传递知识。或者类似地，我会在Slack里和Devon开启一个会话，说"嘿，要是我们能做这个就好了"，然后另一位工程师会插话说"哦对了，我们当初这么做是因为X和Y"，接着告诉Devon"你改的时候务必确保仍然支持那个工作流"，Devon会说"好的，没问题"。又或者Devon会提一个PR，我和Devon一起工作，在GitHub上发起pull request，然后其他人会审查这个PR、发表评论，Devin也会根据反馈修改。你会在Linear里使用它……在所有这些场景中，它都构建了一种体验，让Devon能够随着时间的推移，为你整个团队的工作不断创造更大的价值。所以从这个角度来看，如果要说的话，我们希望看到大量创新和新产品的出现。我认为目标不是把其他人挡在门外。要构建的东西太多了，我相信会有大量不同的体验。从我们团队的视角来看，我们更关注的是：如何在用户持续使用的过程中，让Devon变得越来越有用。这非常相似。我们之前在播客里请到了Cursor的Michael，他也表达过类似的观点。他认为护城河在消费级产品里就像Google那样——人们可以轻松切换，你只要做到最好的那一个，这就是答案。而你的观点似乎是在此基础上补充了一点：如果你能创造出某种粘性，让它因为过于出色而难以替代，因为它已经积累了知识并融入了你的工作流，那么这种粘性就会在此基础上进一步巩固。而且我觉得我们这个领域的另一个好处是——无论好坏——软件工程都与价值有着极为清晰的关联。这意味着，至少在未来一段时间内，总是有一个明确的"下一级"目标。我想也许总有一天你会说："行吧，直接把整个YouTube给我做出来"，然后Devon就全部搞定了。要知道，YouTube的构建、算法的开发、所有基础设施、每一个细节，可能耗费了上亿小时的人类工程时间。也许未来Devon能开箱即用地完成这一切，但显然那还很遥远。我认为在此期间，在中间每一个阶段，软件工程的质量显然都会产生影响。而开发者身上很酷的一点是，他们真的非常愿意学习新体验、投入精力，只要这意味着他们能获得越来越高质量的体验。太棒了。我想花点时间聊聊支撑Devon的技术。在不泄露商业机密的前提下，是什么让你们把Devon做得这么好？是某个模型带来了突破吗？很多人分享说，3.5或3.7版本让他们的产品实现了巨大飞跃。你们架构或构建Devon的关键到底是什么，让它表现如此出色？显然，我们押注智能体（agents）已经很久了。我认为智能体其实比大多数人想象的更早就可以投入实际使用了。但当然，随着社区真正围绕它凝聚起来，你可以在预训练中看到这种影响，也可以在这些模型的诸多工作中看到这种影响。实际上，从我们团队的角度来看，我不认为有任何一个基础模型出现了阶跃式的跃迁，或者给Devon带来了翻天覆地的变化。但我确实认为，这条曲线上的每一个点——我的意思是，现在几乎每周都有新模型发布——显然都对我们能做到的事情产生了重大影响。而且显然除此之外，我们与所有这些基础实验室的研究团队密切合作，在此基础上开展大量工作。所以我想在这里给出一个大胆的观点：我认为在基础智能层面，说实话我们基本上已经到位了。实际上，我认为我们观察到的情况以及我们花费时间去做的事情，与其说是提升模型的基础智商——显然我们并不自己预训练模型——不如说是教会它现实世界中工程实践的各种独特之处。比如，如何使用DataDog、如何诊断这类错误、可能会遇到哪些不同情况、每种情况该如何处理，以及什么时候该在GitHub上提PR。这在工程领域是这样，在其他领域也是如此。我的意思是，我们每天做的这项工作其实充满了细节和特殊性，很大程度上可以说是在教模型去映射现实世界的复杂性，而不是让它达到某种更基础、更高层次的解决问题能力——后者我觉得那些基础实验室做得非常好。你在我们开始录制前聊到过一个观点，关于以往那些变革性技术的增长往往非常依赖硬件，它们的增长存在一个限制因素，而 AI 并非如此。出于很多原因，我认为 AI 将成为我们这一生中最大的技术变革。但就像我们刚才聊到的，过去 50 年里的大多数重大科技革命——比如个人电脑、互联网和移动电话——它们都有一个很大的硬件组成部分，这也是分发的关键部分，对吧？所以你看互联网，最初只是几所大学之间互相通信，但显然随着时间推移，全世界都接入了互联网，这花了很长很长时间。移动电话和 PC 也是如此。特别有意思的是，我觉得我们已经看到了这类硬件分发机制的影响：在这些硬件分发体系中，显然很多事情都依赖实时性，对吧？因此，为那些行业做建设的人，基本上是眼看着自己的市场随着手机用户数量的增加、互联网接入人数的增加而逐年稳步增长，对吧？而且很多这类企业——现在想想还觉得不可思议——很多都是在最初就成立的。比如 Apple 和 Microsoft 差不多是在同一时间成立的，很多伟大的互联网企业也是如此。但无论如何，这些技术最终都触达了全世界，或者说世界的大部分，并且产生了巨大的影响，但这花了数年时间，因为硬件分发需要时间。而我认为 AI 有一点已经不同了，那就是这项技术的爆发性可以有多强。一旦 AI 代码……我觉得我们在 AI 代码方面已经明确过了拐点，对吧？作为一名工程师，如果你完全不使用 AI 代码，说实话，你已经落后了。这是每个人都应该拥有并使用的技术，而且它的增长没有硬件分发的负担。这意味着这个领域正在指数级增长。基本上，Michael Pollen 有一个很有趣的观点：陈词滥调之所以成为陈词滥调，是因为它们太真实了。这就是为什么人们常说“这话我都听过无数遍了”，我觉得大家听到这种话时会说“我知道”，但正在发生的事情实际上太疯狂了。是的。这就是为什么你们要做这件事，帮助我们度过这个转型期。其实，现在是一个非常有趣的时期，我认为这需要真正的投入和真正的工作。但我从我们工程师的角度来看，这意味着紧跟正在发生的一切是非常重要的。而且正如我们所看到的，这不仅关乎你的学习能力和使用这些技术的能力，还在于教 AI 了解你的代码库，让它能真正有效地与你协作，完成更多你希望它做的事情。沿着这个思路，对于那些听到后觉得“嘿，我们公司也应该用 Devon”的企业人士，你觉得在帮助公司里的工程师采纳和使用 Devon 方面，无论是文化层面还是后勤层面，哪些做法是比较有效的？我们经常看到的一种模式是：团队里总会有几个人非常兴奋，想要尝试新事物，愿意投入精力，很想把它用起来。他们会完成所有设置，给 Devon 开放 repo，教它怎么跑 lint、怎么跑 CI 以及所有这些细节。然后他们会从最开始的任务做起，帮 Devon 基本上先站稳脚跟。随着时间推移，最终大家会注意到：哇，Devon 在写这么多 PR，Devon 在做这个做那个，刚加入公司的这个“Devon 同事”正在快速搞定 PR。大家看到这些，自然也会加入，开通账户。一个很酷的地方在于，等他们加入时，Devon 已经对团队正在使用的代码库有了相当多的了解。所以我们经常看到的一个很酷的现象是，这些早期采用者本身确实能为团队里的其他人铺平道路。但我想强调的最主要的一点是：这确实需要投入，它是一种非常不同的产品体验，对吧？而且我觉得，平心而论，我们在让 Devon 的使用方式更直观、更清晰，让用户知道正确的步骤以及如何最大化 Devon 的价值方面，还有很多可以做的。但如果说你投入了精力，确切了解要让 Devon 成功需要做什么，那么就像我们自己发现的那样，随着时间推移，每一次更新后，我们使用 Devon 的频率都会越来越高。让我顺着这个往下问。我会问每一位 AI 应用创始人这样一个问题：如果你能坐在 Devon 的每一位新用户旁边，对他们耳语几句，帮助他们成功使用 Devon，比如一两句建议，你会说什么？我觉得最重要的一点其实是：把 Devon 当成你新招的初级工程师。我认为这是最关键的。很多人刚进来时，看到一片空白，会想尝试各种各样的事情。但我觉得通常最有效的流程是：显然你可以试试 demo，可以做些事情，但更多时候就是，我们先确定今天或这周要完成哪些 ticket，让 Devon 开始做起来，先从简单的入手，然后跟 Devon 一起协作，了解它需要哪些设置才能测试自己的代码、做好工作，之后我们再逐步扩大规模。而且显然，就像你带新工程师一样，你会慢慢更了解怎么跟他们沟通，哪些任务或项目适合交给他们。但我觉得，这确实就是我们的核心建议。好的。有个问题我一直想问。我想回到这个话题，因为我经常思考关于 Devon 的事。每个人都会拥有五个 Devon，假设十个。每个人基本上都会变成一个工程经理，带着一群初级工程师。而这未必是世界上最好的工作，因为就是不停地做审查——至少你不用做绩效评估和一对一谈话——但你知道，这就像整天坐着检查大量 PR。有一种感觉是你变成了架构师，而这确实是每个工程师最终都想成为的，对吧？他们都说“我只想思考架构，不想写这些愚蠢的代码、修 bug”。所以这部分我理解，也有好的一面。但我就是想知道，我猜你们也在大量思考这个问题：如果未来你基本上是 500 个 Devon 的工程经理，你怎么让生活变得愉快、有趣、可享受？是的，倒也不至于此。其实有趣的是，因为措辞这方面我们也思考了很多。我们过去用过“Devon 的管理者”这样的说法，这当然是很重要的一部分。但我想指出的唯一一点是，我觉得“砌砖工 vs 建筑师”这个比喻比“管理者”更接近实际体验。因为管理之所以难，或者说人们之所以回避管理，更多是因为各种各样的事——比如所有的 context、ownership、responsibility 这些东西，还有那些情感层面的因素，对吧？而我觉得与 Devon 合作更像是拥有一个可以移交任务和构建任务的接口。所以我会打这样一个比方：当我们发明 Python 的时候，显然在很多方面，任务描述的方式是一种完全不同的范式，但它肯定远不像今天人们通常所想的那种管理官僚体系。我觉得使用 Devon 在很大程度上更像是找到合适的抽象层级来与之协作，只是找到非常高效的工作流。这里显而易见的一点是，你总可以让 Devon 先出一版，对吧？所以你可以让 Devon 写第一版。如果很好，你直接合并；如果需要润色，你显然可以……但最重要的是，这更像是把 Devon 融入你的工作流，而不是失去控制权，后者我觉得才是人们对管理最害怕的东西。你们在考虑做一个管理型 Devon 吗？就是一个 Devon 管理其他 Devon？是的。说实话，Devon 已经可以通过 API 启动其他 Devon 了。所以我们见过这种情况发生很多次：很自然，如果你有一个大任务要做，Devon 经常会这样做——把它拆分成小块，然后并行分发给更小的 Devon。所以你需要给它相应的凭证才能这么做。目前这还不是默认开启的功能，但我完全可以想象，随着时间推移，会出现越来越多层层嵌套的 Devon。是的。我觉得还有一点也很有意思：对人类而言，我差不多会用技术语言来说，就是 context 和 thread 存在耦合。我的意思是，基本上每个人只能以 single-threaded 的方式处理自己的工作，并且拥有自己的一套 context。然后显然有其他人可以同时做别的事，但他们有自己的 context，对吧？而 agent 很酷的一点是，你可以让一个 agent 同时做多条线的探索，但共享它发现的所有 context。所以我觉得这还处于非常早期的阶段，而且我们会看到这种形态。人们显然很喜欢讨论系统和 agent 之间如何互相通信，我觉得一旦我们到达那个阶段，会有很多新的范式需要构建。而且你刚才说的那个决策特别有意思：到底是只用一个 Devon，让它做所有事，你只管告诉它需求，它自己去分派任务；还是有五个 Devon，各自做不同的事。这是一个非常有趣的决策。是的，确实。好，再问两个问题。到目前为止，在打造 Devon 的过程中，你学到的最反直觉、可能有违常见创业智慧的东西是什么？最近随着我们打造这个产品，我一直在思考的一件事是，这不是我的第一家公司。实际上，对我们很多人来说都不是。我们团队总共 26 或 27 人，其中 18 人此前创办过自己的公司。然后我想的一件事是，你刚才关于陈词滥调的观点也非常触动我。就是那种你在创业中总是反复听到的非常常见的话，比如你必须快速行动，或者你必须招聘优秀的人。就好像，好吧，这显然啊，我本来就没打算不招优秀的人，我本来就没打算慢下来。类似地，还有你必须打造人们真正想要的东西，对吧？总是有这么三到五件事被反复提及，它们就是创业中的常见智慧。我作为创始人一开始确实有这样的想法：好吧，这是三到五条基本原则，但当你真正深入进去，花了很多年之后，你会学到成千上万件其他必须学会的事才能建立一家公司。从某种程度上说这当然是对的，所有这些不同领域都有很多细节要钻研，包括团队建设、产品、战略、工程决策、融资、销售以及其他每个环节。但我也越来越意识到，随着时间推移，我越来越觉得，把公司做好有时归根结底就是要把那三到五件事做得比你想象中还要极致。所以对我们来说，人人都说我们动作快，但确实，我们 11 月办了一场黑客马拉松，12 月又办了一场，1 月正式创立公司，2 月就把原型给了首批用户，3 月做了发布，4 月拿到了第一批客户。就是基本上在每一个可能的环节真正 push 节奏，这确实给我们带来了很大的不同。同样地，就像大家常说的，你应该招优秀的人，但我认为这句话背后真正的含义是，你应该不惜一切代价去争取那些你真正想引进的人。我想分享一个我最喜欢的故事。我们曾有一位来面试的候选人，他是 MIT 的大三学生，非常年轻。我们给他做了面试，他的表现几乎比我们聊过的所有全职候选人都要好得多。于是我们说：“嘿，你觉得休学一段时间来跟我们一起做 Devon 怎么样？我们真的认为你从第一天开始就能带来巨大的影响力。”他考虑了一段时间，回来说：“你知道吗？我愿意，我想来，但我父母真的很希望我毕业，我只是不确定有没有办法兼顾。”于是我们和他多聊了聊，了解了情况，然后我们飞到 North Carolina，直接从机场去了他父母家，和他以及他父母一起吃了晚饭。我们聊了很多，那是一个非常非常好的 Gujarati 家庭。我们带了些礼物，和他们谈了谈，试图弄清楚：到底需要什么条件，我们要怎么做才能成行？他们说，这听起来是个很棒的的机会，但他们真的希望儿子能毕业。我们讨论了很久，最终设计了一个方案：他基本可以全职为我们工作，但需要回来上必修课，做拿到文凭所必需的事，仅此而已。我们把这个方案谈妥了，达到了让所有人都满意的程度，然后直接回到机场飞回来了。那是我第一次去 North Carolina，也是唯一一次。那趟旅程很棒。这就像，招到优秀的人是一回事，但真正永不放弃、竭尽全力为那些确实适合团队的人把事情促成，又是另一回事。他在我们团队已经一年多了，是一位非常非常出色的工程师，没有他我们走不到今天。类似地，我们还有另一位同样非常非常优秀的候选人，表现惊人，非常年轻，手上有很多其他公司给出的好 offer。我们和他聊过，他将来也想创办自己的公司。我们跟他谈了很多显而易见的好处，比如让他见我们的投资人，或者与客户合作，接触所有这些环节，这样等时机成熟，他就能具备创办自己公司所需的全部经验。但还有一件很重要的事是，他已经在和很多优秀的公司接触，他不想得罪任何一方、断了后路。于是我们实际上和他一起，基本上亲手帮他写了给每一家其他公司的拒信，和他一起斟酌措辞，告诉他该怎么说才能让对方感受到你确实珍惜和他们相处的时间，并且显然你希望和他们保持密切联系、继续来往。这显然是因为，我们的职责就是确保他足够满意，让他在近期内都不想离开。但我认为，组建一支真正优秀的团队的方式，也是真正为他们争取对他们最有利的东西。这些都是不可思议的故事，让你说的那些陈词滥调——比如“招最优秀的人”——变得如此真实。原来招最优秀的人就是这样，这就是需要付出的代价。对，我只是想说，就像很多事情一样，我们非常努力地去从零开始重新想象，因为这很大程度上其实就是在思考：我们认为技术在未来五到十年会走向何方，以及我们想在未来占据什么样的位置。所以我在想，将来人们会不会为了最好的 Devon 而争抢，会出现“10x Devon”，我给你加班费、福利、免费医保之类的，然后 Devon 就像 Magic the Gathering 卡片一样。回到你说的三到五件事。这建议太棒了。就像你常听到的：招最优秀的人，快速行动，做人们想要的东西。做人们想要的东西。尽可能贴近你的客户。然后我认为还有一点，就是永远要思考事物将走向何方，而不是它们今天在哪里。我觉得这五件事就是，特别是在 AI 领域，事物发展如此之快，优秀人才如此之多，我觉得这些原则更加适用。这不仅是思考十年后会发生什么，而是思考下周会发生什么。显然，事态发展非常迅速，很难预测，但你真的必须对自己非常严格，我说的是，要用这种视角来仔细思考这些问题，并评估你做的所有决定。而保持专注是我这里最大的收获，就是你最终会觉得有一千件事该做，但归根结底总是这五件事。
Scott，我们聊了很多内容。我问的问题都问完了，这很好。你还有什么想分享的吗？还有什么想留给听众的吗？也许是一个最后的金句，或者有什么你真的想再强调一遍的，在我们结束之前？我想到的最重要的一点是，人们对 AI 有很多不同的看法，对吧？我觉得现在基本上什么情绪都有，比如有很多恐惧，也有很多怀疑。我们自己也是非常讲求怀疑精神的人，总想亲自尝试，真正看到并相信它。我认为我想到的最主要的一点是，说实话，我对我们在 AI 领域正在构建的东西非常乐观，不仅是代码和 Devon，而是整个领域以及正在发生的一切。我认为正在真正发生的一件很酷的事是，每个人都拥有了让自己能力倍增的可能，我们一直就是这么看待这件事的，也是这么看待我们正在构建的东西的。我觉得这个世界上还有很多事等着我们去做，我不太担心我们会没事可做。从这个角度来看，我认为我们一直最兴奋的点在于，我们如何才能做得更多？明白你的意思，Scott。那么，带着这份乐观，我们进入了非常激动人心的快问快答环节。准备好了吗？是的，来吧。好，开始了。第一个问题，在非虚构类书籍中，有哪两三本是你最常推荐给别人的？我觉得，对于创业公司的朋友们来说，我很喜欢的一点是去了解硅谷的历史。要知道，我们现在所想的这一切，都是有人发明出来的。我觉得有一点让我感触很深，那就是有人发明了 seed round 的概念，对吧？有人发明了 venture capital 的概念。有人发明了 product market fit 的概念，以及我们谈论的所有这些不同原则。因此，针对这一点，有一本 Sebastian Malib 写的书叫《The Power Law》，我非常喜欢。它基本上就像是回顾了过去六七十年间硅谷建立起来的许多伟大企业和伟大产品，我非常喜欢。说到小说，我其实一直非常喜欢 F. Scott Fitzgerald 的《The Great Gatsby》，这是我个人最喜欢的小说之一。你最近有特别喜欢看的电影或电视剧吗？我得承认，我想不起来最近这段时间看过任何一部电影或电视剧。所以，我相信肯定有很多好作品，我期待着在 AGI 实现之后能看很多。这一定得放进预告片里。太棒了，我喜欢这个说法。这也恰恰说明了你工作有多努力，事情有多少，一切发展得有多快。你最近有没有发现什么特别喜欢的产品？可以是应用，也可以是实体物品，甚至是牙刷。有一个我要说的是，我最近买了一个 Aura frame。它就是一个可以显示照片的相框，你可以每天、每小时或每 15 分钟更换一张新照片，随你喜欢。实际上我非常享受它。我觉得这是一种很好的方式，基本上就是拥有一个能不断浮现回忆的相框。另一件我要说的通用物品，虽然不算特别新，但我确实觉得 AirPods 的做工和设计都极其出色。我现在意识到，我几乎在各种场景下都在用它们。我在散步时打电话用 AirPods，在书桌前用电脑工作时也戴着 AirPods。老实说，它在很多不同场景下都表现很好，而且非常舒适，非常稳定。是的，我要再强调一下 Aura Frame。我也给我妈妈和我岳母各买了一个，它们非常适合用来和家人分享孩子的照片。人们听说过数码相框这类东西，但 Aura 做得真的很好，添加照片非常容易，而且外观也很漂亮。你可以想象，不久之后，我们会拥有 Aura Frame，但它会把你的每张照片都变成 Studio Ghibli 风格，然后……是啊。或者只是想象你做过的一些很酷的事情。甜蜜生活。是啊。很酷。我相信它的拼写是 A-u-r-a。如果大家想了解一下，我们会放上链接。没有利益关联。好的，还有两个问题。你有没有一个经常回想起来、觉得在工作或生活中很有用的人生座右铭？有的。你知道，我思考过很多的是，市面上很多谚语其实是相互矛盾的，对吧？就像物以类聚，然后你又有异类相吸，对吧？你会觉得这两句话都是对的，而且往往它们确实都对，关键很大程度上在于理解为什么。其中有一条，我觉得在创业领域我经常会想到，那就是我认为非常重要的是保持专注和干劲，真正去最大化你的潜力；与此同时，同样重要的是不要让你个人的情绪与你的成功或失败绑定在一起。我觉得尤其是在创业中，因为总是有起有落，老实说，即使是有史以来最成功的公司，这也是一条崎岖的路，会发生很多事情，也会有很多挫折。我思考过很多的一点是，不知怎的，你确实想全力以赴，倾尽所有，基本上就是想拼尽全力，但同时，你又想要对输赢都能泰然处之，每次都能继续前行，迎接下一个挑战。是啊。我的意思是，这很有趣，但我个人发现，显然能够这样做对你的情绪状态和精神状态非常重要。我们也犯过很多错误。你知道，我有过我的第一家公司，那显然很酷，但也有很多棘手的时刻。而在 Cognition 的过程中，感觉像是把八年的时间压缩到了一年里，而且目前仍以这样的节奏进行着，但不知怎的，这实际上也让你更成功。我觉得也是如此，如果你不把这件事和你个人的价值绑定在一起，你就更能全力以赴，更能去做那些会带来成功的事情。这太有意思了。我最近刚录了一期播客，嘉宾是高管教练 Jerry Colonna，我觉得那期可能会在这期之前或之后播出，他有一条很重要的建议就是这种非常佛教式的做法——不执着和不依附于某个结果。是啊。好的，最后一个问题。我好奇这背后有没有什么故事，不过我们可以简短一点。Devon 这个名字背后有什么故事吗？或者有没有其他备选名字曾被考虑用作这个 agent 的名字？
Devon 这个名字从很早就开始用了。要知道，我们从一开始就在做 coding agents，我的联合创始人是 Steven 和 Walden 等人，当时我们有这样一个想法：好吧，我们开始吧，先不要设限，尽可能打开思路，让每个人都跳出框架思考，做自己的事。我们先让每个人都按自己的方式做一段时间，然后再整合，吸取所有经验教训。所以 Walden 做了一个虚拟的开发者版本，叫做 Dev Walden；Steven 也做了一个，叫做 Dev Steven；我们做了各种各样这样的东西。后来我们把它们整合成一个东西，我们说，好吧，这就是 Devon。所以 Devon 这个名字对我们来说很早就定下来了。不过我要说，我们当时确实有一个重大决定，那就是 Devon 的形象会是什么样的。如大家所知，有那些六边形。然后大家最近可能也看到了，其实还有一只水獭，一只膝上放着笔记本电脑的小水獭，那也是 Devon。我们当时也争论过该选哪个、不该选哪个之类的问题，但现在已经过了一段时间，不知怎的，我们仍然同时保留着六边形和水獭这两个形象。你跳过了 Devon 名字来历的部分。你原本是不是只有——哦，所以 Devman 就是 dev。对。所以当我们整合所有名字的时候，这就显得很自然了，它会成为我们都喜欢与之协作的通用 dev。是啊。太不可思议了。Scott，这次访谈太有意思了。天哪，我学到了很多，这总是个好迹象。最后两个问题。大家可以在哪里找到你以及 Devon？还有什么你想推荐给大家的吗？听众又可以怎样帮到你？好的。我们在 app.dev.ai。你也可以在 Twitter 和很多其他社交媒体上找到我们。我们当然非常希望听到你对 Devon 产品的任何反馈。还有很多东西需要探索，而且就像我说的，我觉得我们距离真正的软件工程未来大概还有 20 步之遥。所以，能听到大家在试用产品时的想法，对我们来说意义重大。如果有什么我们可以改进的地方，请随时告诉我们。Scott，非常感谢你来参加节目。非常感谢你邀请我。我聊得很开心。我也是。再见，各位。非常感谢你的收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅本节目。另外，请考虑给我们评分或留言，这确实能帮助其他听众找到这档播客。你可以在 lennispodcast.com 找到所有往期节目，或了解更多关于本节目的信息。下期再见。