图片来源：Matthew Berman

当Thomas Dohmke第一次看到GPT-3生成Python代码时，他的反应是：“这不可能奏效。”作为GitHub现任CEO、前Copilot项目负责人，他曾是代码世界里最冷静的现实主义者。但在2020年那个夏天，Codex完成了一个排序算法——没有编译器支持，却语法完美，那一刻，他意识到软件开发的未来已经到来。

本次访谈中，AI产品专家Matthew Berman与Thomas展开了一场极具穿透力的对话，回顾了从最早的代码自动补全、到今天多模型Agent协作的全过程。他们探讨了一个关键问题：当AI不再只是建议代码，而是开始主动设计、修改和验证系统时，软件开发者的角色到底发生了什么变化？

Thomas指出，真正的变革，不是“写代码这件事被AI取代”，而是写代码的“起点、过程与目的”正在被重构。过去，程序员从复制粘贴开始学编程，而现在，AI正将“vibe coding”（氛围编程）和“agentic DevOps”（代理驱动交付）结合起来，让软件开发更像构建一个系统生态，而非堆砌指令集。

他还首次透露：GitHub Copilot将正式开源，这是继VS Code之后又一次对开发者生态的深度承诺。他坚信，未来的代码是由人类的创意、AI的算力和Agent的系统能力共建的。“AI不会消灭开发者，只会激发他们更大的创造力。”

Thomas的经历横跨编译器开发、开源运动、AI工程管理，是硅谷极少数在“模型尚未流行前就成功产品化生成式AI”的第一批实践者。在这场对话中，他不仅复盘了一次技术奇迹的诞生，也给出了一个更清晰的行业方向：Agent不是工具，而是平台；开发者不是被替代者，而是新的指挥者。

以下是全文翻译。

奇迹：AI 生成式工具如何颠覆写代码的第一印象

Matthew Berman：Thomas，非常感谢你和我聊天。我真的很激动，特别期待讨论软件的未来，尤其是编码Agent的未来。我的第一个问题是，你曾领导GitHub CodePilot的开发。这是在最近的生成式AI浪潮之前。在这个项目中，你输入Alina代码，点击Tab键，它就会为你完成代码。当我第一次看到它时，真的非常震撼。你第一次看到当时的GPT以及代码补全功能时，你有什么感想？那种感觉是什么样的？

Thomas：起初，我觉得它永远不会奏效。我在上世纪90年代末和2000年代初在大学时做过很多编译器的工作。所以我明白编译器的工作原理。当时我简直不能相信模型竟然能够区分Python、Ruby或Java的语法。我以为它肯定会搞混，把括号放错位置，或者在不需要的地方加上分号等等。然而，当我在2020年夏天第一次看到GPT-3以及后来Codex时，这款开源的第一个编码模型能够根据提示生成代码，比如说写一个号码检测或某种语言的排序算法时，竟然可以提供整套正确语法的方法，尽管没有编译器支持。它还没有像我们如今编码Agent中用到的那种工具调用能力。

Matthew Berman：是的，当你和团队首次推出时，那时我真的大开眼界。其他在我团队工作的工程师们都说，“你一定要试试，这将带来巨大的改变。”你马上意识到软件开发将永远改变了吗？

Thomas：我们在这之前就看到了一些迹象。在GitHub，我们总是先将每个功能发布给员工内测。所以我们对Copilot也做了同样的事，大约在2021年6月发布预览或公开预览的三四个月之前。用户的反馈非常出色。我们跟踪了代码的编写量，第一次的遥测数据回来时，我的团队进行每周回顾，他们发现启用功能的文件中，它写了大约25%的代码。我们一开始不相信这个数据，就让他们去重新检查到底是怎么测量的。他们回来确认，没错，这个数据是真实的，现在甚至更高。对于不同的编程语言效果也不同，这也验证了我们的想法，这不是什么随机数字。比如说对于Python这样的语言效果比较好，而对于C或C++这样的语言效果较差，如果你考虑这些语言的历史和它们对某些头文件的导入或包含依赖，这就很合理了。

另一个指标是净推荐值，这是用户的反馈评价。我们大约是72分，这在-102到100的范围内算是很高的满意度分数。预览版本通常很少有这么高的分数，特别是在我们改变开发者的日常工作流时。有很多开发者，包括我自己，对他们想要的配色方案和快捷方式配置都很挑剔。在VS Code中，你可以在设置和扩展中自定义很多选项，这也是一个重要的吸引力。所以每个人都有自己的开发环境。当我们把Copilot引入这个环境时，告诉他们现在你有了Copilot，它将总是预测接下来的十行代码。然后你需要阅读这些代码并决定是否接受。我们原以为这种方法会被认为消极，实际上反馈却是非常积极的。正如你所述，我们首次发布私人预览，然后是公开预览，很短时间内，Copilot用户就突破了一百万。许多人都有这样的时刻：起初我怀疑这个工具，然后发现它确实有效，简直像魔法一样。这在当时引发了大量的推文和帖子，就像是在描述这一现象。

融入：从自动补全到行为设计，AI 如何适配开发者日常

Matthew Berman：我想谈谈用户体验。现在回头看，Tab补全功能似乎再显而易见不过了。但在那之前并没有这样的功能。它让学习曲线变得如此低。你是如何确定Tab补全作为你的AI编码助手与开发者之间的第一个交互点的？

Thomas：在Visual Studio和Visual Code中，有一个称为IntelliSense的功能，它利用编程语言和该语言的库信息来告诉你类中有哪些方法。这会以小下拉菜单的形式显示，你可以看到哪些选项是可用的。许多其他集成开发环境（IDE）也有类似的功能，比如在开发iPhone应用时使用的Xcode，它帮助你编写那些冗长的Swift方法，并显示这些方法的参数。所以有些行为已经成为开发者的习惯了：即便你不记得每个方法的完整拼写，只要能够记住前三四个字符，自动补全IntelliSense便能帮助你。编辑器如TextMate和Sublime也有智能自动补全功能，它们会查看你本地的文件，提取你已经编写过的方法，并为你进行预测。因此，你可以编写一个方法，当你调用这个方法时，它知道方法的声明，将其自动补全。这种从开发者的自动补全中学来的行为已经有一段时间了。我想应该已经有差不多20年了，也许稍微少一点，但我第一次使用TextMate的时候，它就有智能自动补全功能。

另一方面，如果开发者没有过目不忘的记忆力，总会有查找资料的时候。无论是在文档中、浏览器里，还是在Reddit、博客文章，或者像Build这样的开发者大会视频中，当然还有GitHub上的库和开源项目。他们可能在尝试解决问题，例如如何访问某个API、如何进行圆角处理、如何编码一个字符串等。通常，他们会找到一段代码片段并粘贴到编辑器中，然后根据自己使用的变量名和编程语言或库的版本进行修改。因此，总会有这样一种学习行为，即从别处获取代码，并让它适应特定的场景。实际上，大多数人都是通过这种方式学习编程的。通过某种形式的反复尝试，你可能从其他地方拿来一些东西，比如“Hello World”教程或指导，然后将其修改成自己的第一个应用程序。

在编辑器中拥有自动补全功能，你可以利用这种学习行为让代码正常工作，即使它不是完全完美的。然后，你将其与2020年的大型语言模型Codex结合，虽然它也存在一些不足之处，并有时会产生幻觉，但它已经足够好，能够简化从别处查找资料的过程，帮助你保持在流状态。我们相信，对于软件开发者来说，这种“流状态”是非常神奇的。你有一个想法，你想要构建它，就可以在有限的时间内集中精力和能量去实现。因此，只要我们能让你在IDE中不断构建，代码顺利流动，你继续进行Tab补全并修改，编译并持续推进，对许多开发者来说，这是最佳时刻，尤其是在代码成功运行的时候。这样，你可以看到，尽管只是依靠自己的双手和一点思考、创意，就创造出了这些东西。

重塑：从学习语言到验证Agent，开发者身份的演变

Matthew Berman：您提到学习编程时，通过获取代码片段并加以修改是一种常见的学习行为。那么，我想和您讨论编程教育。这是您一直以来非常关心的话题，也是我关心的。学习编程可能是我学过的最重要的技能之一，因为它使我能够将想法变成现实。从两年多前开始，如果有人问我应该教孩子什么，我自己有两个小孩，一个七岁，一个两岁，我可能会说我想教他们编程。然而，现在我并不那么确定了。但我还是认为学习系统思维确实有很多好处。您怎么看？您是否仍然支持教孩子们学习基础的编程语言？

Thomas：绝对支持，百分之百。孩子们应该学习编程，因为它在当今生活中是如此重要的一部分。软件无处不在。显而易见，我们口袋里的设备和我们的列表都在运行软件。我们的汽车主要由软件定义，而且如果你有一辆电动汽车，还包括一个电池。我们的房子、旅行都受软件影响，当然，大多数职业生活也是一样。即便是像农业或者警务这样的领域，现在也大量使用软件。因此，我觉得就像数学、物理、化学以及在学校里学的其他科目一样，尽管以后可能不会再去使用，但学习它们是为了理解这个世界。理解计算机科学，具备基本的阅读代码能力，了解二进制逻辑、布尔逻辑及二进制编码，是每个人都应该学习的技能。无论他们是否会在未来成为计算机科学家、物理学家或者只是因为我在学校学了音乐并不意味着我该站上舞台唱歌。我个人是这么认为的，我不知道你怎么看。但这并不意味着我不该在学校接受这些课程。

首先，可以说软件、计算机和技术在未来几十年甚至几百年内会继续发挥重要作用，这点是无法争论的。其次就是，现在我们已经构建并推出了编码Agent，例如GitHub Copilot。这很神奇，因为你给它一个任务或问题，或者描述你要构建的东西，它会在现有的代码库和存储库中找出如何在代码库中实现该问题。所以它不仅仅是从零开始，我们已经看到了很多这样的演示。我自己也做过，比如构建一个贪吃蛇游戏。但实际上，它是利用现有的代码库，基于描述对代码库进行修改，并创建我们称之为“拉取请求”的东西，以显示代码是如何更改以实现功能的。

现在，工程师的角色变成了验证Agent所做的事情。他们需要阅读所有这些变化。如果你有足够长的工作经验和理解力，你如何验证Agent所做的内容确实符合你的目标、符合你的业务，并且能够保持客户对我们的信任？因为显而易见的危险是，Agent可能会创建不安全的代码，导致安全事故，使得我们需要去解释、处理客户数据丢失的假设情境。比如，你可以想象很多这样的情况，Agent做了一些事情，当下感觉很好，因为它做得非常快，但是由于你没有真正理解它的工作，可能会损害业务。因此，对于每个正在进行软件开发的企业来说，至关重要的一点是理解这些Agent建造的东西，以及如何利用它们来最终创造竞争优势。

Matthew Berman：所以，现在不仅仅是学习核心编程语言及其如何运作，比如语法、逻辑运算符的使用，学习AI辅助工具的使用也同样重要。请告诉我你的看法或纠正我。

Thomas：学习这门技艺，就像学习工艺一样。你必须掌握这种技艺，还需要不断发展它。在软件开发中，如果你从事这个行业已经20年了，你会知道20年前的软件开发方式和今天的方式是非常不同的。20年前，开源软件在许多企业里仍是一个新鲜事物，它们对安全性和合规性以及一旦开源项目的创建者失去兴趣时，谁来维护这些项目存有担忧。如今，20年后，从操作系统到容器管理，再到开源编辑器，以及数以万计的从后端到前端的开源库，几乎每个人的技术堆栈都会使用开源软件。

20年前，我们并没有全栈工程师这样的概念。数据库开发、后端开发和前端开发都是独立的学科。以前开发Windows应用的程序员需要了解PC的架构、可用内存的大小以及内核中的方法。当时可能有一个叫PDC的东西，而不是我们现在熟悉的Build大会，重点也更多是关于Windows，因为它在当时扮演着更大的角色。而那些Windows开发者需要理解PC的架构、可用内存以及内核中的方法。而如今，多数开发者是为网络应用进行开发，他们不需要深入至硬件层面。

他们基本上假设自己可以在需要的时候启动一个更大的虚拟机。所以软件开发的方式正在不断演变，开发者必须不断提高他们的技能，了解下一次的大变革是什么。学习如何使用AI和新的模型，管理这些工具以满足客户的信任期望，这已经成为全栈工程师技能集合的一部分。现在不再仅仅局限于前端和后端开发，还包括对模型的使用。我们在GitHub和微软都不认为未来只有一个单一的模型。会有多个模型用于不同的应用场景。比如代码补全功能，你已经提到了，它使用快速且低延迟的模型。对于Agent来说，延迟就没有那么重要了，因为你有更多的时间。Agent调用工具，因此模型需要具备强大的工具调用能力。所以，这个领域会不断发展，将会有许多应用程序同时利用多个模型。这就是软件开发的未来，开发者需要随着技术的进步而不断学习和发展。

共建：开源开放如何推动Agent 系统与多模型未来

Matthew Berman：好的，你提到了开源和多模型，也提到了关于开源的一些一般性内容。微软在Satsya的领导下，过去十年中在开源方面有了令人难以置信的转变和采用。你今天做了一个重要的宣布，我一听到就立刻发了推文：GitHub Copilot是开源的！这是怎么考虑的？为什么你们这么做？我们能从这样一个强大的开源项目中期待什么？

Thomas：我们对今天的宣布感到非常兴奋，将Copilot在VS Code中开源。这延续了VS Code作为开源编辑器的悠久历史。事实上，就在上个月，2025年4月，VS Code迎来了10周年纪念。Satsya在主题演讲中提到，在这10年间，VS Code已经发布了超过100次版本更新。几乎每个月都有一个新版本发布。其实只有少数几个月份，团队没有发布新版本。但这是稳定版本的情况。实际上，每个工作日都有VS Code Insider版本发布，我相信周末是不会发布的，至少我没有注意到团队在周末发布。

不仅如此，VS Code团队确实像一个开源项目一样运作。他们所有的规划都是公开的。在VS Code的存储库里，他们会展示下个月的计划。发布说明都是存储库的一部分，文档，甚至博客文章也都在存储库中的一个文件里。因此，过去几个月我们观察并决定，是时候让Copilot本身也开源，并将其整合到VS Code项目中，以继续向开发者生态系统提供他们喜欢的东西。这个举措是针对过去10年一直在使用VS Code、为VS Code做贡献、支持VS Code团队和产品的那些人。

另一个关键点是认识到，在VS Code中为Copilot编写的客户端代码，实际上为那些希望构建AI软件的人提供了很好的学习机会。不管他们是想构建一个VS Code和Copilot的竞争产品，还是想将其集成到自己喜欢的IDE中，或者为他们正在构建的新编辑器开发一个类似Copilot的工具，还是想将其整合到开发者工具栈中的全新东西里，这些代码都可以给予启发。通过MIT许可证，他们能够将Copilot集成到自己的系统中，并使用我们的API，我这里指的是GitHub API和Microsoft API，因为Copilot是建立在Azure AI Foundry之上的，这对我们来说创造了业务价值，而这一点比将Copilot的部分内容保密更重要，因为这些内容最终都会泄露出去。比如，系统提示已经为人所知，而VS Code是用Java编写的，因此逆向工程Copilot并不难。实际上，自从2021年Copilot发布不久之后，就有很多人在博客文章，包括GitHub页面上探讨它是如何工作的以及在幕后如何构建提示的。

因为对于自动完成，你无需写明提示，你只需编写，然后它会收集光标上方、下方、相邻选项卡中的文件信息、系统提示等内容。我们早在开源之前就记录了这一切，因为人们可以轻松地逆向工程Java扩展。所以对我们来说，这感觉是一个顺理成章的路径。我们为此感到非常兴奋，因为我们正在回馈给予我们长期支持的社区。

Matthew Berman：现在，他们实际上可以在微软的全力支持下，将其进行分叉并在此基础上进行构建，尽管之前已经有过泄漏或公开可用的情况。

Thomas：我们都是工程师，能够逆向工程。是的，可以完全分叉并为项目做出贡献。当然，提交一个出色的拉取请求，比如说，“我在Copilot中构建了这个功能，因为我喜欢Copilot，我想回馈社区。”

Matthew Berman：你对看到其他外部开发者所做的工作最感兴趣的是什么？是否有某些功能集或工作流是你希望能被构建到GitHub Copilot中的，而这些可能是微软还没有优先考虑的？

Thomas：哦，还没有能够优先考虑。我们今年及去年已经优先考虑了很多事情，毕竟现在是2025年5月。在这段时间里，已经有接近100个关于Copilot的变更日志。我们正在快速发布新功能。去年底在GitHub Universe大会上，我们宣布了多模型选择，这让我们非常兴奋。因此，一个明显的例子就是将其他模型引入Copilot。我们的团队时间有限，要整合新模型，同时还要进行验证测试和维护等工作，以便为Copilot添加官方支持的模型。

我们提供了"自带密钥"的功能，所以你实际上可以连接到OpenAI、Olama和许多其他东西。这为开发者提供了机会，可以让Copilot与其他模型协作，进行所有的测试，甚至决定将模型托管在Azure AI Foundry上，以便推动模型领域本身的创新。虽然现在有一些大公司在这个领域中占据主导地位，但也有很多初创公司正在崛起。尽管我们喜欢相信科技行业是一个零和游戏，但总会有新的颠覆出现。没有任何一切是固定不变的，状态也尚未稳定，我想我们仍然对Agent模式的发展感到非常兴奋，并且可以在这个领域期待很多创新。今天我们宣布了针对Java和.NET应用的App迁移，这也意味着还有很多其他编程语言没有涵盖。所以，你可以看到，有人可以利用Copilot并扩展Agent模式，提供从COBOL到Java或从Perl到Python的迁移。有很多技术债务问题尚未解决，不可能涵盖世界上的所有场景。其次，就是通过查看Agent模式，理解其工作机制。也许有人有更好的想法，知道如何更好地应用这些更改，或者有一个想法，可以确保当修改出错时，他们总是能够回滚一两步。因此，在许多较小的用户体验功能上，开发者常常有自己对某事物运作方式的想法，并与他们在VS Code项目中进行开放对话，允许他们分叉、贡献回去，或者保持以开源分叉的形式运行。我希望这就是我们对VS Code未来的期望。

Matthew Berman：让我们继续讨论未来的话题。谈谈软件的未来吧。确定性代码、传统软件与非确定性生成部分之间的界限变得越来越模糊。首先，您对此有什么看法？您认为未来的软件架构状态会是什么样的？这条界限会如何移动？

Thomas：代码希望总是具有确定性的，因为从设计上讲，代码本身就是CPU指令集的抽象。但你所说的是，我用来生成代码的提示可能会因为模型自身的非确定性而导致不同的代码，即使是使用相同的模型也是如此。我想象未来的软件工程师将需要能够在这两个抽象层之间切换：一个是自然语言的非确定性层。在团队中与其他工程师、产品经理或设计师互动时，总有可能出现对未来该如何构建的误解。在多人共同开发软件项目时，本质上就有可能产生非确定性的结果。世界上没有一个公司，即便像GitHub这样有3000名员工的公司，我作为CEO描述我对一个功能的愿景，三个月后，团队返回并完全按照我的愿景构建出该功能，这并不现实。因为人类有自己的想法，他们会将我所说的内容转换成已有的计划，映射到其他客户的反馈上，也许会进行竞争研究，或者意识到我描述的方案实际上行不通，我们需要做些不同的东西。

而当我们与模型和编程语言一起工作时，同样的道理适用。例如，我向模型描述某个功能，实际上已经有多种方法可以在开始使用Agent模式之前与模型进行头脑风暴，比如让Cloud 3.7与我一起进行功能规范的讨论，并告诉它产品经理给我的需求文档，然后说：“看看我的代码库，我该如何实现这一点？”然后，它会利用开源库代码来帮你先写规范，而不是直接写代码，比如以项目符号的形式写一个Markdown文件。接着，你可能会选择第一个项目符号和其下面的三个子项目符号，将其输入到Agent模式中，先构建那个功能。这其实就是工程的意义所在。你把一个非常复杂的问题分解成更小的模块，就像乐高积木或乐高积木组一样。然后，你知道在某个点上，复杂性降低到模型可以以更加确定性的方式实现它，也就是更接近你预期的方式，你不必之后再去修改。但这里的关键部分是，作为工程师，他们必须知道什么时候该使用模型，什么时候该自己动手。当规范过于复杂时，模型可能只会生成垃圾。就像一些简单的场景，你给它一个任务，比如构建GitHub，模型可能会帮你生成一个页面，但肯定无法构建出GitHub的所有功能。或者它可能会直接告诉你，它无法做到这一点，你需要提供更具体的信息，或者告诉你它们将如何处理这个问题。当工程师达到一个合适的复杂度水平时，模型实际上能比他们自己更快地完成任务。

Matthew Berman：好的。像这样理解了确定性和非确定性之间的区别，最终都归结为确定性代码，但也许存在一个未来，您告诉我整个操作系统实际上是在实时生成的。您认为这在遥远的未来可能实现吗？或者如果可能的话，大概是什么样的时间线？

Matthew Berman：我一定会和我的孩子一起做那个。

Thomas：这的确是一个很好的练习，其实可以让孩子们学会编程。而其中的妙处在于，当你因为时间不够需要回去工作或者去做其他事情，比如园艺时，他们可以继续进行。因为所有的编程都是自然语言，它可以是英语、德语、汉语等多种语言。孩子们真的很擅长探索世界，并且有很强的探索动力，而往往是父母出了问题，比方说没耐心了，天黑了，或者没答案了。当我学习编程时，我家的所有人没有一个会编程，所以我没地方问问题。我那时只有书籍和杂志，没有网络。在今天的世界，只要你有任一种连接和一部智能手机，你就可以问任何与你一起并肩作战的助手任何有关编程的问题，它会帮助你减少很多挫折感，并在你能够进化自己的软件的时候，正如你可以通过那些图像生成器生成小狗的图像一样。

终点：在“vibe”和Agent之间寻找开发的理想状态

Matthew Berman：好的，我想换个话题。GitHub宣布推出了编码Agents。我相信你听说过vibe coding。我想了解一下编码Agents作为vibe coding的基础层和促进者的作用。你对编码Agents有什么看法？对于在开发中稍微放手，不必看到或理解所有代码，而是与AI协作以获得所需结果的这种方式，你有什么看法呢？

Thomas：我不认为这件事是关于“放手方向盘”的问题。事实上，这更像是你在决定一个时刻，比如说，“我是不是该让这辆车启动驾驶辅助系统”。当然，如果你没法更好地完成这个动作，系统也不会帮你完成。但如今大多数的驾驶辅助系统其实仍然要求你手握方向盘，因为这是一种优势——系统知道它并不完美，所以它会把责任保留在驾驶者身上。当然，Vamel是一个相反的例子，但Vamel目前只在某些城市中有效。要真正达到理想状态，我们还需要一些时间。未来我们确实会走到那一步：Agent能够在明确的范围内构建完整应用，而你可能甚至无需查看代码。但我始终认为，在绝大多数软件项目中，你还是需要理解和处理代码的。毕竟，大多数软件开发，其实都是在维护和改进别人已经写好的东西。即使在初创公司也是这样，比如两个创始人在最初六个月内完成了产品的第一版，但接下来他们就会开始招人。新加入的工程师就需要在现有的代码基础上继续工作。我们很少有从零开始、完全自由开发的机会。即使你真的拥有这种机会，当你回头看一年前写的代码，可能也会感到羞耻——因为你在过去一年里学到了更多，现在知道了更好的实现方式。如果你回头看五年前、十年前写的东西，那感觉可能更糟。所以，软件开发的“匠心”不会被wipe coding所取代，它只会被支持、被增强。

从我的角度来看，wipe coding和coding Agents的兴起，背后其实有两个关键原因。工程特别是软件开发，始终都围绕着一个核心命题：我有一个想法，我希望尽快把它变成现实。但现实中常常是这样：我有了想法，开始查资料、找库、研究怎么实现它。到了晚上，我项目才刚刚搭建好，基本还什么都不能做，只是出现了三个按钮。然后我心想：如果我接下来三个月持续开发，也许能接近我早上设想的目标。所以人们心中的梦想一直是：我有一个点子，我能有多快将它变为现实？过程中不需要被各种样板代码、复杂性、环境配置问题所困扰，比如“为什么我本地的 Python 又跑不起来了”之类的问题。正是wipe coding发挥巨大作用的地方——你只需要把自己的想法输入进去，它就能帮你生成一些内容，而且通常看起来会比你自己在短时间内做出来的还要好。你可以持续“vibe”，不断迭代，构建出原型。这正是wipe coding最强的价值所在：原型开发。

但另一方面，在真正的软件项目中，就需要coding Agent的介入了。因为你仍然得考虑安全漏洞、代码质量、团队设定的编码规范、性能目标等等。你不能随意消耗CPU或GPU，特别是当你所在的团队有预算限制时。这种限制在不同团队中表现不同——有些团队有较长的盈利窗口期，有些则短得多，但不管怎样，你在为某个商业目的而构建软件。所以你就需要一个“严肃的Agent”，就像一个工程师向你提交拉取请求一样，它会向你提出代码方案，而你来进行审查。你会运行code review Agent、执行 CI/CD流程，确保测试通过。这不再是vibe coding，而更接近我们所说的Agentic DevOps：在一个成熟的软件开发流程中引入Agent的协助。这个过程中，我会把我不想做的那些工作交给Agent，比如修bug、找安全漏洞、写测试用例。在我的那些兴趣项目里，我几乎不写测试——不是因为我写的代码完美，而是因为写测试太无聊了。而且它并不会让我更快实现自己的想法。所以，把这些繁琐的事情交给Agent来处理，而我可以在本地“进入vibe模式”专注创作，这才是理想状态——你能花更多时间写你想写的代码，而那些不那么有趣但又不可或缺的事情，就交给不同的Agent去完成。

Matthew Berman：有些人联系我，他们从来没有写过一行代码，还有我团队里的几个人——他们现在正在开发应用程序。而且这些应用是真正能在他们生活中产生价值的。但在某个阶段，AI Agent就会开始有些“失灵”，而这并不是因为代码行数达到了某个明确的阈值，而是它自然而然地开始跟不上了。现在看来，我们似乎正处在一个临界点，AI真的快要能够vibe code更大型的代码库了。你认为，为了提升coding Agents的能力，最有杠杆作用的改进会是什么？

Thomas：你看，其实零代码这件事已经存在有一段时间了。早在我们拥有AI之前，我们就已经在赋能一些人，尤其是IT专业人士，甚至普通用户去构建网页、小应用，解决一些业务逻辑问题。当时这些东西不是靠AI构建的，而是通过模板、可定制模板来实现的。但核心理念其实是一样的：就是在不了解代码的情况下，也能走完一段开发旅程，在某个框架下完成一些构建工作。现在AI把这个可能性极大地拓展了。AI如今所能生成的内容，即使完全不懂代码，也能做到的事情，真的是非常惊人。但同时你也会发现，很多人在这个过程中也会走到一个节点——也就是Agent再也无法帮助他们迈出下一步的时候。到了这一步，你至少需要对系统有一定的理解，比如说：一个系统是如何架构的，如何从支持100个用户扩展到支持1万个用户？又或者说，如何引入身份服务提供商来实现身份验证？这些都是Agent目前还难以应对的。

未来Agent会变得更强大，但与此同时，我们人类也会提出更复杂的想法。我非常确信，大多数有志于开发软件的人，总会有比手头工具更宏大的想法和愿景。工具永远追不上创意。唯一的问题是：我们如何把这些创意扩展到足以触碰到那些工具的边界。现实是，在我见过的几乎所有软件公司里，他们都有一个“无止境的待办事项列表”。我自己也一样。虽然说不上真的是“无限”，但它已经长到让我明白——以我们现在所拥有的工具，加上我们的开发人员、产品经理、设计师等团队成员，这个待办事项列表是我这辈子都完成不了的。而在这些待办事项列表之外，还有各种各样的其他问题，比如技术债务、合规性问题、数据存储位置要求、无障碍访问标准等等，这些标准在持续演进。还有总是层出不穷的新设备、新操作系统，还有我们正在用的一些早就过时的开源库。我们永远不会缺活干。

我梦想有一天，只要打个响指，所有合规性的待办事项列表就能瞬间清零，所有问题都得到解决。如果能做到这点，我会直接宣布胜利：AI Agent真的让软件开发发生了翻天覆地的变化。但即使那一刻到来，我们仍然还会有许多待办事项列表，是关于“我们到底要实现什么”的——我们仍然需要人类之间的讨论：团队要怎么做？这个功能将来在产品中扮演什么角色？我们要怎么命名它？等等。这些还是需要人类共同参与。Agent会持续在这个旅程中帮助我们。借助它们的力量，我们将能把更多想法变成现实。

Matthew Berman：我很高兴你提到了这一点。我自己对人工智能的未来也是极度乐观的。我真心相信，当我们拥有“无限智能”的时候，并不是说人类会被取代，软件工程师会被取代，而是我们将能够解决更多的问题。比如你说的那些待办事项，以前我们每天只能完成其中的一小部分，而现在我们可以完成更多。就像制作人Alex说的，这简直就像是软件工程领域的Jevon悖论——你能构建得越多，你就会想构建更多。所以这真的非常有趣。我们已经看到AI编码出现了很多不同的形态。GitHub现在有自己的coding Agent。我们见过自动补全、VS Code的各种fork、插件，还有完全“免手动”的Agent和AI助手。那这些不同类型的AI编程辅助工具，最终会融合成一种统一的交互方式吗？还是说，它们始终会保持某种程度的碎片化，我们根据不同的使用场景去选择最合适的工具？

Thomas：两者都有。从一个角度来说，作为科技行业的一员，我们总是倾向于设想存在某种统一的组织层，所有东西都能整合在一起。但现实情况是，系统太多了，公司太多了，商业利益也五花八门。尽管从某种角度看，一个能包办一切的单一Agent听起来很理想，甚至可以代替我的工作，但现实是，我们永远都会有多个Agent。比如，你车里的那个东西——"Hey Mercedes"。我并不认为 “Hey Mercedes” 会和我的GitHub Copilot是同一个AI Agent。但我看到的是，这些不同的AI Agent是可以互相连接的。其实我们已经有了实现这种连接的工具，比如用GitHub登录，系统之间的数据虽然不是完全打通，但GitHub现在已经可以和JFrog Artifactory连接了，或者与Vercel连接，然后你就可以把你的GitHub仓库通过Next.js部署到Vercel 的云平台上了。

在开发者领域，我们已经实现了系统与系统之间的集成。我也可以想象这样一个世界，你有一个个人Agent，它贯穿你整个个人生活，也许从高中开始一直到退休。它了解你的一切——你去过的旅行、拍过的照片。它很可能已经与你的手机有某种集成，因为你的手机本身就包含大量相关信息。所以当你问它“今晚吃什么”、“接下来读什么书”、“最近有什么值得一看的节目”时，它就能给出推荐。与此同时，你还有一个 工作 Agent，它来自你的雇主，拥有公司级的知识体系，了解代码库、GitHub，能帮助你完成在公司里作为知识工作者的各种任务。我可以想象一个未来世界，在那里，你的个人Agent和工作Agent是可以互相连接的。所以，当你在一家公司工作时，你会有一个统一的界面来使用这些Agent。而当你离职——我们每个人总会在某个时点离开公司——你就可以断开这些连接。这样，那些属于你工作内容的知识就随公司一同保留，而那些属于你个人生活的部分，则继续保留在你的个人Agent 中。当然，这其中肯定会有交叉。比如，像这段对话，到底是属于我的工作，还是我的个人生活？这种边界并不总是清晰的。很可能会有一些智能 Agent来辅助判断：哪些内容是公司的知识产权，哪些内容可以保留在我的个人Agent中。

此外，你可能还有一个旅行Agent，或者是基于任务的Agent，比如由旅游公司或航空公司提供的Agent，帮助你预订行程。这些Agent的数据可能会通过Agent-to-Agent协议传递到你的个人Agent或工作Agent中。谷歌已经在做Agent-to-Agent通信，还有像MCP这样的技术，它们都可以接入你使用的各种工具。未来一定会出现一个Agent生态系统，而且希望这些Agent之间都是可以互联的。最初，它们可能只是运行在操作系统上的多个app，但理想的情况是，它们都采用统一的、基于语言的用户界面。这样你就不需要自己在不同上下文之间频繁切换了。毕竟，现实生活中，工作与个人生活、出差与私人旅行等，其实往往没有那么泾渭分明，就像很多雇主所设想的那样。

Thomas：我相信将会有一些工作，也就是说，一些原本由人类完成的任务，现在模型已经可以自动执行了。翻译就是一个这样的例子。尤其是，如果你有两个人彼此不会说对方的语言，我可以想象这样一个世界：我们只需要戴上耳机，然后我说德语、你说英语，而你听到的是我用英语说话，我听到的是你用德语说话。这样我们之间就不再需要一个翻译来传达我们说的话。所以在某些场景下，确实会需要更少的人来完成工作。与此同时，还会出现一整类由AI帮助创造的新工作。这种转变正在发生。而且实际上如果我们回过头来看“Co-pilot”的出现，它为地球上任何一个想成为软件开发者的人打开了巨大的空间。你不再需要查阅文档，也不需要家人中有能回答你问题的人，尤其是当你还是个孩子时，你甚至不需要会英语了。就像你自己提到的，你只需要创建一个小应用，然后通过提示语不断迭代它。所以我们会看到越来越多的公司利用AI来处理那些在二十年前难以想象的用例。这应该让我们有信心——即便现在某些人从事的工作由于AI而不再存在，他们也会通过AI的帮助重新学习技能，找到新的工作，也许那些工作甚至更有趣、更有创造性。

在工业革命、个人计算机的时代，这样的事情已经发生过很多次了。某些工作被自动化取代，比如软件行业中的用户界面测试就是一个例子。在微软，过去曾有一个专门的测试工程师职位。所以当时有工程师、产品经理和测试人员。而后来测试这个角色消失了，因为没人想再手动测试软件.大家宁愿写自动化测试来完成这个任务。所以我们替代了测试员这个角色。但很多测试人员后来转型成了工程师或产品经理。这是一个很好的例子，我想这就是我能给你的信心：如果你回顾过去的技术发展历程，你会发现每当技术替代了一些岗位，我们总能为那些人找到新的机会。我相信在AI时代，这也同样适用。

Matthew Berman：Thomas，非常感谢你。这次谈话非常有趣，我感到非常荣幸。

原文章：GitHub CEO predicts the future of programming...(Full Interview)

https://www.youtube.com/watch?v=3WNukz5-Ch0

编译：Li Jiahui