谷歌Keith Ballinger谈AI编码：工具尚早期，需清晰指南和架构。未来编程将更抽象，开发者可能无需直接接触代码，重点是意图。优秀程序员亦是优秀作家。
译自：Stop Writing Code, Start Writing Docs
作者：Frederic Lardinois
在本期《The New Stack Agents》节目中，TNS 出版商 Alex Williams 和我与 Keith Ballinger 进行了交谈，他是 Google Cloud Platform 开发者体验部门的副总裁兼总经理。
Ballinger 是少数仍经常编写代码的高管之一，他也深入参与了最新智能代理编码工具的构建和使用。不出所料，我们花了一些时间讨论了 Gemini CLI，它是 Google 的产品，直接与 Claude Code 和 Gemini 的 Codex 等产品竞争，也是 Ballinger 目前负责的关键产品之一。
但也许更有趣的是他对如何充分利用这些智能代理工具的看法，Ballinger 认为这些工具仍处于“起步阶段”。在他看来，放慢速度以加快进程很重要：开发人员应该为智能代理编写清晰的指南，专注于架构（并记录下来），并制定项目计划。
他说，开发人员常常仍然尝试一蹴而就的方法，但这无法为模型提供足够的关于开发人员意图以及他们旨在解决的问题的整体背景信息。
Ballinger 还认为，从长远来看，我们可能会达到这样一种境地：大多数开发人员根本不需要查看代码。编程语言的历史就是不断抽象的历史。他告诉我们，下一个抽象层“本质上是我的意图——我想要什么，以及如何将这些意图组合起来创造一种体验，创造一个应用程序。”
他承认这有点争议，而且他通常持有的“非常乐观的观点可能属于少数派”。
请查看上面的完整对话，其中包括 Keith 在 Microsoft、Xamarin 和 GitHub 的职业生涯，他用于指导智能代理的 Conductor 框架，以及为什么优秀的程序员也是优秀的作家。您还可以通过订阅我们在 YouTube 或其他播客平台上的播客来观看更多 Agents 节目。
以下是我们对话的一些亮点，为求清晰度略作编辑。
AI 编码的早期阶段
Alex Williams: 我当时问 Keith 你是如何真正开始使用 AI 的。你在录制前提到，很多人不知道如何使用它，他们以一种非常“一杆进洞”的方式使用它。你现在对此有什么体会？给我们讲讲你刚开始时的早期情况。
Keith Ballinger: 是的，这很有趣。虽然我一直从事开发工具和技术方面的工作，但青少年时期我曾是 Marvin Minsky 的电子邮件笔友。所以，我很小的时候就对 AI 产生了浓厚兴趣。大约在 2012 年，我为 Bayes Hack 组建了一个黑客团队，为非营利组织进行机器学习。所以我一直对这个领域非常感兴趣。[编者注：Bayes Hack 是 Bayes Impact 的黑客马拉松。]
后来在 GitHub，我们开始构建 Copilot。当时的想法是，OpenAI 出现并最终拥有了一个相当不错的模型，有趣的是，他们当时称之为 Codex，如果你仔细管理它，它就能很好地完成编码任务。我们做的第一件事纯粹是代码补全。很快就有了聊天功能。有趣的是，我认为从代码补全开始，从非常交互性的东西开始，对于理解人们如何使用 AI 并让他们对此感到有点舒适非常有用。
接着人们开始使用聊天功能。即使在今天，有些人也会去 ChatGPT 或 Gemini 进行 AI 编码。当然，智能代理也随之而来，对吗？突然之间，模型开始代表你使用工具做事情。这是我们行业一个非常有趣的增长。
我一直关注着它。我记得大约去年年中，使用工具的模型开始真正流行起来。你想到像 Cursor 这样的人，突然之间它们能够有所突破，因为它们不仅仅是代码补全，也不仅仅是聊天。突然之间，它们开始使用工具为你完成这些半自主任务。
这很有趣，因为在那之前的一年左右，我只使用聊天功能。所以我会去 Gemini——当时我们称之为 Bard——告诉它我想做什么，然后它会返回并给我代码，我就会把代码复制粘贴到我的项目中。
但它也会告诉我做其他事情，比如运行测试并将测试结果输出给它。我基本上是在为 Gemini，也就是模型本身充当工具。一旦这个过程自动化，你就能突然快很多地完成任务，这真的扩展了你能做的事情。
使用智能代理编码工具的最佳实践
Ballinger: 我目前在行业中看到的一件事是，人们对什么是最佳实践，甚至对最佳实践应该是什么，存在很大的差异。我认为我们必须在这方面进行更多教育，以帮助人们理解如何使用 AI 进行编码辅助。
因为如果你只是“一杆进洞”，你不会真正成功。你必须把 AI 当作同事。如果你遵循通用的开发最佳实践——比如编写用户指南或规范，编写技术设计，创建项目计划——仅仅这三件事，如果你在与 AI 交互时这样做（对任何复杂事物你都应该这样做），你实际上会从 AI 获得非常好的结果。
Frederic Lardinois: 我一直在思考这个问题：它仍然非常冗长，我们看到类似的项目，其中包含 agents.md 文件。你认为这仅仅是当前通往不同方向的一个中间步骤，将来我们就不需要再这样做了吗？
Ballinger: 我不确定。我希望不是。我想我喜欢创造事物。我喜欢成为一名工匠并创造事物，我想参与其中。我不一定想写每一行代码并调试每一个测试失败或其他什么，但我喜欢创造的行为。
对我来说，创造的行为是思考我想解决的问题，然后思考我想如何解决它。我认为 AI 也许也能做到这一点，但你仍然面临一个问题：“作为 AI，或者作为人类，我如何在没有 AI 的情况下，给你足够的我想要的东西？”
你必须以某种方式做到这一点。它无法读懂你的心思，至少目前还不能。如果它无法读懂你的心思，那么你就无法获得你想要的。我希望参与到那个部分。
保持智能代理正常运行
Williams: 那么你如何确保它正常工作呢？通常情况下，当你输入一个提示，然后得到提示的输出，再将其应用到你的开发环境中时，它的效果并不好。那么你是如何验证一切的呢？
Ballinger: 我做这件事的方式是利用 AI 来帮助我。所以我不会查看每一行代码。对于像 Aether 这样的东西 [编者注：Aether 是 Ballinger 作为实验创建的一种 LLM 编程语言]，我创建了那个架构文档。
我与它进行了大量协作。任务计划非常详细，在每个任务之后，我基本上让它像测试驱动开发一样工作——就像 TDD。它会编写测试，然后实现功能，直到测试通过。
我确实花时间查看了这些。我看了很多测试，但大部分时间可能都花在看示例上。我必须创建大量示例，涵盖各种场景——文件 I/O、HTTP、简单的内存管理等方面——我确保这些示例总是能运行。
所以在完成任何任务后，我会确保示例运行，所有测试通过，我也会确保 AI 正在做这些事情。在某种程度上，对我来说它是一个黑盒子。
我真正关心的只是，最终它是否奏效了？有时，我也会随便检查一下。
CLI 的复兴
Lardinois: 你认为为什么 CLI 最近又变得如此流行？目前几乎所有这些智能代理都某种程度上拥有 CLI 版本。这是为什么？
Ballinger: 我认为，老实说，我们从未放弃过终端。我想这是原因之一。我们没有把终端视为主要界面。越来越多的人会去终端运行像 npm 或其他命令，比如 ls 之类的。但我们没有把它看作是我们的主要界面。
越来越多地，曾经有一个丰富的 TUI（终端用户界面）生态系统，比如 Midnight Commander，对吗？
Williams: 我足够老，还记得。
Ballinger: 是的，没错。这很有趣——我们只是不再考虑那些，而只是使用命令行脚本。但我们总是使用终端，尤其是在现代开发中，特别是在有如此多的[开源软件]的情况下，人们使用终端进行 git 操作。
所以使用终端来做这些事情是非常自然的。它给了你很多控制权。它专注于要完成的工作，而不是大量的 UI。它让你专注于你需要做的事情。它只是顺应你正在做或已经做的事情。
Williams: 正如 Frederic 指出的那样，CLI 在 AI 世界中现在是一个有趣的话题。我很好奇你如何看待终端本身的发展。我的意思是，Gemini CLI 将 AI 直接带入其中，不是吗？
Ballinger: 是的，我认为这是一个非常有趣的问题：终端本身会演变为更具 AI 能力，还是其中只会出现越来越多具备 AI 能力或受 AI 影响的命令行工具？
一年前，我构建了一个 kubectl 的原型。我为它构建了一个名为 kubectl AI 的扩展。团队重写了它——我的代码很糟糕——但它现在是 kubectl 核心的一部分。你可以给它一个自然语言查询，然后 kubectl 可以用它做事情，比如“现在有哪些节点正在宕机”，等等。这是我们可能会看到事情发生的一个地方——越来越多的工具这样做。
我们可以看到的另一件事是终端本身变得更具 AI 和代理能力。Warp 就是一个例子。此外，今天最常见的 shell（脱离终端）是 BASH 和 zsh。我一直在思考的一个问题——我之前做了一个原型，我的团队又做了一个更好的原型——就是，我们能否创建一个 AI 感知型 shell？
这些都是交互的方式，对吧？就像你可以有一个桌面应用，它能理解事物并与你交互，或者一个网页。我的猜测是，所有这些事情都可能会发生，因为它们都有有趣的用例。
编程语言的未来
Williams: 说得通。我对编程语言再次感到好奇。我们谈论终端的演变时，有很多与终端相关的事物也在演变。有了生成式 AI，你可以利用机器帮助你生成正确的代码。但是我们对代码本身的看法是否发生了转变？与此同时，你如何看待新编程语言的演变？
Ballinger: 这是一个引人入胜的问题，因为我认为对此存在各种各样的观点，没有人能确定。我通常持一种非常乐观的观点，这可能属于少数派。但 Aether 当然就是其中一个例子。
我认为我们应该构建为 LLM 设计的编程语言，在其中，我们可以说永远不会去查看它们。我认为我们可以达到这样一种境地，作为开发人员，我不再处理代码行。我处理的是系统设计、架构、用户界面以及所有这些类型的事情。我将它们精心组合在一起，但底层的实际语言对我来说只是一个黑盒子。
对我来说，这感觉就像是抽象的自然演进。我们最初从打孔卡开始，本质上是机器码。然后我们有了像 C 这样的语言，它们在汇编器等之上提供了一层薄薄的抽象。接着我们转向了越来越抽象的语言，比如 Java 或 C#，它们继续提升了抽象级别。
下一个抽象层本质上是我的意图，我想要什么，以及如何将这些意图组合起来创造一种体验，创造一个应用程序。在这种情况下，我认为你不一定需要代码。
当然，我一直认为会有一些人，他们的技艺就是代码，他们喜欢逐行编写代码。老实说，在代码编写的某些领域，他们可能在很长一段时间内都拥有竞争优势。那是他们所享受的。我希望他们享受它。但我认为我们将达到这样一个阶段，我们不会再看到那么多这样的情况。再次声明，这肯定是有争议的观点。
不久前我读到一篇论文，讲的是有人让两个智能代理相互通信，随着时间的推移，它们开始相互发送乱码，因为它们即时协商出了一种高度紧凑的语言来进行交流。这类事情对我来说很着迷。我很想看看它会走向何方。
Lardinois: 那么那个抽象层，默认情况下是自然语言吗？还是某种元编程语言？因为你想要一定程度的精确性，对吗？而自然语言并非如此——至少英语在这方面并不总是擅长。
Ballinger: 是的，我的意思是，这是一个我最终不知道答案的问题。我曾经有点反自然语言。我感觉会有其他比自然语言更精确的与 AI 交互的隐喻。
但随着我在这个领域工作的时间越来越长，我有点觉得，当你阅读一本教科书或任何非虚构小说时，我们不会担心所写内容的精确性。没有人会说：“嗯，那本微积分教科书不精确。”我们觉得它非常精确。当然，也有一些模糊的糟糕写作，但我认为在自然语言写作和文档中，有太多精确的例子。
我认为你必须某种程度上迎合人们现有的水平，对吧？人们可以学习其他语法，一些正式的语法，让他们与 AI 对话；或者一些可视化的东西，让他们与 AI 交流。但那样我们就是要求人们学习新东西并做新事情。我认为你会有越来越多的证据表明——[人们应该] 只需具备出色的写作技能，并善于分解问题和理解设计，对吧？
设计模式已经存在很长时间了，它们总是被证明非常有用，而且不仅仅是在编码中。建筑师也使用设计模式。我认为这正是我们想要达到的目标——让我们帮助人们成为越来越好的作家和越来越好的问题解决者，这又回到了问题的分解上。
Lardinois: 是的，这是一种不同的技能，与有时程序员今天所拥有的技能不同。
Ballinger: 我认为并非如此。我认为一位优秀的程序员也是一位优秀的作家。他们会写下他们要做什么。他们记录问题、解决方案、解决方案的选项、设计以及所有这些东西。我认为优秀的程序员都会这样做。
他们当然理解——他们能够很好地从业务问题转变为技术解决方案。理解需求是什么，理解什么是可能的，将其分解成小块，以便他们能够根据需要进行迭代和调整。我认为这些正是智能代理编码世界所需的精确技能。而且，也许，或者也许不需要，编写代码行的能力在未来不再是那么重要的了。
