正文
我们都是软件工程师，我骨子里依然是个程序员。
从宏观层面来看：计算机正变得越来越智能，能够做的事情也越来越多。也许有一天，计算机真的能完成我们所做的一切，人类不再需要负责任何事情。
我不认为这会很快到来。但在此之前，只要我们人类还需要编程，最重要的任务之一，就是指导计算机我们想要什么、想构建什么、想做什么。
所以从这个角度来看，
我认为随着 AI 变得越来越强大，编程只会变得越来越重要。
对我们来说真正令人兴奋的是，看到这种迭代式的转变。
目前的情况是，我们可以把 Devin 看作一个初级伙伴，或者一个由初级伙伴组成的团队，你可以和他们一起工作。
我们团队里的每一位工程师，在构建 Devin 的时候都会大量使用 Devin。
因此，Devin 每个月会将数百个 Pull Request 合并到 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 语言，甚至在打孔卡时代，基本上就是定义你面临的问题，并真正深入思考你想要的解决方案究竟是什么。思考架构，思考细节，并在你的脑海中精确地规划出你到底想构建什么，以及你想让你的计算机做什么。这是软件工程的伟大之处，也是它最有趣的部分。
然而，这些工作可能只占普通软件工程师大约 10% 的时间，其他 90% 的时间，你可能遇到了 Kubernetes 的错误，你必须 debug，你必须找出问题所在，或者是系统崩溃了，或者你某个端口没关导致了问题，又或者你需要迁移代码，需要升级到新版本之类的，更多的是类似执行层面的工作。
我们思考和构建 Devin 的一种方式，就是真正让工程师可以从「砌砖工」转变为「建筑师」。
很多时候，关键在于达到这样一个程度：你可以进行高层次的指导，并且可以精确地指定你想要的方式。
我认为这仍然非常需要由人来掌控，由人来进行完整的规范定义，但同时极大地放大了你在一天、一小时或任何时长内所能做的事情和所能构建的东西的量级。
Lenny：
未来，假设有人想进入软件工程领域成为一名工程师。首先，你认为人们是否还应该学习编程？其次，对于今天的工程师来说，你认为哪些技能会变得越来越重要，哪些会变得不那么重要？在我们讨论从「砌砖工」到为「建筑师」的转变时。
Scott Wu：
我很喜欢这个问题。
就「是否仍需学习编程」 这一问题而言，我的答案是绝对肯定的。
当你上计算机科学课程，学习这些基础知识时，当然你会学到一些关于特定语言如何工作的知识。但你学到的大部分内容实际上是关于逻辑分解问题的能力；其次是对于计算机模型以及长期以来我们构建的各种决策和抽象概念的理解，比如什么是数据库？应如何理解数据库？什么是垃圾回收系统，它们的运作原理是什么？以及所有这些不同的组成部分。
我们在编程领域已经经历过这些阶段。未来的发展阶段我觉得会更快、更大规模，但许多方面与当下情况相似。比如，当你现在使用 Python 时，实际上已经有很多内容被抽象化了。50 年前的人可能已经会说 Python 就是「你用英语解释你想要什么，然后计算机就为你做了」。这非常强大，它打开了大门。我们现在的程序员数量显然比以往任何时候都多，就是因为这个。
但当你作为一名工程师培养技能时，深入理解这些抽象概念并探究其底层原理非常有帮助。比如说，如果人们真的想对一段代码进行性能优化，他们会使用汇编语言。为了构建好的系统并理解这些东西，你肯定想要理解这些抽象概念，比如网络是如何工作的？TCP/IP 到底是什么？或者这段 Python 代码在被解释时会发生什么？或者所有这些细节。
我们会达到一种状态，即使没有任何经验的人，也能够凭借描述自己的需求来构建一些很酷的产品，完成很了不起的工作。但同时我认为，
在相当长的一段时间里，人们依然需要能够精准地思考细节，揭开抽象的面纱，非常精确地定义想要构建的东西以及构建方式。
Lenny：
你认为对于工程师而言，哪些技能会变得愈发有价值，他们应着重在哪些方面发力？
Scott Wu：
我认为是架构方面的技能。工程领域已经有「架构师」这一术语，我觉得它在发展方向上是合理的。常规的实现、编写样板代码等事情，AI 编程已经让我们在这方面快了不少。
关键问题在于理解复杂的系统，在整个公司的大背景下开展工作，思考正在构建的产品或正在从事的工作，弄明白我们想要解决的问题是什么？应如何解决这些问题？我们究竟想要构建怎样的解决方案？以及将要做出的关键决策和权衡是什么？
那些能够出色完成这些工作的人，将会越来越多地发挥自己的影响力。所以，如果说有什么不同的话，我认为几年后，程序员和工程师的数量会比现在多很多。而且，成为程序员的具体形式显然很快会发生改变。我们能构建的东西将会多得多。
人们常常提及「杰文斯悖论」，软件确实是杰文斯悖论的典型例证。我们人类社会总能找到越来越多的事物，为其构建软件、编写更多代码，真的还有很多事情可以去做。
Lenny：
对于那些不知道杰文斯悖论的人，你能简单解释一下吗？
Scott Wu：
当然可以。杰文斯悖论简单来说就是，当某样东西的价格下降时，总支出反而可能上升。你可以用金钱、时间或资源来思考这个问题。但这里的直接版本是，随着编程变得越来越容易，编程变得越来越有效，我们将拥有更多的程序员。
从一种零和博弈的角度来看，你可能会说，我们在软件工程方面的速度将提高 10 倍，这意味着我们需要的软件工程师将减少 10 倍。但我认为，实践中真正会发生的是，我们实际上将构建超过 10 倍的代码量。因为我们所做的所有工作显然都受限于我们实际构建、执行和迭代的能力，我们将会有如此多伟大的想法，如此多伟大的产品。人们将会构建更多个性化的体验，等等。将会有很多事情要做。
随着技术能力不断提升
开发工作会越来越向异步工作流转变
Lenny：
你说每位工程师都拥有一支 Devin「团队」。在你们公司，现在大多数工程师通常会同时与多少个 Devin 一起工作？
Scott Wu：
这个过程是异步的，你可以根据需要随时启动和关闭 Devin。团队中的大多数人，通常会同时与多达 5 个 Devin 一起工作。这是一种很好的工作流程，你有 5 件事要做，可以让 Devin 1 号做第一件事，Devin 2 号做第二件事，以此类推。我们花了一些时间才真正适应并达到这种状态，让它对我们来说非常直观。
这确实是一种不同的体验，你可以将大部分事情异步地交接出去。
你每个任务的目标是在那些真正需要你专业知识的部分出现，精确定义你正在解决的问题和你正在构建的东西，或者在一些比较复杂的部分，你需要引导 Devin 朝着你
想要做的特定类型的更改方向发展。例如，我希望这个类别这样设置，我们应该去修改所有下游对这个的引用。但基本上是让 Devin 异步地为你完成大部分工作。
Lenny：
你们大概有多少工程师？
Scott Wu：
我们现在的工程团队大约有 15 人。
Lenny：
15 人？哇哦。每个人大约有五个 Devin。所以 Devin 的数量是工程师的五倍。我喜欢这一点的原因是，这简直就是向未来的一瞥。你们在使用 AI 工程师方面遥遥领先于其他公司，所以观察你们的运作方式，基本上就能了解大多数公司最终将如何运作。
Scott Wu：
是的，而且我们自己已经看到了这种转变。在团队层面，大家不会花那么多时间仅仅编写样板代码或者只是进行纯粹的功能实现。人们可以将更多的时间专注于思考真正核心问题，比如，我们如何让 Devin 变得更好？最合适的 Devin 交互界面是什么？什么样的流程或功能组合才能真正让 Devin 体验尽可能出色？这就是我们喜欢的方式。
Lenny：
那么什么时候你们会达到这样一个临界点，即 Devin 的发展速度远远超过其他所有人？比如，一旦你有足够多的 Devin 在做所有这些事情，你就领先了 10 年、20 年、30 年、100 年。
Scott Wu：
全球的工程师们，都将思考这个问题，围绕这一方向开展开发工作，并逐步适应这些新技术。
随着技术能力的不断提升，即使在今天的稳定状态下，事情会越来越多地向这种异步流程转变。
其中一个原因在于，你始终受到现实世界约束的限制。可以这样理解（不过这些数字并非精确数据），最基本的逻辑是：能够编写文件、完成函数或某行代码之类的任务，已经带来了巨大帮助，使用体验也非常出色。但构建软件的很多部分几乎完全不是这样。
例如，当你修复一个 bug 时，需要启动本地服务器，在前端点击产品尝试复现这个 bug。一旦出现错误，要去查看 Datadog 了解情况，并尝试在日志中查找其他错误。还要查看哪里出了问题，做一些修改，甚至重新运行整个流程，以确保修改后的结果是正确的。这很大程度上就是作为一名软件工程师意味着什么。这些过程都需要真实的时间。
随着我们越来越多地转向这种智能体工作流程，从某些方面来说，这就像未来几年我们通过软件工程来实现 200%、500% 甚至 1000% 增长的真正途径。
Lenny：
让我们向大家展示一下 Devin 的工作原理到底是什么样子吧。
Scott Wu：
好的，与 Devin 协作的整个过程显然是异步进行的。所以，我想我们可以实际观看一下 Devin 的工作过程，然后我们可以看一些 Devin 完成的其他工作示例，或者 Devin 为我们团队所做的事情。然后我们可以异步地回来看看我们最初运行的那个 Devin。
我想强调的关键是，想想我们作为软件工程师，或者工程团队、产品经理等等，思考我们想要构建什么，想要交接什么。所以，我们已经用我们自己的 Devin 代码库设置好了 Devin。所以，我会为它启动一个 Devin。我会说：
「嘿 @Devin，我和朋友 Lenny 在一起。你能修改一下 Devin 的 web 应用，把 Lenny's Newsletter 作为 Devin 网站的一部分展示出来吗？就在真实的 Devin 网站上吧。」
所以我们启动这个任务。如你所见，Devin 立刻开始工作并做出回应。你可以异步地处理这个，也可以同步处理。这次，我们就稍微深入一点，看看具体发生了什么。但如你所见，Devin 正在浏览文件，查看很多东西。所以，我们可以根据需要在这里跟进，看看哪些是有意义的。你可以看到 Devin 已经指出了几个特定的部分。比如侧边栏，这是我们在前端实现的。那里有一些部分，我们将拥有一个新的组件，这个组件将链接到 Lenny 的网站。这听起来都不错。Devin 在问我们是否有什么问题。同样的情况，你可以让 Devin 自己做决定并交接，或者你可以提出更多想法。比如按钮应该在新标签页还是应用程序内打开？ 我会说，「让它在新标签页中打开吧」。
Lenny：
你可以在任何时候回答这些问题吗？它是在等你吗？
Scott Wu：
你可以在任何时候回答这些问题把任务交出去，也可以再收回来。
Lenny：
它不会说：「天哪，我刚写成这样，你为什么不早点告诉我？」
Scott Wu：
没错。关于 Devin 的一个重要优点是，Devin 总是充满热情，总是准备好投入时间。
我们会给 Devin 一点时间工作，它会浏览这些文件，然后为我们创建一个 PR，我们会看看结果如何。但我觉得展示一些 Devin 在其他场景下的例子也很有趣。
