这是我与 Zed 的三位联合创始人 Nathan、Max 和 Antonio 的第五次对话。你可以在这里阅读前一次的对话。
这次我不得不提到房间里的大象：AI。我想知道每位创始人是如何接触到 AI 的，他们今天如何使用它，以及他们希望如何使用它。我们还讨论了 Zed 中当前 AI 功能实现的细节，以及今年 AI 将为 Zed 带来什么。我还不得不问：在 AI 时代构建编辑器是否无视了时代的标志？
以下是长达一小时对话的编辑后的文字记录。我尽量保留了意图和意义，同时摆脱了嗯、像、你知道、停顿以及构成深入对话的修正。
（你可以在我们的 YouTube 频道上观看完整的对话。）
Thorsten：你是什么时候开始使用 AI 进行编程的？还记得吗？
Nathan：我很早就开始使用了。我认为我第一次真正令人大开眼界的经历是 ChatGPT 刚推出时，用它来做一些非常基本的事情。我想我在里面定义了几何图形，比如一个几何图形库，但只是为了好玩。我惊讶于我甚至可以做那些非常基本的事情，比如定义一个点、一个圆和一个面积函数，以及它当时正在做的所有这些事情。从那时起，事情变得更加复杂，但这对我来说就像一个令人震惊的时刻。
Thorsten：是令人震惊还是你持怀疑态度？
Nathan：令人震惊。我不理解很多程序员对 AI 的普遍厌恶和怀疑。
我记得在大学里，我学习了自然语言处理，毕业后就为我的教授工作。他是 SRI 的负责人，从事经典的 AI 研究，Jerry Hobbs。我记得我当时对什么是意义？什么是语言？它是如何运作的？以及研究这些组合的、分类的语法机制非常着迷，我们把语法定义为这种定向的 lambda 演算形式，你知道，我对所有这些都非常好奇和着迷，但也感到沮丧，因为当时……语言模型是最愚蠢的东西。它基于标记的频率或其他东西，你无法从中获得任何东西。
所以，我只要坐在那里，用英语要求它做任何事情，它就能做任何事情的想法让我震惊。就在那里，就在那一刻。这太棒了。这是一个奇迹，我从来没有预料到它会这么好。所以，为什么每个人都没有被这个事实所震撼，我无法理解。这让我有点生气，人们对此如此封闭。就像，是的，你把一辆兰博基尼开到我的车道上，但我不喜欢它的颜色。
这只是对消极和错误的以及它不能做什么的执着，而不是对它能做什么感到惊讶和震撼。我想这只是我和那些人之间性格上的差异。我总是看到杯子半满，我总是看到令人兴奋的东西。现在，我从来没有买过一个 NFT，对吧？只是为了说清楚。所以我知道，在技术领域，我们有这些炒作周期，这可能会让人有点疲惫，你会对最新的炒作周期感到翻白眼，你 Twitter 时间轴上的人都在用大写字母谈论着它是如何改变一切，以及具有颠覆性。但我认为在这种情况下，我们拥有这项技术实际上非常了不起。好吧，我不说了。
Thorsten：有趣的是你提到了自然语言处理，因为我来自栅栏的另一边。我学习了哲学和语言哲学。然后当 ChatGPT 出现时，每个人都说它不“理解”。我坐在那里想着：什么是“理解”？你是如何理解事物的？什么是意义？所以，我在栅栏的另一边，也认为事情并没有那么容易，这超级迷人。
Antonio：我紧接着使用了 ChatGPT——我不知道，我认为 Nathan 提示我们使用它。我不是一个 AI 怀疑论者，我感到惊讶，我也使用 AI 来做非编码任务——但我从来没有过令人大开眼界的经历，我不知道。
我经常遇到的一个问题是，我每天都在做什么。我每天花几个小时编写代码，我用 Rust 在这个相当复杂的代码库中编写代码。所以我的第一个用例是在我们的代码库中使用它。而且每次我尝试这样做时，总会有一些摩擦。
但我非常喜欢的一件事是，我认为它真正发光的地方在于生成复杂的代码片段。基本上，代码中存在某些模式，对吧？但你无法用正则表达式或使用 Cmd-D 来设置多光标来表达这些模式，但 AI 非常擅长。你可以直接说“好吧，我想将这个重构应用于这五个函数”，我可以以一种我无法用任何类似 regex 的工具来解释的方式来解释它。这里有很多有趣的潜力。
Thorsten：听起来有点失望。
Antonio：是的。我不知道它是否见过足够多的 Rust。也许这是一个问题。但也可能存在我们如何与它集成的问题，对吧？我们没有给它足够的上下文。我认为仅仅提供正确的...我最近才开始了解到，创建上下文至关重要。
你真的需要正确地表达它。机器真的需要理解你想要做什么。特别是在一个复杂的代码库中，你脑海中可能有 50 个引用，但机器无法知道。它怎么知道？所以，是的，我的部分失望仅仅在于与 AI 的集成，而不是工具本身，而是像，
Nathan：我们还没有到那一步，是的。
Max：是的，在 Zed 代码库中使用 Copilot（我有时仍然会这样做，但我不会称之为改变游戏规则的事情）和在某个 JavaScript 脚本中使用它之间的区别很大，该脚本是一个单文件，所有上下文都在那里，脚本的工作是通过减少步骤来最小化随机测试失败，并且它需要读取一堆文件并调用一些 shell 命令等等。在后一种情况下，即单个 JavaScript 文件，Copilot 表现得非常出色。
因此，如果我们可以让它在我们日常工作中使用，当我们在一个数十万行的代码库上工作时，那里有很多潜力。
Thorsten：这是我在我们的代码库中使用聊天助手时注意到的。我经常想，“哦，如果你能看到嵌入提示，如果你能看到类型，那么你就不会给我这个答案了。”但是的，集成。
Nathan：再说一次，这也是我们的失败。我最成功的时候是我把模型训练数据中已经存在的东西组合在一起的时候。我喜欢那种模式。
我编写的许多 GPUI2 的渲染器都是纯粹从助手面板中生成的，我说“嘿，我需要一个与 Metal API 集成的渲染器。它是用 Rust 编写的。”它并不完美，但它比我自己配置所有这些图形管道要快得多。这不是我做过很多的事情。
我喜欢从这些模型中的一个的潜在空间中提取我需要的东西，我提供了一些参数，但主要是权重。但我正在引导权重给我一些像 StackOverflow-on-acid 这样的东西，知识就在那里。我只需要它以某种形状存在，并且我想引导它。
所以这个周末我在浴缸里玩 Claude，对吧？我实际上写了一个完整的文件索引，它使用无锁映射来存储文件路径，解释了从 FS 事件 API 出来的所有 FS 事件。它异步地完成了所有事情。你知道，我为它编写了随机测试，有一个虚假的文件系统实现，我当时正在浴缸里，对吧，在我的手机上。我没有一刻是在编写花括号。现在，我从来没有运行它生成的东西，但我用眼睛审查了它，虽然它可能在这里或那里有一些问题，但它是对 Antonio、Max 和我花费了无数天的时间来完成的事情的一个非常合理的实现。我之前解决过这个问题的事实帮助我引导了它，但我不知道，它几乎以某种方式改变了你可以快速完成的事情的规模。
然后有时它会彻底失败。对于最简单的事情。
Thorsten：ChatGPT 是 2022 年 11 月推出的，对吧？当时我们都应该购买 NVIDIA 的股票。从那时起，你是否调整了对 AI 的适应以及你使用它的方式？例如，使用 Copilot 的人说他们适应了它，并且会留下一些注释来引导 Copilot。或者你们中有人曾经涉足过整个提示工程的事情吗？或者在弄清楚它可以做什么和不能做什么之后，你是否减少了使用它的次数？
Nathan：不值得一提的是，我真的不使用 Copilot。我发现它很烦人。它就在我面前。我也从来没有想过在保存时自动运行测试。我总是想……我不知道。我更喜欢以聊天的方式与 AI 互动。所以我非常期待我们即将投入的时间，以更多地了解那个上下文窗口。
我只是觉得 Copilot 有点蠢。我不知道。因为他们必须能够在每次击键时调用它，他们必须使用一个更笨的模型。所以我想我只是更喜欢使用一个更聪明的模型，但更慎重地使用它。但我并不执着于这种观点。我认为对 Copilot 进行一些 UX 调整可能会改变我的关系，但我不知道。我想我一直愿意使用它，甚至让我的互动有时会更慢或更无效，以投资和学习如何使用它。
是的，比如当时它帮我解决了一些非常困难的事情，比如编写一个过程宏，或者枚举 GPUI 的所有 Tailwind 类。它有点像教我如何编写 过程宏，因为我之前根本不会。
Thorsten: 大约一年前，我在一个会议上，和一些程序员朋友见面，我们都在谈论 ChatGPT，有些人说：“哦，它什么都不懂。我刚刚试了一下，它什么都不懂。” 但是他们使用的查询或提示，看起来就像 20 年前人们使用 Google 的提示一样。那时你还在用关键词搜索，人们会输入“哪里可以买到热狗？” 但当时不是那样工作的。不过，我有个朋友说：“你知道我用它来做什么吗？ 我把它当成助手来用。 我把它当成实习生来用。” 基本上，当他在调试某个东西，需要一个小程序来重现这个 bug 时，他会对 AI 说：“你能帮我写一个小 HTTP 服务器，不设置连接超时吗？” 因为他知道它的缺点在哪里。 我认为过去一年，我们很多人都有这种感觉，我们开始感觉到它的缺点在哪里，并调整我们对它的使用。 所以我很好奇你是否有过类似的时刻。
Max: 我在日常生活中经常使用 ChatGPT 代替 Google。我学会了说，“现在，不要说‘视情况而定’。 我知道。 直接告诉我，给我一个答案”，这样 ChatGPT 就不会说“对此有很多可能的答案。”
但我认为关于在编程世界中如何使用它，我还有很多要学习。 可能有很多我还没有应用到我的工作流程中的知识，关于如何提示这个助手。
Nathan: 我认为我的优势在于我没有 Max 或 Antonio 那么擅长编程。很多时候，当我配对编程时，我在互动中更多地扮演领航员的角色。所以我更多地求助于 AI，因为我写代码的速度不够快。所以我认为这对我来说没那么令人沮丧。
Thorsten: 你什么时候决定“我们必须把这个添加到 Zed 中”？ 是被炒作所席卷，每个人都在要求它，还是有什么具体的事情或时间让你说“不，我需要在编辑器中加入这个。”
Nathan: 对我来说，有 Copilot，还有 Assistant。 所以每个人都在要求 Copilot。 我当时想：“哦，我想看看用它工作是什么感觉”。 但最后我并没有经常使用它。 但对于另一个， Assistant 来说，是因为我在使用 GPT4，他们对我的使用进行了速率限制。 所以我只能进入 SDK 或 Playground，在一个该死的网页浏览器中编写文本。 我当时想，这太让我抓狂了。 我想在 Zed 中编写文本。
而且，我的意思是，这就是 Assistant 现在的作用。 它有点像一个骨架。 它就像一个 API，几乎就像一个 OpenAI API 请求编辑器，一个从文本编辑角度来看不那么烦人的编辑器。 这就是目前的情况，但这并不是它应该保持的状态。 我们还有很多工作要做，这就是我的思路。
Thorsten: 我想深入了解一下 Zed 中的内联助手。 给正在观看、收听或阅读的人提供一些背景信息：你可以在 Zed 中选择文本，然后点击 ctrl-enter，你发送一条消息以及选定的文本和一些更多的上下文到 AI，你可以要求它“更改此处的返回类型”或“重新排序此代码”或“使用宏”等等。 然后，当请求从 AI 返回时，你可以看到它键入文本或更改文本，你可以看到它逐字逐句地更改。 看起来不像是仅仅将文本推入缓冲区。 所以我很好奇，当 LLM 请求返回并说，这里有一段代码时，会发生什么？
Antonio: 基本上，我们实现了 Needleman-Wunsch 算法的自定义版本。 有几种模糊查找的算法，它们都源于这种动态编程算法，这种算法本质上是寻找从 A 点（原点，即两个字符串的起点）到终点（两个字符串的终点）的最低成本路径。 所以我们有点像在做这个差异（diff），流式差异（streaming diff），因为通常差异（diff）是一个有损函数，你需要有完整的文本，但问题是 AI 以块为单位流式传输响应。 但我们不想等待整个响应返回后再进行差异（diff）。 所以我们有点像对 Needleman 进行了轻微的修改，我们尝试优先考虑插入和删除，我们稍微向前看一点，并使用不同的成本函数。 这使我们能够产生这些流式编辑。 这是一个非常有趣的项目。
Thorsten: 那么你是专门为内联助手构建的这个吗？ 我还以为这段代码也被用于协作功能，不是吗？
Antonio: 不是。 实际上我们最初尝试的是让 AI 使用函数调用来给我们编辑，而不是要求 AI 给出响应，然后 AI 从上到下地吐出结果。 最初的尝试是这样的：“好的，只需给我们你想要我们应用的精确编辑”。 但是我们很早就发现它不能非常可靠地工作。 要让它产生精确的位置是很棘手的。
它非常擅长理解你作为一个整体想要做什么，但很难让它说，“好的，在第 3 行第 2 列，我想插入、删除 5 个字符，然后插入另外 6 个字符”。
所以我们回到了绘图板，我们说它擅长吐出文本，所以我们就让它写出你想要的东西，这就是 Nathan 的想法的由来。
Nathan: 还有 Antonio 在算法方面的实力让它成为了现实。 是的。
Thorsten: 它非常可靠，对吧？
Antonio: 谢谢。 是的。
Nathan: 有时它会过度绘制。 它……我不知道。 对我来说并不总是可靠的。 我认为这与我们的提示方式有关。 这里有很多需要探索的地方。 我会要求它为一个函数编写文档，然后它会重写这个函数。 这让我很抓狂。
Thorsten: 提示方式，当然，但实际的文本插入——每次我看到这些词亮起来，我就想，这是怎么回事？ 他们是怎么做到的？ 实现这个花了多长时间？ 我很好奇。
Antonio: 半天。 是的，我记得是一天。 是的，差不多。
Thorsten: 不可能吧。
Nathan: 但公平地说，我们已经做了很多探索，只需要一点动力来完成路径匹配。 这花了一点时间，我们绞尽脑汁地思考。 我认为更多的是你理解了，Antonio，可以说。
Antonio: 哈哈哈！
Nathan: 因为，是的，遍历那个动态编程矩阵仍然让我有点困惑。
Thorsten: 半天——你可以说一个星期，只是为了让我感觉好一点。
Antonio: 一个星期，是的，一个星期，不。
Max: 哈哈哈。
Thorsten: 所以现在在 Zed 中，我们有内联助手，我们有聊天助手，你可以用它来编写 Markdown，你可以与多个模型进行对话。 接下来是什么？ 未来有什么计划？
Nathan: 一个重要的部分是让助手看到更多的上下文。 从一个 API 客户端过渡到开始引入更多的上下文。 与我们合作的 Kyle 有一个分支，我们正在引入当前文件。 显然，我们想要更多的机制来引入上下文，不仅是当前文件，还有所有打开的文件，你可以拨入上下文，选择加入或退出，等等。
但也要进行工具调用，我可以与助手对话，让它帮助我构建我的上下文，如果这有意义的话。 还要让它与语言服务器交互，还要使用 tree-sitter 来对我们引入的文件的依赖项进行排序，以便我们确保所有这些都在上下文窗口中。 当然，上下文大小已经增加了很多，这让一切都变得容易得多，因为我们可以更贪婪地引入内容。
所以这是一个重要的维度，更智能地填充那个上下文窗口，还要给助手工具调用，让它可以在终端中编写命令。 我不知道我是否想让它能够按下回车键，你知道，但至少把它写出来并暂存，然后将我的焦点转移到那里，这样我就可以运行一些东西。 我可以获得关于我可能想运行的任何随机 bash 命令的帮助。 让助手逃离那个小盒子，接触并与编辑器的其他部分互动。
这些都是非常容易实现的功能。 我认为我们需要选择它们。 这就是我接下来的目标。 而且我们也在尝试其他的完成提供者，以获得 Copilot 风格的体验。 我们会看看结果如何。 目前还处于早期阶段。
Max: 我对功能集的另一个维度感到兴奋。 现在，我们刚才一直在谈论的所有东西，这个系统是非常本地化的。 你选择一段代码，它的输出会定向到那个位置。
但是能够像 Zed 中的代码操作一样，说“将这个函数内联到所有调用者中”，并打开一个多缓冲区，上面写着“我在这里做了更改，我在这里做了更改，我在这里做了更改。 你想保存这些更改还是撤消它们？” 然后我可以去看看它做了什么。
我想能够说，“从中提取出一个不在这个 crate 中的结构体，而是在一个子 crate 中，并在该 crate 的所有这些用法中依赖它，这样他们就不必依赖所有其他的东西”，然后让它去，“在这里，我更改了你的 Cargo.toml，我创建了一个 crate，我更改了这个，我对你的代码库中的各种代码片段进行了这些更复杂的转换。 你想保存这些更改还是撤消它们？”
我认为这将是一种非常强大的方式，让它做更多的事情，同时保持控制。 我认为多缓冲区是一个很好的方式来询问用户“你想应用我刚才做的所有这些转换吗？”
Nathan: 说到多缓冲区，另一个非常容易实现的事情是在多个选择上并行调用模型。 当我调出一个包含大量编译错误的多缓冲区，这些错误基本上都是我需要做的相同的愚蠢操作时，如果能将 LLM 提示并行应用于每一个错误，那就太好了。
Thorsten: 唾手可得的东西到处都是 —— 基本上你可以在每个文本输入框中添加 AI，比如添加自动补全或生成等功能。上周我和一个人聊天，他想在一个项目搜索输入框中使用 LLM 来生成正则表达式。这很酷，但同时，我在想，更好的步骤难道不是拥有一个合适的关键字搜索，而不是让 LLM 翻译成正则表达式吗？我怀疑，是否有可能因为追求唾手可得的东西而陷入局部最优解。
Max: 你的意思是，像正则表达式搜索这样的现有编程工具范例，我们到底还想保留多少？或者说我们是否认为我们甚至不再需要这个功能了？
Thorsten: 类似这样的。一年前，每个人都在每个领域添加 AI，但显然情况发生了变化，人们现在说“这不是一个好的用例”，而且你现在还说你想让它访问文件等等。你是怎么看待这个问题的？你认为下一个重大里程碑是什么？
Nathan: 嗯，我想我有不同的看法。有几件事情我想回应。一是我们在夏天尝试了语义搜索，最初的做法是用 OpenAI 的 embedding API 生成所有这些 embeddings，它是为文本和散文设计的。我认为它不太适合代码，至少我的理解是这样，也许人们可以在 YouTube 视频下评论告诉我我错了。所以我不知道 embedding 模型在代码方面总体表现如何，但我发现，通过这个最初的实验，你只要开始输入你的查询，我们就会向你展示匹配的文件，或者像文件和行号。我一直在大量使用它进行导航，因为它能够快速输入按键，非常有用。
它比模糊查找器更好，也比语言服务器上的符号搜索 cmd-t 更好。因为至少在我们的代码库上使用 rust-analyzer 可能会非常慢。所以我把它当作一种快速、便捷的导航工具。
但后来我没有深入参与，我们把那个原型模式体验转化成了搜索的一个功能。然后我就不再使用它了，因为使用它的摩擦太大了。而且至少当时我们得到的结果质量还不够高。我想回到那个状态，恢复那种使用语义快速跳转到不同区域的模式模糊导航体验。但它不像搜索结果，更像是快速跳转。
我想说的另一件事是，我有点怀疑……在我被证明是错的之前，我一直对 AI 持怀疑态度。所以我想谨慎地对待可以做的事情的可能性。但是，总的来说，我现在的想法是，我仍然想看到正在发生的事情。我不希望背后发生很多事情，比如它写一个正则表达式然后运行它，因为我没有足够的信心它会运行良好。
所以在获得这种信心之前，我喜欢这种非常可见的混合体验。AI 正在帮助我使用算法化的传统工具。甚至 OpenAI 也有代码解释器，对吧？他们没有试图让 LLM 添加数字，而是直接 shell 调用 Python。所以我认为让 AI 访问这些更算法化的传统工具是我想要的方向。
Thorsten: 你对上下文窗口有什么看法？当你有一个大的上下文窗口时，你可能会认为所有的问题都解决了，对吧？直接把整个代码库塞进去。但是你也必须上传大量的代码，并且需要更长的时间才能得到回复。你对上下文大小和延迟之间的权衡有什么看法？
Nathan: 我仍然在思考上下文大小增加时，是什么导致了额外的延迟。在我对 Transformer 的 mental model 中，我不明白为什么需要更长的时间，但我实际上可以看到它确实需要更长时间。所以，是的，我想，我在这里暴露了我的无知。
但在我看来，提供一切可能意味着提供太多，反而会让人感到困惑。虽然我的理解是这种情况也在改善，它们现在越来越不容易被噪音和大海捞针问题所迷惑。我从 Gemini 那里看到了这一点，我仍然在等待获得我的 API 访问权限。但我看到的是，它非常擅长从大量的垃圾信息中挑选出重要的细节。
我不知道，这并不是一个非常连贯的想法，只是在我看来，我们需要考虑如何管理上下文一段时间。而且我与模型交互并且最成功的时刻，要么是我再次从模型的权重、潜空间中提取信息，并且上下文窗口中几乎不需要任何信息，因为我要解决的问题有点像存在于以太坊中。或者我真的为它设置了成功所需的特定事物。
但公平地说，我认为我们在这个领域还有很多东西要学习。是的。
Thorsten: 我问这个问题是因为你说你在触手可及的时候使用了模糊搜索，但是一旦有更多的摩擦，你就停止使用它了。我注意到，说到大的上下文窗口，我有时已经对等待 ChatGPT 感到不耐烦了。“拜托，跳过介绍，给我干货。”对于大的上下文窗口，我想知道我是否宁愿跳过提问，因为我知道答案需要 20 秒、10 秒或更长时间才能返回。
Nathan: 是的，我认为延迟越高，我对它回应的期望就越高。我的意思是，我只是在浴缸里度过了一段美好的时光，同时等待 Claude 的回应。我深吸一口气，感受着身体上的温暖水，你知道，然后当它回应时，我就读它。
Thorsten: 我认为你应该用一个对照组重做这个实验，这个对照组也在浴缸里写代码，但没有 AI。也许结果是一样的。听起来像一个很棒的浴缸。让我问一些有争议的问题……当我说我要加入 Zed 时，人们问我，“哦，一个文本编辑器？两年后我们甚至需要写代码吗，有了 AI？”你对此有什么看法？你认为五年后我们仍然会在 Zed 中输入编程语言语法吗，还是你认为我们编程的方式将发生根本性的改变？
Nathan: 是的，这是一个好问题。我的意思是，我发推文说，具有讽刺意味的是，一旦 AI 能够为我编写代码编辑器，我就不需要代码编辑器了。但到目前为止，还不可能坐下来，说，用 Rust 编写一个代码编辑器，使用 GPU 加速图形。我不知道。我不认为 AI 已经达到了那个水平。
也许这是唯一足够复杂的产品。也许 AI 唯一无法构建的是代码编辑器，但我现在持怀疑态度。也许 Ray Kurzweil 是对的，我们都会像上传我们的大脑到云端一样，我不知道。我只知道事情变化很快，但现在看来，至少我想要监督访问权限，就像那个 Devon 演示 一样。
对我来说，一个可能的结果是，编辑代码最终会让人感觉像 Devon 演示一样，但具有惊人的 UX，让人类程序员参与到这个循环中，指导这个过程，这样我们就不会仅仅用蛮力尝试来狂轰滥炸 LLM。相反，LLM 获得访问权限，而人类参与者必须纠正或指导它，从而形成这种反馈循环。是的，它变成了这种人类 LLM 协作，但人类仍然参与其中。
如果最终不是这样，是的，我想我们不再需要代码编辑器了。我不知道那一天有多远，如果它真的会到来。
他们长期以来一直告诉我，我将乘坐自动驾驶出租车，我已经乘坐过几次了。但我要说的是，出租车拒绝停在我们实际在旧金山的地方。所以我们不得不冒着倾盆大雨走到他们接我们的地方。我的脑子都要爆炸了，一辆车自动驾驶着我，接我并把我送到其他地方，但与此同时，我有点生气，因为我正在冒着雨走到它停靠的地方。这感觉有点像 LLM 发生的事情，对吧？
谁知道会发生什么，但就目前而言，我喜欢创建软件。我不需要自己输入代码，但我确实觉得我想更多地参与其中，而不仅仅是坐在 Google 搜索框前，然后说，去成为一个代码编辑器吧。
Max: 我看好代码在未来很长一段时间内仍然是一件事。我认为这可以追溯到 Nathan 所说的，AI 扩展了你可以构建的东西的集合，在更短的时间内，它使探索更大的想法空间变得更容易，因为它更便宜。
我认为会有一些代码不再需要任何人来编写，但那些代码无论如何都很无聊。
但我认为它只会使更多的代码成为可能，因为维护它更便宜，创建它更便宜，如果我们需要新版本，重写它也更便宜。会有各种以前不可能的事情。比如现在，银行无法提供好的网站，我认为有一天银行可以拥有一个好的网站。会有一些软件，由于某种原因，现在无法交付。最终将可以交付。我认为这将是代码，我仍然会想偶尔看看它。
Nathan: 是的，银行拥有一个好的网站是在我们实现 AGI 的前一天，这真是对人类激励的力量和银行系统腐败的令人难以置信的评论。
Max: 哈哈哈哈。
Antonio: 如果你现在看看 Twitter，就会发现每个帖子都在说 AGI 将在下个月发布。我不知道。我真的不知道。对我来说，诚实的答案是我不知道。这有可能。这是我对 AI 感到恼火的一件事，这些事情中的一些事情太不透明了。
过去，对于一般的技术，如果存在难题或复杂的事情，我可以坐下来，至少尝试理解它们，甚至可以创建它们。对于 AI，除非你想用 ChatGPT 或 Claude 做一些事情，否则你必须花费数百万美元。我不喜欢这一点。
我的怀疑就来自这里，因为这些公司的工程师和研究人员很可能已经接近 AGI，已经接近超人类智能，但有多少是炒作呢？我不知道。
Thorsten: 我很想听听你们对一个问题的看法。我经常使用 ChatGPT 来做编程的“琐事”，比如一些 CSS 或 JavaScript，或者用它生成一个 Python 脚本来与 Google API 交互。这能帮我省去一整天查找 OAuth token 应该放在哪里的麻烦。但对于更底层的编程，比如 async Rust，你会发现它开始不行了。你会发现某些事情对于 AI 来说相对容易，但另一些事情就有些困难。我想知道这是否是规模的问题？是因为它见过的 JavaScript 比系统 Rust 代码更多？是因为它抓取了整个互联网吗？
Max: 我认为解决那些已经被多次解决，只需要稍作调整的问题，LLM 这样做非常好。那些都是很无聊的事情，因为它们已经被解决了很多次，我认为 LLM 非常擅长解决这些问题。我们所做的一些事情，虽然也不能说每天都在做前所未有的事情，但很多时候我们日常做的事情，在世界上并没有被解决过很多次。这很有趣，这也是我喜欢做这件事的原因。所以，LLM 不能完全为我完成这些工作，我并不感到沮丧。但当我做一些非常标准的事情时，我很高兴 LLM 可以直接完成，直接解决它。
Nathan: 我希望 LLM 能够尽可能多地为我完成工作。但是的，我确实认为它还没有见过很多 Rust 代码。我的意思是，我和这个领域的人聊过，他们也这么说。比如他们很兴奋，“哦，你们要开源 Zed 了？我很高兴能获得更多的 Rust 训练数据。” 我也会说，“我也是”，除了，你知道的，竞争对手直接坐下来，然后说，“给我做一个快速的代码编辑器”，然后它就已经学会了如何做到这一点，而我们所做的一切都白费了。我不知道。
但即使真是这样，最终我还是对推动人类进步感到兴奋。所以如果我正在做的事情最终变得无关紧要，也许我应该去做其他事情。我的意思是，那会让人失望，我希望能够成功……总之，我不知道我是怎么扯到那里的。
但是用它写 Python 代码，我并不想写，但我需要写，因为我想看看帧时间的直方图并比较它们？谢谢。我不想写那些，而它做得很好，我很满意。
Antonio: 还有一个更宏观的观点，我想我们并没有真正讨论过。即使在 AI 能够生成代码编辑器的世界里，在某个时候你还是必须决定你希望这个功能如何工作？我想 AI 也可以在这方面帮助你，但我猜还是需要人来指导它，理解需求是什么，以及你到底想做什么，对吗？
也许在某个时候，AGI 也会消除这一点，但我不知道。归根结底，代码只是想法的表达，是的，以及公司或一群人内部的知识。
我很高兴 AI 在协作方面的应用。我认为这将是 Zed 作为协作平台的一个非常好的角度。
我们已经讨论过查询 tree-sitter 来获取特定函数或语言服务器来获取引用的问题，这些都是你可以提供给 AI 的一些上下文。但是发生的那些对话呢？比如——回到我们的之前的采访——如果代码真的是所有发生过的对话的提炼版本，那么对于 AI 来说，这将是帮助你编写代码的绝佳上下文。
Nathan: 我们可以使用语音转文本模型或多模态模型来捕获这些上下文。
我的真正梦想是创建一个 Max 或 Antonio 的 AI 模拟——GPtonio，你知道吗？我喜欢和他们一起编写代码，因为它让我可以在很多时候以更高的抽象层次进行思考。我不知道，也许我只是太懒了。我应该多打字，但有时我觉得当我打字时，我成了阻碍。我只是喜欢结对编程，喜欢成为导航者并参与其中。所以，一个可以和我说话并编写代码的多模态模型，可以听到我说什么。我也可以参与其中，时不时地在这里和那里打字。那将是太棒了。但这与协作不同。
但它会通过观察我们协作来学习。这是我的主要想法。你知道，是的。
Thorsten: 你可以根据 Antonio 过去一年所做的所有编辑来训练 AI。以及所有的对话。
Antonio: 是的，这些编辑为什么会发生？背后的原因是什么？为什么这样做比那样做更好？什么是内部知识，那些没有写下来的隐含知识？我们拥有这些知识仅仅是因为共享的上下文。仅仅是将这些上下文与 AI 共享。
Nathan: 当我们开始做 Zed 的时候，我们一直有这样一个想法，如果我可以把光标放在一个字符上，然后说，给我看看写这个字符的过程，那岂不是很酷？这个想法是，所有的对话和上下文都与这些代码相关联，我们可以存储它并使其易于访问。但即使是那种模式，仍然需要梳理很多东西，对吧？因此，拥有一个能够很好地提炼这些信息并以智能方式呈现的工具，这太棒了。这对协作来说是一个非常令人兴奋的进展，它可以将我们可能捕获但尚未真正捕获的所有这些数据，以一种新的方式带到我们的指尖。
Thorsten: 最后一个问题，展望未来。你知道 Andy Warhol 是怎么评价 Coca-Cola 的吗？他认为可口可乐的伟大之处在于，无论是总统喝还是你喝，它都是一样的，没有高级可口可乐和普通可口可乐之分，每个人都喝到一样的。对我来说，编程也是如此。我可以和世界上最好的人在线编写代码，而且在 GitHub 上看起来完全一样。我的头像在他们的头像旁边。这是一个公平的竞争环境。我可以把我的网站放在网上，它也是 thorstenball.com，与大型公司的网站并列。没有专属俱乐部。我一直在思考的是，你只需要一台电脑就可以编程，即使是 Raspberry Pi 也足够了。但是现在有了 AI 和 LLM，事情突然变得非常昂贵。要玩 AI 游戏，你需要大量的金钱或 GPU。你们是否考虑过这一点？你们是否看到了这种转变？或者你们认为，如果你想要拥有一个数百万用户的可扩展的 Web 服务，你就一直需要有钱？
Antonio: 也许只是因为我们现在的技术还没有达到那个水平，所以硬件成本才会这么高，对吧？CPU 的价格已经变得便宜很多了，现在有这么多 CPU。所以，我可以看到一个世界，在这个世界里，东西变得非常便宜，以至于它们变成了一种商品。
Nathan: 想想 70 年代末，对吧？Ken Thompson 和 Dennis Ritchie，在电传打字机上编写 Unix，连接到一台占据我房间天花板的 PDP11 上。谈谈访问计算的民主化。情况并非总是如此。似乎我们正处于一个时代，在这个时代里，计算不再是长期以来限制创新的因素。但也许现在又回到了过去，谁知道未来会怎样。
Thorsten: 太好了。真棒。