第一个 AI 程序员 Devin 的公司，已经在用Devin 来构建「Devin」了。
去年 12 月，Cognition 推出了世界上首个 AI 编码程序员「Devin」，产品定位是无需人类参与自行编写代码，并完成通常分配给人类开发人员的整个项目，订阅价格 500 美元/月。
在推出「Devin」后的 6 个月时间内，Cognition 完成了数亿美元的 A 轮融资，估值翻了一番，达到近 40 亿美元。Cognition 成为 AI 编程赛道的绝对明星公司。
Cognition 目前仅有 15 人规模的工程团队，Cognition 的每个团队成员都有一个由 5 个 Devin 智能体组成的「团队」，Github Pull Request 已经有四分之一左右由 Devin 完成，Cognition 的创始人 Scott Wu 预计一年以后这个比例将达到 50%。
Scott Wu 在近期接受播客 Lenny’s Podcast 的访谈时更为详细地分享了 Devin 如何从一个概念成长为能端到端完成任务的“初级工程师伙伴”，如何融入到现有软件开发流程中，以及如何理解在 AI 浪潮下工程师的角色定位等思考。
TLDR:
-
我们整个团队大概只有 15 名工程师，团队里大多数人与 5 个 Devin 智能体组成的「团队」协作，Devin 每月会将数百个 Pull Request 合并到 Devin 代码库的生产环境中，占整个 Pull Request 提交数量的四分之一左右。
-
我们思考和构建 Devin 的一种方式，就是真正让工程师可以从「砌砖工」转变为「建筑师」。很多时候，关键在于达到这样一个程度：你可以进行高层次的指导，并且可以精确地指定你想要的方式。我认为这仍然非常需要由人来掌控，由人来进行完整的规范定义，但同时极大地放大了你在一天、一小时或任何时长内所能做的事情和所能构建的东西的量级。
-
对于智能体（agent）来说，你可以让一个智能体同时进行多条探索线，并且它们可以共享所有上下文。这还处于非常早期的阶段，但未来我们会看到这一点。一旦我们达到那个阶段，将会出现很多新的范式，等待我们去构建。
-
未来智能体编码的体验还会迭代 20 次。从现在到那时，还会有很多代际更迭。但 Scott Wu 认为，产品体验本身每次都会改变，同时还有将其推广到全世界的各种实际问题。所以，人们需要学习如何使用新技术。
-
几年后，程序员和工程师的数量会比现在多出很多。而且，成为程序员的具体形式很快会发生改变。
原播客访谈链接：https://www.lennysnewsletter.com/p/inside-devin-scott-wu
Founder Park 正在搭建「AI 产品市集」社群，邀请从业者、开发人员和创业者，扫码加群：
-
最新、最值得关注的 AI 新品资讯；
-
不定期赠送热门新品的邀请码、会员码；
-
最精准的AI产品曝光渠道
用 Devin 来构建「Devin」
Lenny：当人们开始使用 Devin 时，作为一名工程师，其工作方式和构建方式正在发生怎样的变化？
Scott Wu：我们都是软件工程师，我骨子里依然是个程序员。一直以来，我们思考的方式就是，这里面存在抽象层和工具。
从宏观层面来看：计算机正变得越来越智能，能够做的事情也越来越多。也许有一天，计算机真的能完成我们所做的一切，人类不再需要负责任何事情。
我不认为这会很快到来。但在此之前，只要我们人类还需要编程，最重要的任务之一，就是指导计算机我们想要什么、想构建什么、想做什么。
所以从这个角度来看，我认为随着 AI 变得越来越强大，编程只会变得越来越重要。对我们来说真正令人兴奋的是，看到这种迭代式的转变。
目前的情况是，我们可以把 Devin 看作一个初级伙伴，或者一个由初级伙伴组成的团队，你可以和他们一起工作。
我们团队里的每一位工程师，在构建 Devin 的时候都会大量使用 Devin。因此，Devin 每个月会将数百个 PR 合并到 Devin 代码库的生产环境中。
我们整个团队只有大约 15 名工程师，所以 AI 辅助编码在我们编写的所有代码中占了相当大的比例。我们每个人都拥有自己的 Devin 团队。
如果你要处理各种问题、功能请求、bug，或者研究你想构建的新范式，很自然地，会有很多交接点。在这些交界点，你就可以@Devin，然后告诉它：「现在情况是这样的，你能帮忙处理一下吗？」
有时候 Devin 能够百分之百自主地完成任务，直接创建 PR，然后你合并 PR；有时候，你可能需要自己介入，做 10%或 20%的工作，也许在具体如何界定范围或如何架构这个功能方面有一些细节需要你处理，或者你可能想在最后自己去测试前端，确保它看起来完全符合你的要求，并在之后给出你的一两句反馈。但在大多数时候，都是与 Devin 一起工作，让它并行处理更多事情，构建更多东西。
Lenny：目前你们的 PR 中，Devin 提交的和人类提交的比例分别是多少？
Scott Wu：我得查一下，但 Devin 大概占我们所有 PR 的四分之一左右。
Lenny：那六个月前是什么情况呢？
Scott Wu：相比六个月前，它在我们内部呈指数级增长。Devin 的发展关乎两个方面：能力和产品界面。
首先，它的智能水平提高了很多。
另一方面，我们也花了很多时间来研究如何构建它的界面：在这个界面上，即使 Devin 只能完成 80%或 90%的任务，你也能获得 Devin 的价值。
Devin 显然不是完美的，它会犯错。用户需要与 Devin 一起初步确定任务范围，然后让 Devin 去做用户想让它做的事，并在最后阶段介入审查并提供反馈。
用户还可以让 Devin 不断学习自己的代码库，它会变得越来越强大。
Lenny：今天你们大约四分之一的 PR 是由 Devin 提交的。你认为到今年年底这个比例会达到多少？
Scott Wu： 到今年年底，预计会超过一半。而且我们观察到的一件事是，你能够异步完成越来越多的工作，并且能够交接越来越多的任务。
我认为软件工程的灵魂，基本上就是定义你面临的问题，并真正深入思考你想要的解决方案究竟是什么，思考架构，思考细节，并在你的脑海中精确地规划出你到底想构建什么，以及你想让你的计算机做什么。无论是以前还是现在，无论你使用的是汇编语言、Pascal 语言，还是 C++、Python，这是软件工程的伟大之处，也是它最有趣的部分。
然而，这些工作可能只占普通软件工程师大约 10%的时间，其他 90%的时间，你可能遇到了 Kubernetes 的错误，你必须 debug，你必须找出问题所在，或者是系统崩溃了，或者你某个端口没关导致了问题，又或者你需要迁移代码，需要升级到新版本之类的，更多的是类似执行层面的工作。
我们思考和构建 Devin 的一种方式，就是真正让工程师可以从「砌砖工」转变为「建筑师」。很多时候，关键在于达到这样一个程度：你可以进行高层次的指导，并且可以精确地指定你想要的方式。我认为这仍然非常需要由人来掌控，由人来进行完整的规范定义，但同时极大地放大了你在一天、一小时或任何时长内所能做的事情和所能构建的东西的量级。
Lenny：你说每位工程师都拥有一支 Devin「团队」。在你们公司，现在大多数工程师通常会同时与多少个 Devin 一起工作？
Scott Wu： 这个过程是异步的，你可以根据需要随时启动和关闭 Devin。团队中的大多数人，通常会同时与多达 5 个 Devin 一起工作。这是一种很好的工作流程，你有 5 件事要做，可以让 Devin 1 号做第一件事，Devin 2 号做第二件事，以此类推。
你可以将大部分事情异步地交接出去，而你在每项任务中所做的事情，就是精确定义你正在解决的问题和你正在构建的东西，或者在一些比较复杂的部分，你需要引导 Devin 朝着你想要做的特定类型的更改方向发展。但基本上是让 Devin 异步地为你完成大部分工作。
Lenny：你们在使用 AI 工程师方面遥遥领先于其他公司，所以观察你们的运作方式，基本上就能了解大多数公司最终将如何运作。
Scott Wu： 是的，而且我们自己已经看到了这种转变。在团队层面，大家不会花那么多时间仅仅编写样板代码或者只是进行纯粹的功能实现。人们可以将更多的时间专注于思考真正核心问题，比如，我们如何让 Devin 变得更好？最合适的 Devin 交互界面是什么？什么样的流程或功能组合才能真正让 Devin 体验尽可能出色？这就是我们喜欢的方式。
把 Devin 当作你的「新同事」来用
Lenny：假设你现在可以手把手教 Devin 的新用户，给他们一些成功使用 Devin 的技巧，你会怎么说？
Scott Wu： 我认为最重要的一点是，真的把 Devin 当作你的新初级工程师来对待。我认为这是最重要的事情。
我认为人们进来，看到空白的页面，会想到各种各样他们想尝试的东西。
通常我们看到的有效的操作是，你可以尝试演示，你可以做一些事情。但很多时候是，我们弄清楚今天或这周我们想完成哪些任务，让 Devin 开始处理这些任务。
我们从比较容易的开始，然后与 Devin 合作，了解 Devin 需要设置哪些东西才能测试自己的代码并做得很好，然后随着时间的推移逐步扩大规模。当你与你的工程师（Devin）一起工作时，你会更好地了解如何与他们沟通，或者哪些任务或项目适合让他们参与进来，这确实是我们的核心理念。
Lenny：假设工程师每人有 5-10 个 Devin，他们就成了管理初级工程师的经理，这工作量可不小，光审核就够呛。他们要是说「我只想搞架构，不想修 bug」，你怎么看？
Scott Wu： 我认为「砌砖工」与「建筑师」的对比更接近于体验，而不是当经理。
管理当中遇到的很多困难，或者说人们回避它的原因，更多的是很多像上下文、所有权、责任之类的东西，然后还有各种情感方面的东西。
我认为与 Devin 合作更像是，拥有一个界面来交接任务和构建任务，找到合适的抽象层次，找到真正有效的工作流程。
你可以先让 Devin 尝试一下，如果效果很好，你就马上合并。如果需要一些修改，你可以给出反馈。这更像是让 Devin 成为你流程的一部分，而不是失去控制，我认为这是人们在管理方面最害怕的事情。
Lenny： 你是否在考虑推出一个经理 Devin，来管理其他 Devin？
Scott Wu： 有考虑过，Devin 可以通过 API 启动其他 Devin，我们已经见过这种用例了。
如果你有一些大的任务想做，Devin 会分块，你需要给它们相应的凭证才能做到这一点。目前这还不是默认启用的功能，但随着时间的推移，这种情况会越来越多。
对于人类，用技术术语来说，上下文和线程之间存在一种耦合。我的意思是，每个人只能在他们所做的工作上单线程操作，并且他们有自己的一套上下文。其他人可以同时做其他事情，但他们有自己的上下文。
对于智能体（agent），你可以让一个智能体同时进行多条探索线，但共享他们的所有上下文。这还处于非常早期的阶段，但未来我们会看到这一点，一旦我们达到那个阶段，将会出现很多新的范式需要构建。
是的，我们确实考虑过。Devin 可以通过 API 启动其他 Devin，我们已经见过这种用例了。
如果你有一些比较大的任务想做，Devin 会把任务分解成更小的部分，你需要给它们提供相应的凭证才可以做到这一点。目前这个功能还不是默认开启的，之后会越来越普遍。
对人类来说，用技术术语讲，就是上下文（context）和线程（thread）之间存在一种耦合。我的意思是，每个人在处理工作时基本上是单线程的，并且有自己独立的上下文。虽然其他人可以同时做别的事情，但他们也有各自的上下文。
但对于智能体（agent）来说，你可以让一个智能体同时进行多条探索线，并且它们可以共享所有上下文。这还处于非常早期的阶段，但未来我们会看到这一点。一旦我们达到那个阶段，将会出现很多新的范式，等待我们去构建。
用户粘性是关键「护城河」
Lenny ： 在 AI 编码领域，有多种不同的做法，你们全力打造 AI 工程师，但也有 IDE 公司和构建出色工程模型的公司。现在连 OpenAI、Anthropic、Cursor 等都在构建智能体。你们如何定位自己，又如何看待在这个领域取胜的关键？
Scott Wu ：我认为这些团队都很强，它们由非常聪明和具有前瞻性思维的人组成，正在构建许多优秀的产品。而且，我认为在未来几年，随着通用人工智能（AGI）逐渐实现，还有很多事情要做。
我非常喜欢的一句话是：2017 年，如果你问我们是否拥有通用人工智能（AGI），答案是否定的；而到了 2025 年，如果你问我们是否拥有通用人工智能，答案则是，你必须定义通用人工智能，而且这取决于你的研究领域。
这里触及到的一个核心问题是，现在正在发生很多真正令人惊叹的事情，很容易让我们低估这场变革的巨大程度。
在过去 10 年 -30 年里，有很多很棒的产品，它们让产品构建生命周期中各种不同细分领域的各个环节都变得更容易了一些。
例如，有很棒的即时响应产品，日志记录产品，计费产品，各种不同的工具。这些领域都将以数倍的速度发展，这将是一个数量级的转变。
从我们的角度来看，我们一直专注在一个领域，那就是自主编码智能体。
这里有很多问题需要解决，比如核心能力方面仍然有很多工作要做，我们经常遇到这样的情况：「Devin 为什么会做那个决定？任何人类工程师都不会那么做。」
在很多方面，比如产品界面，显然有很多需要思考的地方，这不仅仅是我们正在努力实现的单一目标，而是会随着每一次能力迭代而改变的东西，我估计未来智能体编码的体验还会迭代 20 次。
我们将在几年内达到一个阶段，那时你可能根本不需要看代码，只需要查看并指定任务，然后说：「我们在这里加一个新的标签页，应该保存这些信息。启动一个数据库表，并在 X、Y 和 Z 列上建立索引。」你将能够实时地与你的产品交互，并让你的智能体为你打造这些功能。
从现在到那时，还会有很多代际更迭。但我认为，产品体验本身每次都会改变，同时还有将其推广到全世界的各种实际问题。所以，人们需要学习如何使用新技术。
同时，在部署以及处理现实世界软件的各种复杂情况方面，还有很多工作要做。现在仍然有很多 COBOL 代码、Fortran 代码。人们已经做了很多各种各样的抽象和细节处理。
（注：COBOL 代码和 Fortran 代码都是比较「古老」的代码。)
所以我们从一开始就一直专注于智能体编码。这是我们真正相信并为之设计的一件事，甚至延伸到了收入模式和基于使用量的设置，也融入了所有的产品体验。
比如，你想在哪里与 Devin 交谈？你希望能够在 Slack 中与 Devin 交谈，你希望从你的问题跟踪器中启动它，当然还有能力方面。
所以我不认为有一个简单的答案，这是多种因素的结合。但这确实是我们过去一年半投入所有时间的领域，未来五到十年也将如此。
Lenny：沿着这些思路，AI 领域一个普遍的难题是护城河和可防御性。当构建产品变得容易，而且很多东西都建立在自身发展如此迅速的模型之上时，你如何思考在这个领域建立护城河？
Scott Wu：我认为这通常更多关乎用户粘性，而非护城河。通常人们所说的护城河是指某种能阻止竞争对手进入市场的东西。从宏观层面来看，许多不同公司在 AI 谱系的不同层面，比如基础模型实验室或应用层等，我不认为存在任何能够阻止其他人进入的硬性壁垒。
我认为真正存在的是粘性，我会将其定义为：一旦你用上一个真正喜欢的产品体验，是否会兴奋地持续使用它？
或者是否存在一种效应，即从现在开始，切换到一个新的产品并学习它也同样容易？从这个角度来看，我认为编码智能体有几个尤其出色的方面。
首先，随着时间的推移，存在很多固有的粘性和学习积累。把 Devin 比作人类工程师的话，第一天加入公司的工程师，与已经在公司工作了五年、自己写了一半代码、接触过每个文件、构建过每个部分、且熟悉团队其他成员的工程师，他们的产出是不可相比的。
Devin 也会真正学习并构建它对客户的代码库、技术栈和流程的认知，并随着时间的推移能够做更多的事情。
另一方面，我认为非常令人兴奋的是，我称之为代码的「多人协作」方面，确实有很多事情可做。这正是现实世界中很多事情的完成方式。
把 Devin 当成一个工程师，自己使用，这是一种用法。另外我们也经常看到，一些工程师与 Devin 一起工作并调教 Devin，人们会让 Devin 帮助新工程师入职，并向他们传授知识。或者我会在 Slack 中与 Devin 开始一个会话，我会说：「我们要做某某产品」；然后其他工程师会插话：「我们最初这么做的原因是 X 和 Y。Devin，当你做这个更改时，请确保仍然支持那个工作流程。」Devin 会说：「好的」。或者 Devin 会创建一个 PR（Pull Request），然后其他人会审查那个 PR 或给出一些评论，Devin 也会进行相应的处理。
在软件工程的各种场景里，Devin 为这样一种体验奠定了基础：它能够随着时间的推移，为客户整个工作提供的价值不断增长。我们更多地思考的是：如何让 Devin 在你使用得越多的时候，变得越来越有用？
Lenny： 之前 Cursor 的 CEO Michael 也有类似观点，他认为护城河或者说用户黏性，就像 Google 做到的一样：用户切换成本低，关键在于做到最好。你是否认为，如果能在此基础上创造出更强的粘性，让用户因为产品太好用、积累了知识并与你的工作流程深度集成而难以离开，那会更进一步？
Scott Wu：我认为软件工程这个领域的一个好处是，无论好坏，都有一个非常清晰的价值衡量标准。换句话说，至少在未来一段时间内，总会有一个清晰的下一个目标。
可能未来会有某个时刻，你可以对 Devin 说，帮我搭建一个完整的 YouTube，它真的能完成。而现在的 YouTube 背后，是数亿小时的人类工程时间，他们构建了算法、基础设施，以及每一个微小的细节。
而且，也许有一天 Devin 能以开箱即用的方式完成这个任务，虽然那将是很久以后的事情。
我认为开发者一个很酷的地方在于，他们真的愿意学习新的体验，并投入努力，如果这意味着他们能够获得越来越高质量的体验。
核心能力是构建专属 wiki，
全面理解代码库
Lenny ：给大家演示一下 Devin 的工作原理。
Scott Wu ：Devin 的诸多功能旨在与现有代码工作流程无缝协作。例如，我们当时在 GitHub 探索 deepseek-coder 代码库，将其导入 Devin 并建立独立分支（fork）。
我想强调的几个点是：其一，Devin 能构建专属 wiki，全方位呈现对代码库的深度理解。当 Devin 索引代码库时，它会生成代码库的表示形式，持续学习并优化，这是其核心能力之一。
有意思的是，我们发现人类也渴望了解代码库的表示形式，所以推出了 Devin Wiki。你可以浏览各个部分，查看不同层级的构建与组合图表、部署操作，以及丰富的架构细节，并据此提问。
比如，你可询问：「DeepSeek 如何处理多 token 预测？」 Devin 会搜索整个代码库，给出有理有据的回答。我们常常使用这项功能，尤其在规划任务与提供初始提示时，即便没有特定任务也十分实用。
工程师思考大型代码库的方式是：更改或思考特定任务时，不会一次性记住每一行代码，而是先形成高层次抽象概念，审视后逐步聚焦，再获取更清晰的细节。Devin 的工作方式与工程师相似，先把握高层架构，再深入组件提供细节，因此它是可扩展的。
Lenny：这其实回归了工程师即架构师的理念，Devin 正协助你理解架构。
Scott Wu：没错。我们发现了一个有趣的用例，用户经常借助 Devin 来引导新加入团队的工程师。刚加入团队时，你对代码库和程序设置充满疑问，有时向导师或经理提问会稍显尴尬，尤其担心问题幼稚。此时，直接询问 Devin，浏览其生成的 wiki，理解内部表示形式，就很有帮助。
Lenny ：这很有趣，又回到了你的观点，Devin 不仅是初级工程师，而是具备「参差不齐」的智能，像资深工程师一样理解代码库。通常，你得询问长期在此工作的工程师，这个东西是干啥的、在哪、怎么运作，而 Devin 在这方面的表现得令人惊讶。
Scott Wu ：是的，检索和处理大量代码与 token 正是语言模型的强项，它能在你需要时提供帮助。
Devin Wiki 是我们上周刚推出的功能，与 Linear 完全集成。如果你在 deep seek 代码库有任务，只需要添加 Devin 标签，Devin 就会给出对任务的看法。你可以查看每个特定文件，或它标记的重要代码片段。若认可构建内容和结论，就可以启动 Devin 会话，来实际完成任务。
Lenny ：听起来是个简单想法，但本质上，你在说 Linear 中有修复和功能任务，现在 Devin 可以直接帮你搞定。
Scott Wu ：这是个需要手动操作的过程。当 Devin 规划任务或提供想法时，你当然希望参与其中。Devin 还会告知它的把握程度，比如对某个部分的理解可能性，这有助于加快进度。
正如你所说，很多产品经理喜欢用 Devin 和 Linear 更好地理解事物、代码库等。例如，Launch Darkly 的 Claire Vo 是 Devin 的重度用户，她喜欢规划任务，询问数据相关问题，或者某个功能是否已合并到生产环境，又有多少人正在使用某个功能等。这是一种简洁地获取智能的方式。
我喜欢它与 Linear 的集成，依然保持简单。你可以添加一个小工单，比如将某个内容链接到主页，Devin 能精准理解并展示。
Lenny ：人们应该如何看待 Devin 擅长的领域以及可能出问题的地方？
Scott Wu ：我认为 Devin 在处理明确任务时表现出色，你应该给 Devin 分配任务，而不是问题，比如快速的前端功能请求、bug 修复、添加测试和文档等。
让循环变得非常好的一个因素是能够快速迭代和测试。例如，直接调出预览查看链接是否有效，Devin 也很容易做到这一点。
05
「我们已经度过了 AI 代码的拐点」
Lenny：在不泄露商业机密的前提下，是什么让你们能把 Devin 做得这么好？是因为某个特定模型的突破吗？有些人分享过，Claude sonnet 3.5 和 3.7 版本对他们的很多产品来说是一个巨大的突破。你们在架构或构建 Devin 方面，使其如此出色运作的关键是什么？
Scott Wu：我们很早就开始押注于智能体，我认为智能体比大多数人想象的要更早地变得可行和实用。随着整个社区真正围绕它团结起来，你可以在预训练中看到它的影响，你可以在很多与这些模型相关的工作中看到它的影响。
从我们的角度来看，我不认为 Devin 的表现出现过任何单一的、阶梯式的基础模型转变或其他任何导致天壤之别的变化。
但现在每周都会有新模型问世，这也对我们能做的事情产生了重大影响。在此基础上，我们与基础模型实验室的研究团队合作，在他们的基础之上进行我们的工作。
所以，我想在这里给出一个大胆的观点，我认为在基础智能方面，基本上已经达到了我们的要求。我们不会自己预训练模型，不会去提高模型的基础智商，而是更多地教会它现实世界工程中的所有特质和细节。例如思考如何使用 Datadog，如何找出程序中的错误，如何处理每一种情况，如何创建 GitHub PR。
我们每天所做的工作中，都有非常多的细节和特殊性，这更像是教会模型去反映现实世界的复杂性，而不是让它达到某种更高的、根本性的解决问题的水平。
Lenny：你曾经分享过一个关于以往颠覆性技术增长的观点，那些技术非常依赖硬件，并且其增长存在限制因素，而 AI 则不同。
Scott Wu： 出于多种原因，我认为 AI 将是我们一生中经历的最大的技术变革。
但我想说的一点是，过去 50 年我们经历的大多数重大科技革命，像个人电脑、互联网和移动电话，它们都有一个重要的硬件组成部分，这在推广普及中扮演了重要角色。
互联网最初只是一些大学之间相互通信，但随着时间的推移，整个世界都接入了互联网，这花费了很多很多年。
移动电话也是如此，个人电脑也是如此。关于这一点特别有趣的是，我们已经看到了这种影响：在这些机器中，有很多事情取决于实时性。
所以，那些为这些行业开发产品的人，都亲眼见证了他们的市场随着手机用户和互联网接入人数的增加而逐年稳步成长，很多企业都是从行业初期就开始发展起来的。
像 Apple 和 Microsoft 几乎是在同一时间创立的，很多伟大的互联网企业或其他企业也是如此。它是一个随着时间的推移触及了整个世界，或者说触及了整个世界很大一部分的事物，产生了非常巨大的影响，但它花费了数年时间才得以实现。
我认为 AI 已经显现出的一大不同之处在于其技术的爆炸性增长潜力。
我认为我们已经稳稳地度过了 AI 代码的拐点，也就是说，作为一名工程师，如果你完全不使用 AI，你会被甩在后面。这是一种每个人都应该拥有和使用的技术，而且没有任何硬件分销的阻碍。这意味着这个领域正以指数级速度增长。
这是一个有趣的时代，这将需要真正的投资和真正的工作。但是，从我们的角度来看，作为工程师，这意味着与正在发生的一切保持同步非常重要。不仅是你学习和使用这些技术的能力，而且还关乎你教会 AI 关于你的代码库的知识，以便让它能够真正有效地与你一起构建，并做更多你想让它做的事情。
06
AI 编程并不会导致工程师数量减少
Lenny：Devin 刚推出时宣传是「你的新人 AI 工程师」，它当时和现在的能力分别如何？
Scott Wu ：一年前我们首次发布 Devin 时，大家甚至觉得智能体很难实现。2024 年初，AI 模型的推理能力还处于相当早期的阶段。从那时起，它有了显著的发展。从实用技能方面来讲，我们偶尔会做些比较，最开始的时候，它就像一个高中计算机专业的学生，后来逐渐成长得更像一名大学实习生，而现在则相当于一位初级工程师。不过这些判断标准比较粗略，因为我很赞同 「参差不齐的智能」 这个说法，它在某些领域比人类强出不少，可在另一些方面又不如人类。在过去一年里，我们收获了许多经验，不只是关于编码智能体，更是关于智能体本身 —— 包括怎样构建智能体，以及如何将其融入工作流程，使之与人协同工作。
当时，Devin 还没有 Slack、GitHub、Linear 集成，也没有交互式的规划阶段，更没办法修改它生成的代码。所以，从那时起我们开发的诸多产品功能，基本都是为了找到最佳方式，让与 Devin 协作以及向 Devin 分派任务的体验尽可能顺畅。
Lenny：所以很多工作不只是单纯地提升 Devin 成为最优秀的工程师，而是让其更好地适应与人的协同合作。
Scott Wu：我觉得这两方面是各占一半的。一方面是 Devin 的能力有了显著且可衡量的提升。另一方面是产品界面、工具等的优化。现在大家普遍知道如何使用聊天机器人并与其协作，但对于智能体，我认为用户仍需花费一些时间和精力去学习如何使用它们并最大化地发挥其价值。所以，看到许多其他公司如今也纷纷在智能体领域投入精力，真的让人感到很兴奋，这是我们所有人在共同探索的方向。
Lenny：未来，假设有人想进入软件工程领域成为一名工程师。首先，你认为人们是否还有必要学习编码？
Scott Wu：我很喜欢这个问题。就 「是否仍需学习编码」 这一问题而言，我的答案是肯定的。
计算机科学的核心，首先是逻辑上分解问题的能力；其次是对于计算机模型以及长期以来我们构建的各种决策和抽象概念的理解，比如什么是数据库？应如何理解数据库？什么是垃圾回收系统，它们的运作原理是什么？以及所有这些不同的组成部分。
未来的发展阶段我觉得会更快、更大规模，但许多方面与当下情况相似。比如，当你现在使用 Python 时，实际上已经有很多内容被抽象化了。在培养工程师技能的过程中，深入理解这些抽象概念并探究其底层原理十分关键，例如网络是如何运作的？TCP/IP 到底是怎么回事？或者这段 Python 代码在解释执行时会发生什么？
我们会达到一种状态，即使没有任何经验的人，能够凭借描述自己的需求来构建一些很酷的产品，完成很了不起的工作。但同时我认为，在相当长的一段时间里，人们依然需要能够精准地思考细节，揭开抽象的面纱，非常精确地定义想要构建的东西以及构建方式。
Lenny ：你认为对于工程师而言，哪些技能会变得愈发有价值，他们应着重在哪些方面发力？
Scott Wu ：我认为是架构方面的技能。工程领域已经有 「架构师」 这一术语，我觉得它在发展方向上是合理的。常规的实现、编写样板代码等事情，AI 编程已经让我们在这方面快了不少。关键问题在于理解复杂的系统，在整个公司的大背景下开展工作，思考正在构建的产品或正在从事的工作，弄明白我们想要解决的问题是什么？应如何解决这些问题？我们究竟想要构建怎样的解决方案？以及将要做出的关键决策和权衡是什么？
那些能够出色完成这些工作的人，将会越来越多地发挥自己的影响力。所以，如果说有什么不同的话，我认为几年后，程序员和工程师的数量会比现在多出很多。而且，成为程序员的具体形式显然很快会发生改变。
人们常常提及「杰文斯悖论」，这是一件很有意思的事情。软件确实是杰文斯悖论的典型例证。我们人类社会总能找到越来越多的事物，为其构建软件、编写更多代码，真的还有很多事情可以去做。
Lenny ：那么什么时候你们会达到这样一个临界点，即 Devin 的发展速度远远超过其他所有人？
Scott Wu ：全球的工程师们，都将思考这个问题，并努力适应这些新技术。随着能力的提升，我认为事情会越来越多地向这种异步流程转变。
其中一个原因在于，你始终受到现实世界约束的限制。在构建软件的很多环节中，都需要耗费大量的时间。例如，当你修复一个 bug 时，需要启动本地服务器，在前端点击产品尝试复现这个 bug。一旦出现错误，要去查看 Datadog 了解情况，并尝试在日志中查找其他错误。还要查看哪里出了问题，做一些修改，甚至重新运行整个流程，以确保修改后的结果是正确的。
随着我们越来越多地转向这种智能体工作流程，从某些方面来说，这就像未来几年我们通过软件工程来实现 200%、500% 甚至 1000% 增长的真正途径。
Lenny ：这很有趣，因为它与人们谈论合成数据和强化学习的方式十分相似，也就是创建非常简单的数据，答案明确，是或否，非常清晰。在你们设计和构建 Devin 的过程中，争论最多的是什么？
Scott Wu ：我想到了几个例子。其中一个我想说的是一个我称之为 「我们应有多固执己见」 的问题。
我们有各自常用的 Devin 工作流程，它能集成到 Slack 和 GitHub，在我们的代码仓库中为我们创建 Pull Request，响应问题报告等。当然，我们也会遇到很多其他各种各样的情况，很多人在使用 Devin，创造出不同的用例，甚至有人用 Devin 点 DoorDash 外卖。而且还有许多人从头开始构建很酷的网站，或者做类似的事情。这对我们而言是一个有趣的权衡，我会这样描述它：我们产品中构建的大部分功能肯定是针对创建 Pull Request 和工程团队使用的用例。但我觉得，如果人们想将 Devin 用于其他目的，我们也会确保他们充分了解局限性以及可能遇到困难的地方。
生成式 AI 很有意思，我看到的最常见的创业建议之一是：专注于一个非常小众的群体，做那些无法规模化的事情，打造一个真正出色的用例，然后从那里开始拓展。我认为这在各个方面都是很好的建议。但是，对于生成式 AI 而言，你很自然地会看到很多产品体验最终会变得更通用。这是我们依然在反复思考的一个问题，我们也希望能够做一些事情来支持其他类型的用例，来处理人们可能想用 Devin 去做的事情。
另一个问题是，Devin 应该在多大程度上成为一个单一的综合项目体验，还是更像一套工具？我们有 Devin Search、Devin Wiki，还有 Linear 工单范围界定功能，这些工具是相互作用的。但随着时间的推移，我们越来越将其视为一套工具。而且我认为，构建各种功能的智能体，即 Devin，是核心部分，这将永远是我们工作的真正特别之处。
然而，现实世界的软件共享需要一套复杂的工具，有很多不同的流程和诸多不同的用例是合理的。例如，你可以向 Devin Search 和 Devin 提出相同的问题，Devin 可能会马上开始运作，但用户有时更倾向于拥有控制权。你可能正在设计一个编程任务，但还不希望 Devin 马上开始这个任务。你只想问问 Devin Search，了解代码库的哪些部分可能相关，或者只提出看看相关代码库片段的请求，或者通过查看 wiki 了解现有的表示。所以，无论是在功能方面还是在用户体验方面，我们都发现这些功能随着时间的推移变得自然而然且十分有意义。
07
创业：把 3、5 件事情做得比想象中更极致
Lenny：Devin 的起源故事是怎样的？
Scott Wu：刚开始时，有几件事我们坚信不疑。其中之一是强化学习确实有效，并将成为能力上的下一个重大范式转变。
当时 ChatGPT 于 2022 年首次推出，那些模型在 AI 领域，我们称之为模仿学习（imitation learning）。基本上就是让模型阅读互联网上所有能找到的文本，然后训练它像互联网上的某个人那样说话，这是最初做法的核心。它非常了不起，通过了图灵测试，并且对很多事物拥有百科全书般的知识。
我们过去一年进入的这个新范式，是真正高算力的强化学习。这是一个截然不同的范式：它能够去执行任务、整合事物，然后根据结果的正确与否进行评估，并利用这些知识来决定下一步行动并从中学习。我们坚信这一定会发生。
对我们来说，代码是很自然的选择，有几个原因。一是因为我们自己都是编程爱好者，所以代码对我们来说再熟悉不过。另外，代码本身就有一个完整的自动化反馈循环，你可以运行代码，这种自动化反馈正是强化学习所需要的，也使得这些模型在编码方面表现出色。
另一件我们坚信不疑的事情是，产品体验将从「文本补全」模式转向「智能体」模式。从根本上说，文本补全领域已经有很多很棒的体验。它被用于市场营销、客户支持、教育和编码，例如 GitHub Copilot 是那一波浪潮中真正的主导产品。
但我们真正预感到的重大转变，是从这种文本到文本的模型，转向一个能够做决策、与现实世界互动、接收反馈、迭代并采取多个步骤解决问题的真正自主系统。我们称之为智能体，这正是我们当时真正兴奋的事情。所以，方向一直是编码，一直是智能体。这看起来像是一开始就应该很明确的，但即便如此，在过去一年半的时间里，在编码智能体这个大方向内，我们感觉自己好像已经调整了八次方向左右。
Lenny： Devin 这个名字背后有什么故事吗？
Scott Wu： Devin 这个名字很早就定下来了。我们从一开始就对编码智能体感兴趣。例如，我的联合创始人是 Stephen 和 Walden，我们当时有了这个想法。
我们在最初创业时，尽量扩大范围，让每个人都能跳出思维定势，让每个人先做一段时间自己的事情，然后我们再整合，吸取我们学到的所有东西。
Walden 制作了一个他的虚拟开发者版本，叫做 Dev Walden，然后 Stephen 也做了一个他的版本，叫做 Dev Stephen。我们把这些都整合到一起，它就是 Devin。
Lenny：在构建 Devin 的过程中，你学到的最反直觉的事情是什么？那种与初创公司普遍认知相悖的。
Scott Wu：最近在我们构建 Devin 的过程中，我思考了很多。这其实不是我的第一家公司。对我们很多人来说，这都不是我们的第一家公司。我们团队总共有 26 或 27 人，其中大概有 18 个人在此之前创办过自己的公司。
我想到的一件事是，有一些在初创公司里你经常听到的非常普遍的「陈词滥调」，比如你必须快速行动，或者你必须雇佣优秀的人才。总是有那么三到五件事情被反复提及，它们是初创公司的普遍认知。
我最初创业的时候，作为创始人，确实有这样的想法。但是当你真正深入其中，投入了很多年之后，你会学到成千上万其他你需要学习的东西。在这些不同的事情上，你都会遇到很多小的细节，包括团队建设、产品、战略、工程决策、融资、销售以及所有其他组成部分。
随着时间的推移，我越来越觉得，要把公司做好，有时候仅仅是把那三到五件事情做得比你想象中还要极致。
每个人都说我们发展很快，但事实是，我们 2023 年 11 月办了个黑客松，12 月又办了一个，2024 年 1 月份正式成立公司，2 月份就把原型产品给初始用户试用了，3 月份我们发布了产品，4 月份就有了第一批客户。
我们在每一个地方都真正地加快步伐，这对我们来说真的产生了很大的影响。
是的，每个人总是说，你应该雇佣优秀的人才，我认为背后的真理是，你应该不惜一切代价，去争取那些你真正想引进的人才。
我最喜欢分享的一个故事是，我们有一位候选人来面试。他是麻省理工学院（MIT）的大三学生，非常年轻。我们给他安排了面试，他的表现比我们以往面试过的几乎所有全职候选人都要好得多。
所以我们说：「你觉得休学一段时间，和我们一起工作，构建 Devin 怎么样？我们认为你从第一天开始就能产生巨大的影响。」
他考虑了一段时间回来后说：「我愿意，我想这么做，但我的父母希望我能从学校毕业。我不确定有什么办法能行得通。」于是我们谈了更多，也了解了情况。
然后我们飞往北卡罗来纳州，从机场直接去了他父母家，和他们以及他父母共进晚餐，我们聊了很多，试图了解他们需要什么。他们说：「这听起来是个很好的机会，但我们希望我们的儿子能够毕业。」我们仔细讨论了这个问题，并想出了一个方案：他可以全职为我们工作，但同时参加他必须上的课程，并完成他需要做的事情来拿到文凭。我们讨论了这个问题，然后达成了一个大家都满意的方案。我们直接回到机场，那是我第一次也是唯一一次去北卡罗来纳州。
你雇佣优秀的人是一回事，但真正永不放弃，并尽你所能为那些真正适合团队的人创造条件，这才是关键。
他已经在我们团队工作一年多了，是一位非常棒的工程师，没有他，我们走不到今天。
Lenny：这些故事太不可思议了，它们让「雇佣最优秀的人才」变得如此真实。
Scott Wu：我们非常努力地从头开始重新构想事物，思考未来 5 到 10 年技术会走向何方？以及我们希望在未来扮演什么样的角色？
Lenny：我在想，有一天人们会不会为了最好的 Devin 而争抢。
就像万智牌卡牌一样交易 Devin。回到你说的三到五件事，这是非常棒的建议，你总是听到要雇佣最好的人，快速行动，构建人们想要的东西。
Scott Wu：是的，构建人们想要的东西，尽可能地贴近你的客户。
我认为另一件事是，始终思考事情未来的走向，而不是它们今天的样子，尤其是在 AI 领域，发展迅速，优秀人才众多。
对我来说，这里的重点是保持专注，感觉好像有 1000 件事情你应该做，但其实总是这 3-5 件事情。
Lenny：你还有什么想分享的吗？还有什么想留给听众的？
Scott Wu：最重要的事情是，我对 AI 构建的产品非常乐观，不仅仅是代码和 Devin，而是整个领域。每个人都能成倍地放大自己的能力。
（文：Founder Park）