[BidClub_]
Latent Space · · 44 分钟

⚡ Google Labs 内部:打造 Gemini Coding Agent——Jed Borovik、Jules 与 AIE CODE Preview

Jed Borovik

YouTube
TL;DR
  • Jules 为这样一个未来而打造:代码代理在专属云电脑上运行数小时甚至数天,而不只是待在 IDE 里提供辅助。 Borovik 最具代表性的表述是:「所谓自主,就是它有自己的电脑」(“autonomous means, like, it has its own computer”);Google 正在为可批量复制、远程触发并最终成为环境基础设施的代理设计产品。

  • Borovik 描述了 Labs 产品团队、DeepMind 模型、内部开发工具与使用数据之间反馈闭环所形成的优势。 他所说的是一套贯穿端到端的系统,从“页面上的像素”一路延伸到基础设施、模型和训练;同时,编码的价值既在于“AGI 视角”,也在于“美元视角”。

  • 基础模型持续进步,正逐步降低对复杂代理脚手架的需求。 早期 Gemini 版本需要复杂的子代理和编排,如今 Borovik 的结论是“少即是多”,脚手架越来越像是弥补模型能力缺口的拐杖。谈到 RAG,主持人认为语义搜索应只是工具之一,不应成为系统唯一的组织原则;Borovik 认同基于 embedding 的 RAG 并非唯一方案,并表示 Google 正在积极研究这一领域。

  • Jules 正在成为一款长期产品,而一则关于30天会话的轶事,则揭示了用户可能持续多久使用同一条代码代理工作流。 Jules 在 I/O 后的5月发布公告获得市场反馈,成为其产品化的转折点;它出现在 GitHub 主题演讲中,也强化了 Borovik“它当然会长期存在”(“certainly here to stay”)的判断。另一个案例中,主持人团队原以为没人会让单个会话持续30天,直到第一位用户触达会话数据上限、会话被锁定后情绪激烈。

  • 分发路径覆盖 API、CLI、GitHub 工作流,最终还会延伸到更广泛的 Gemini 产品面。 一位用户触发 Jules 更新网站,再通过 GitHub Action 自动合并其 pull request,说明代理可以完全嵌入工作流基础设施。Borovik 表示,刚刚发布的 Jules CLI 到节目上线时就会与 Gemini CLI 集成。

  • 主持人认为,垂直代理业务在经济上比通用代理基础设施更容易跑通;Borovik 则认为软件需求会扩张,而不是就业简单坍塌。 主持人称代理公司似乎在“桶里捞鱼”(“shooting fish in a barrel”),ARR 增长更快、利润率更高,但也明确承认,出色的基础设施公司依然可能胜出。Borovik 对劳动力悲观论的反驳是需求弹性:如果工程师的生产力提升50%、100%甚至10x,更多软件项目就可能值得投入。

  • 当代理连续工作数周、吞入文件和海量命令输出时,关键不再是原始上下文窗口有多大,而是如何管理上下文。 即使上下文窗口达到200万 tokens,也可能仍然不够;摘要、外部笔记和子代理交接都会带来信息传递难题。主持人对本地到云端连续性的初步答案,不是转移脑状态,而是转移产物:「我不会把脑状态转给你,我只告诉你我做了什么。」

  • 粗放式 vibe coding 的继任者,必须同时解决规格定义和结果验证。 主持人将问题拆成两部分:明确想要什么,以及验证结果是否符合预期。规范驱动开发可以改善提示词,但也可能变成一场50页的瀑布式工程;交互式规划则承认,用户往往要在反馈中才发现自己真正想要什么。Borovik 将图像描述为另一种输入模式,主持人希望加入视频来处理具有时间维度的 UI bug;双方还讨论了把 computer use 作为超越聊天界面的下一层交互。

摘要 · 为研究而整理的核心内容

1. Stable Diffusion 让一位资深 Googler 转向代码代理

  • 在 Google 工作9年、其中大部分时间负责 Search 的新鲜度与新闻业务后,Borovik 将自己的 AI 转向归因于 Stable Diffusion,而不是 ChatGPT。艺术家在“这在偷我的作品”和把它当作“创作更好艺术的工具”之间分化;他很快意识到,编程也面临同样的选择。

  • 当人们开始劝大学生不要学计算机科学时,Borovik 的反应带有强烈个人色彩:“这是我的 Stable Diffusion 时刻。”AI 可以拿走“我的艺术、我的手艺”,也可以成为制作更好软件的工具;他有意选择了后者,最终加入 Jules。

  • Google Labs 的使命,是打造“Google 其他部门不适合做的新型、创新产品”。它本质上是产品组织,但与 DeepMind 紧密协作,覆盖从界面像素、基础设施到模型训练的完整闭环。

  • Google 早已发表过关于编码辅助的研究,并围绕内部 IDE Cider 建立了内部能力。Borovik 强调,将自研模型与异常丰富的使用数据结合,能够把过去只能留在内部的复杂系统推向更广泛的产品。

2. Jules 假定自主代理终将离开 IDE

  • 核心问题不是复制现有编码助手,而是模型能力提升后代理将走向哪里:“那就为那个未来打造。”如果代理能够连续数小时甚至数天处理复杂工作,Borovik 认为它应该拥有自己的环境,而不是占据开发者的本地工作区。

  • 自主只是第一层;团队还希望 Jules 变得“无处不在”。它的 API 可以让事件在开发者无需打开聊天窗口的情况下发起任务,其中一个工作流就是由 Jules 更新网站,再由 GitHub Action 自动合并生成的 pull request。

  • 产品正在开发者已有的工作界面之间扩散。录制前几周,Jules 已发布专用 CLI;Borovik 表示,到节目上线时它将与 Gemini CLI 集成。API 负责远程触发,CLI 则服务于已经在本地工作的开发者。

3. 更强的模型让更薄的代理框架成为可能

  • Borovik 最明确的工程经验是:模型质量会改变能构建什么,也会改变系统需要多少编排。早期 Gemini 模型需要“极其复杂”的脚手架;随着模型进步,架构开始简化,因为“脚手架几乎就是拐杖”,用来弥补模型本身缺失的能力。

  • 团队曾为编辑、子问题、集成、审查等不同角色分别配置代理。Borovik 并未声称如今的 harness 已经不复杂,但他发现,更少的刚性组件更容易维护和改进,既能靠常规工程,也能靠机器学习:“少即是多”(“Less is more”)。

  • 基于 embedding 的 RAG 也引发了类似反思。主持人的反驳异常明确:任意切分的 chunk 意味着检索作为唯一机制“永远不会好”,因为捕捉到一种语义关系的 chunk 可能遗漏另一种关系;大上下文注意力则可以避免把这一瓶颈硬编码进系统。

  • 两人都没有彻底否定语义检索。主持人仍然主张把它与文件访问、grep 和网络结合使用,而不是“做事的唯一方式”;Borovik 表示认同,并称 Google 仍在持续研究这一领域。主持人还说,在向他人推荐过几种代码 embedding 模型后,他所在团队发现自己并不需要它们。

4. 随着采用率和曝光度上升,Jules 从实验走向产品

  • Borovik 表示,Jules 从一开始就计划做成真正的产品,但 I/O 后5月的公告才是决定性节点:积极反馈推动团队将其打造为长期产品。它在 GitHub 主题演讲中被提及,也强化了内部判断——“它当然会长期存在”。

  • 主持人给出了另一种市场判断:太多有能力的开发者在构建框架,因为开发者工具让人感到熟悉,却没有真正想清楚客户或垂直场景。他认为,垂直代理的 ARR 增长更快、利润率更高,像是“桶里捞鱼”;但他也承认,杰出的基础设施公司依然能够成功。

  • 两人谈到 AI Engineer Code 时,将会议描述为行业转型期间的中立集合点:行业正从学术论文和开放研究,转向产品、创业公司和闭源模型。主持人估计,即将举行的峰会大约每23名申请者录取1人,并表示最重要的是“走廊轨道”,因为演讲内容会免费发布。

  • 这种“走廊轨道”也延伸到正式议程之外:上一场纽约活动促成了约15场参与者自发组织的晚餐和聚会。主持人的建议是,带上一张简洁的名片,说明你在做什么、能提供什么帮助、需要什么帮助,然后围绕语音、代码审查代理、金融或生物学等细分主题组织聚会。

5. 30天会话上限将上下文变成研究前沿

  • 主持人分享了一则代码代理轶事:他的团队只保存30天的会话数据。他们当时认定:“不可能有人会使用同一个会话30天”;但第一位触达这一上限的用户在会话被锁定后非常不满,说明一条连贯的代理工作流可以持续很久。

  • 代码代理在上下文方面承受的压力尤其大,因为它们会在持续数周运行时吸收文件、命令输出和大量对话轮次。即使拥有最高200万 tokens 的上下文窗口,问题也不会消失,这使编码既成为影响巨大的产品类别,也成为要求极高的研究环境。

  • 可用手段包括摘要、把状态外置到笔记中,以及将边界清晰的工作交给不必携带父线程全部上下文的子代理。每种方法都会制造保真度问题——“如何确保足够的信息来回传递?”——而两人也指出,最佳方案可能会随着模型变化而变化。

  • 主持人没有读过比较各种方法效果的论文,Borovik 则称这是一个正在进行中的研究主题,无法展开细节。实践尚未定型之所以重要,是因为长期运行的代码代理会话已经开始挑战它们最初的设计假设。

6. 持久化交接可能是 pull request,而不是对话

  • 新的产品界面正在变得清晰:IDE、VS Code 扩展、CLI 和云端代理。尚未解决的问题是,这些模式在开发者从本地开始、异步委派任务、之后又需要恢复深度工作时如何互通,而不必重放整段代理历史。

  • 主持人最初设想在不同工具之间“传送”对话,随后改变了自己的答案。可转移的单元可能是 Linear ticket、GitHub pull request 或简洁的状态更新:“我不会把脑状态转给你,我只告诉你我做了什么”;遗漏的信息则像人类协作一样,在后续过程中才会暴露。

  • Borovik 希望行业先说清楚自己正在创造怎样的体验,而不是把代码代理当成零和竞赛。他向同行提出的问题是:“我们正在创造的这个美好未来是什么?”其中包括本地与云端工作如何衔接,以及软件工程如何变成一种更好的手艺,而不只是更快的生产线。

7. 软件需求可能扩张,但粗放式 vibe coding 已到极限

  • Borovik 提醒,AI 工具在各家公司之间的渗透程度仍低于他有时的预期;但就个人而言,他已经无法想象回到没有辅助的编码状态:“那听起来太糟糕了。”他反对“代理能力提升必然意味着公司停止招聘软件工程师”这一简单判断。

  • 他的解释机制是需求弹性。农业就业之所以崩塌,是因为食品消费存在上限;而更便宜的电力却会带来更多消费。他认为,软件需求具有很高的弹性。

  • 如果一名工程师能够交付原来的50%、100%或10x,过去无法证明投入合理性的项目就可能变得可行。主持人的补充判断是,代理可以吸收商品化工作,理想情况下让工程师有更多空间处理战略性、全新的、高风险和需要深度专注的工作。

  • 主持人认为,“vibe coding”已经变成了随便 YOLO 提示词、产出“能想象到的最糟糕代码”,再把清理工作留给别人的许可。“Agentic coding”是最主要的替代说法,但缺少 vibe coding 的乐趣;理想实践必须重新找回认真、手艺和可靠性。

  • 规范驱动开发提供了一种答案,因为“提示词写得马虎,得到的就会是马虎的结果”;但一份耗时3天、长达50页的规格文档,只是在重演瀑布式开发。主持人更偏好交互式规划:用户往往要等代理做出某个东西、自己进行修正后,才知道真正想要什么。

  • 主持人将可信赖的代理工作概括为两个成对的问题:明确预期结果,以及验证结果是否符合预期。Jules 会在仓库已有测试时运行这些测试,但主持人指出,它不会强制每项改动都新增测试;是否产出测试,应由工程师控制。

  • 规格定义也应超越聊天界面。Jules 已经接受图像输入,主持人希望加入视频来处理具有时间维度的 UI bug;两人都把 computer use 视为下一层能力——让代理渲染并操作 VM 或浏览器,前提是系统能够达到足够的精度、速度和可负担成本。

  • Borovik 邀请热情用户和怀疑者分享自己的工作流、失败经历,以及不使用这些工具的原因。他同时也在招聘,并表示很乐意与有兴趣从事代码代理工作的人交流。

Speaker 1

Okay, Jed Borovik, welcome to Latent Space.

Jed Borovik

Yeah, thanks for having me.

Speaker 1

We're sitting here at Figma's beautiful podcast studios, and we're actually meeting at GitHub Universe. How's it been so far?

Jed Borovik

It's been great. The keynote today was awesome. It was fun to see Jules up there a little bit. We have a lot of folks from our team here. Jules is partnering with GitHub for the new Agent HQ stuff, which we're excited about, and this is an incredible podcast space. I'm excited to do this here.

Speaker 1

I'm glad for them to loan us this space. You're also MC for AI Engineer Code. That's exciting in New York, where you went to college, but you don't live there anymore.

Jed Borovik

I spent a bunch of time in New York. It's funny being part of New York's tech scene. I actually think it's great having big, major conferences there. There's a lot that happens on the West Coast, but being someone in tech on the East Coast, it's awesome to have stuff there.

Speaker 1

You mentioned you fly over to San Francisco a lot. What's the scene like on the East Coast? Obviously, we're pretty new—we're here for our first year coming to New York. What else happens in New York? What are the highlights for you in the New York tech scene?

Jed Borovik

There's so much. There's obviously a ton of great companies. I think the thing that's interesting about New York is that it's such a big city with so much going on. Tech is a huge part of it, but there are also so many major industries there, whether it's media, fashion, or finance. In some ways, I think that helps push the tech and lets people do all kinds of stuff.

The East Coast is a great place. All the schools are spread across the East Coast, with a ton of great schools and great students doing all kinds of stuff. I went to school there. The hackathon scene there was amazing. I really fell in love with tech and programming there.

Speaker 1

Is there a big NYU hackathon, like Stanford with Cal Hacks and stuff?

Jed Borovik

Yeah.

Speaker 1

TreeHacks?

Jed Borovik

Yeah. There's one that was put on by NYU and Columbia. We did it together—HackNYU. There were a bunch of events that we did together, bringing people across New York City—students across New York City—and those were super fun. It'd be the Columbia one one time, then NYU the next, and we'd cycle back and forth. A lot of cool stuff was made there.

Speaker 1

Nice. You've been at Google for a while—9 years. You've worked on a bunch of things, including with Malte, who's also another guest I'm interviewing today. How did you get into Jules? What's the AI journey?

Jed Borovik

This is going to sound really cheesy, but I've told this story a couple of times to folks when they're like, “How did you end up doing this?” It is actually very true. I worked on Search for a long time, specifically news and freshness.

When Stable Diffusion came out, that was the first gen-AI moment for me. I know people talk about ChatGPT as the first thing, but for me, Stable Diffusion—it was a couple of months before ChatGPT came out—was a huge thing. I was following it a ton online, and there were 2 groups of creators having reactions to it.

There was one group of artists and creators saying, “This is stealing my art. This is stealing everything that's near and dear to me. I hate this. This is ruining my life.” And there was another group saying, “This is a tool to create better art.” I was watching this bifurcation.

Speaker 1

Yeah, exactly.

Jed Borovik

Right around then, I was having conversations with a couple of people who would say things like, “If I had a kid in college, I wouldn't recommend they study computer science.” I was like, “What? Why?” This was long before Jensen Huang and people like him had been saying this kind of stuff. I was like, “Whoa, why?”

They'd say, “Oh, AI. Software engineering is going to change. Who knows if there are going to be jobs?” I loved being a software engineer. I love programming, and I was like, “Wait, this is my Stable Diffusion moment. This is either going to take my art, my craft, or this is a tool to create better art.” I definitely knew which path I was taking.

So I got very into building and coding. I was still working on Search, but I spent a bunch of time making stuff in my own time and playing with things. Ultimately, I tried to find the most exciting role I could find to do this stuff, and that was to join Google Labs to work on Jules, where we were starting to build these kinds of coding agents at Google. The timing worked out well, and I joined. It's been awesome.

Speaker 1

Since we're talking about Google Labs, I'm actually unclear about where Google Labs starts, and then the rest of Google, DeepMind, and the rest of Google. What's the org-chart layer?

Jed Borovik

Labs' mission is to build new, innovative products that the rest of Google isn't well-positioned for.

Speaker 1

Yeah, which we've had, like, Riser from Nom[?].

Jed Borovik

Exactly. Exactly. So it's maybe the most widely known, and then Nano Banana. I don't know if it's—

Speaker 1

Yeah. The thing that's really exciting about Labs is that you work incredibly closely with DeepMind.

Jed Borovik

Right. We're building a product, but we work so closely with DeepMind on the model. One of the nice things about being at Google is that you have the opportunity to really build an end-to-end AI product, from the pixels on the page through the infrastructure, the model, the training, and all of that loop.

Labs is here to build new products, and we're really a product organization, but a true AI product organization, where we work incredibly closely with DeepMind, as well as other parts of Google as it makes sense.

Speaker 1

Just on the history of AI coding, I'd heard that Google actually had an internal version of Copilot or something that was never released. Is that true? What can we say about it?

Jed Borovik

I think Google has published papers in this space for a while. In Google, we've built a lot of our own tools, and Cider, which folks may have heard of, is our internal IDE. We've had all kinds of capabilities and tools there for a while. So, yes, we've certainly had pretty good tools for a while, but they were for internal use.

Speaker 1

I think it was interesting because one of the hype moments, when Google started getting into the LLM game—basically when everything rebranded to become Gemini and started pushing out Gemini—people were like, “Oh, did you know that Google's entire repo is probably about the same size as GitHub? There must be some interesting data in there.”

Jed Borovik

Oh, yeah. One of the things in building a lot of these internal systems is that the data is incredible, especially when not only is the model and training in-house, but all the data on usage and everything. We could build really sophisticated things there.

Speaker 1

Okay, let's introduce people to Jules. Your website says, “Jules: autonomous coding agents.” We've seen lots of these. They're not octopuses. They're not purple, so you've got that going for you. What are you really trying to nail at the core in a very crowded coding-agent landscape?

Jed Borovik

What we think about, and what we set out to do back when I joined, was: where are coding agents going to go as these models get more and more powerful and sophisticated, and what is that experience going to be? Let's build for that future. When you think of a really powerful agent that can run for a really long time doing really complicated things, that's when the product started to take shape for us.

For example, autonomous means it has its own computer. For Jules, it's in the cloud, exactly. Tons of agents run locally or in your workspace with you while you're coding, but if you want something that's going to run for hours or, let's say, days, you might want it to have its own environment where it can do its own work.

That's one of the pieces that's important for this autonomous coding agent, but it's really about thinking about this future where they're incredibly powerful. You can spin up tons of them. They're autonomous, but we're also thinking about what it means for them to be ambient. When it has its own infrastructure and its own computer and its own ways to interact with it, how does that start to change what it can do? For example, we have an API, so people are using it for all kinds of things.

Triggering it when something happens—we saw an example where someone is triggering Jules to make all kinds of updates to their site. Then they have a GitHub Action that's going to automatically merge Jules's pull requests. All kinds of stuff is flowing, really changing how people are able to do things.

Speaker 1

And is CLI-related, just to close that loop?

Jed Borovik

Yeah, CLI. We also have a CLI. We want to meet developers where they are, right? An API means you can trigger it from anywhere, but when you're working locally, you want to be able to trigger things, too. We launched the Jules CLI a couple of weeks ago, which lets you interact with it. By the time this podcast comes out, we'll be integrated with the Gemini CLI.

Speaker 1

That's what I was thinking—you have a number of CLIs.

Jed Borovik

Exactly. So, Gemini CLI, all kinds of places where we're going to mix and where you'll be able to harness this power. Developers work in all kinds of places, so we're making it easy to have this autonomous, ambient agent that can do all kinds of work for you.

Speaker 1

What was your journey like when you started? Did you find any assumptions that were quickly challenged when working with Gemini and coding agents in general? I guess you're maybe not too unfamiliar with it, because Search uses a lot of machine-learned, black-box-type systems, including BERT, which was a major update a few years ago. Fill us in: what is your AI engineering journey?

Jed Borovik

Totally. One of the things that keeps coming up is that the model makes such a difference. It may sound obvious, but the quality of the model really changes what you're able to do and how you engineer around it. When we started, we were working with relatively early models of Gemini, and the agent scaffolding around it was incredibly complex.

One of the things we've seen is that scaffolds get simpler and simpler over time as the models get better. In some ways, the scaffolding is almost a crutch for things the model struggles with. For example, we've played with and experimented with really complicated subagent systems.

Speaker 1

Can you give an example of a subagent system that you had to abandon?

Jed Borovik

It was basically like this: you give Jules a coding task, and it's going to have different agents for making a code edit, handling a subproblem, or taking an action with an integration. You might have full subagents for different parts, like a reviewer agent. People sometimes use different personas, where you have a product manager agent and then a code reviewer agent. That cracked me up.

In this video, we didn't go that far. I think a lot of these things aren't as much in favor now. I don't want to say the agent harness isn't sophisticated—it certainly is—but as the models get better, less is more, especially when it comes to improving through machine learning or regular maintenance.

Speaker 1

I think we were talking a little bit before we started recording about RAG, and mixing and matching all of that. It seems like, not just for Jules but across the industry, agent-based search is difficult. Maintaining embeddings is hard, but getting the chunking right is hard, too. In terms of the black-box aspect you mentioned, a lot of that is hard to improve upon.

Jed Borovik

I would even say it's maybe not so much hard as it is something that will never be good. [laughter]

Speaker 1

Why do you say it will never be good?

Jed Borovik

A chunk that happens to capture the thing you're looking for will fail to capture something else. If you only retrieve based on the embeddings of a chunk, you're using very arbitrary boundaries that are drawn with some hope that the semantics will be captured. But you could just throw attention at it. [laughter]

Speaker 1

Totally. You can probably scale much better using GPUs.

Jed Borovik

Totally. [laughter] So I think that's an example of how these harnesses are simplifying.

Speaker 1

I haven't abandoned it completely, because one of the things we were doing—I don't know if you saw the Cognition's SWE work—was basically using semantic search, chunks, and embeddings as a tool, but on the same level as the other tools, like web and file access, grep, and whatever other variants you have. I think that makes sense: don't abandon it; just don't reify it into the only way to do things.

Jed Borovik

Exactly. And to be clear, this is an area of research we're doing tons of work on. I expect that in the coming months, we'll be talking about some of the stuff we're doing here, too. It's not the only way. I feel like when we started, it was embedding-based RAG. It was like the thing everyone did, and it's interesting to see how it's changed.

Speaker 1

People asked me where the good code-embedding models were. I pointed them to a few Chinese ones. Nomic was working on one, and then we found we didn't need them.

Jed Borovik

Yeah. [laughter] Exactly. Exactly.

Speaker 1

Very bitter lesson.

Jed Borovik

Yeah.

Speaker 1

What's that transition like? Is there a process within Google Labs to promote things when you feel like there's some traction?

Jed Borovik

Absolutely. Google Labs isn't just about experiments. NotebookLM, for example—

Speaker 1

It's not a very serious, incredibly successful product that makes money?

Jed Borovik

It's really not just that. For us, Jules was kind of a turning point. In May, when we announced Jules, it received a great reception following I/O. That was a real moment for us to turn this into a very real thing. It was something we always intended to build; it was always a goal to build a real product here.

That was a very key moment and milestone for us. Now it's very much a real thing. As we were talking about before, Jules was mentioned in the GitHub keynote. It's certainly here to stay, and we're excited to keep building and expanding.

Speaker 1

Awesome. Let's talk about coding in general. You're coming to the MCP AI Engineer Code Summit. It'll be your first time at AI Engineer and MCP. What do you want to know?

Jed Borovik

Yeah. Well, tell me why someone would want to come. Let's turn it around.

Speaker 1

Oh boy. This is embarrassing. Fortunately, we're in our third year—fourth year now—and we have a bunch of prior art we can point people to and say, “Look at our YouTube. Do you like that? Do you like this?”

Jed Borovik

There's some great talks. I haven't been before, but I've watched the talks. There's a lot of good stuff.

Speaker 1

I'm proud that it features content from all labs. This is a pattern I've seen across my career: every industry needs focal gathering points to trade tips and share things. I've seen that in JavaScript, cloud-native, and data engineering. I figured AI engineering would need something like this, too.

The concurrent thread was that I went to a bunch of the academic ML conferences, like NeurIPS, and a lot of them are decades old. NeurIPS is 40 years old, and it hasn't really changed. It's very focused on academics and PhD students, whereas I think the transition in AI from research to industry means you gradually see a shift—unfortunately, less open source and fewer papers, and more products, startups, and closed models.

People still want to share. They still want to hire, and they want to promote their work, so they need a place to do that. You can always do that at your company conferences. Obviously, Google has I/O, GitHub has GitHub Universe, and Microsoft has Build and Ignite, but there usually is one industry-neutral place where everyone is on the same playing field.

Honestly, some people like that. It's not like you're going to be treated as a VIP; you kind of have to earn your spot. But when you earn your spot, I think people give it the requisite level of attention, because you had to.

Jed Borovik

Yeah. Of course. So, you know, I’ve watched the videos online. I kind of get a sense of the specifics, but what’s happening beyond that for someone who hasn’t been before? What goes on other than the talks?

Speaker 1

Oh, yeah. A lot of logistical stuff: invoicing, vendor selection, venue selection. Did you know we have 5 different pieces of software to coordinate speaker logistics, room logistics, and attendee logistics? So I’m going to go sit [laughter], but—

Jed Borovik

Yeah, what am I going to get?

Speaker 1

Yeah, yeah. So actually, it’s really weird because I’m the content guy for AI Engineer, right? I curate the speakers I invite. But I actually know that the content is the least important part, because all of it’s filmed and we’re going to edit it and post it for free on YouTube anyway.

But the reason you come is because, one, you can talk to the speakers, but also you can talk to each other. I always say the hallway track is the most important track.

Jed Borovik

Yeah. [laughter] How do you get the most out of the hallway track? What’s your guide to the hallway track?

Speaker 1

I don’t have as collective a set of thoughts as I should. One, I think it helps if you have some prior history of what you’re interested in and what you work on. Basically, the best intro to somebody is if they’ve seen you online before, so they can skip the whole “Who the hell are you?” part and just get into, “Hey, I saw you wrote that thing. Let me talk to you in person about this, since you’re both here.” That’s way better than, “Who are you? What do you do?”

That’s a very cold interaction. Ideally, people come warm, or they can come with some clear idea of, “Here’s why I’m here. Here’s what I’m looking to get out of this.” Because if you show up with no real intention, or if you’re in and out for your thing and nothing else, then you don’t have the space and the mental energy for the unstructured, serendipitous connections.

The thing about—at least at our scale, our size right now, especially for the summits, which is the one that you’re going to—is that everyone had to apply to get in. Usually, our first summit had something like a 10-to-1 applicant-to-invited-spots ratio. This one went up to 16 to 20-something; this one’s going to be 23. So, 1 out of 23 people who apply gets in.

Yeah, it’s a lot. We’re really trying to filter for people who would be speakers at any other conference, but they are the top of the field. They are either founders or, honestly, enterprise buyers of the best companies you can find in New York. That’s another reason for our New York conference: we’re bringing the best of San Francisco tech to the finance sector, really.

There is a little bit of media, but mostly finance. What I’m trying to say, I guess, is that you’re there to meet the other people, so make time to meet them. Have a calling card: Who are you? What do you do? What can you help with? What are you looking for help with? That kind of intro stuff is really good.

Going with friends is really good. Obviously, we actually offer bundle discounts for the AI Engineer World’s Fair. This one, I don’t think we do, but just reach out if you need something.

The idea of getting immersed in the code agent community is really important. We themed it for the first time, too. These used to be generalist events: here’s the state of AI and the best speakers we can get at any point in time. But now we’re really trying to push ourselves to theme everything. We have the best people in code, the best people in datasets, and the best people in RL. I want to do a mech interp one.

Jed Borovik

That’ll be fun.

Speaker 1

That one, I’m thinking, will be in London, because the people I want to target are in London. But, yeah, I think when you do a summit, it should be focused. Everyone there should have an agenda of trying to learn what the state of the art is and trying to have off-the-record conversations with their peers doing the same thing at other companies.

Who knows what could happen? That’s the weirdest thing. I organized a thing, and I don’t even know half the things that go on, just because my job is to provide the nexus of people to connect.

Last time we were in New York, there were maybe 15 side events organized by people—dinners, meetups, whatever—around the summit, and we encourage it. We post it, and we just want people to meet up.

Jed Borovik

Yeah. I was going to ask: is there a whole off-main-stage set of events happening? How do people know?

Speaker 1

Yeah, they organize it. Honestly, if you’re not scared of strangers, you should organize your own little dinner. We leave all the evenings open.

Jed Borovik

Okay.

Speaker 1

Just organize a dinner or a meetup. Focus on your thing. We have people doing only voice, so if you want to do voice, great. If you want to do code review agents, as a small subset of generalist coding agents, do that.

I think you’ll find it, right? Or you can do AI in finance, AI in bio—whatever that particular sector might be. That is honestly the highest-signal way to get a bunch of people who really resonate with your thing to meet and have high-bandwidth conversations.

Jed Borovik

Yeah. Yeah. Are you and I going to do the autonomous coding agent dinner?

Speaker 1

Well, no. [laughter] My job is to float. My job is to handshake, ask how everyone’s doing, and see if I vibe. I tend to just leave myself open until the end.

But, yeah, it’ll be a sprint. It’s always a mad rush because then I have to do my own talk, and I don’t know yet.

I think, so far, the last time I did this summit, I was talking about how this year had to develop into the year of agents. It’s really played out a lot. Obviously, now the trendy thing is to say, no, it’s not just the year; it’s the decade of agents.

But this year, I think agents really took off, and most people got it right. The consensus was correct. You don’t have to be too spicy or counter-consensus to say that if you worked on an agent, you’re probably a lot better off. You probably made a lot of progress this year.

Maybe you can tell me how it feels from the Jules point of view. I didn’t see myself at the start. You’re joining an agent company—

Jed Borovik

—and I ended up doing that. I’ve gone so agent-pilled to the point where people come to me with startup ideas for infrastructure companies. They’re like, “What if we made an agent framework so that other people couldn't build agents?” I’m like, “Why don’t you just build agents yourself, bro?”

Like, there are a lot of frameworks—frameworks and infrastructure companies. All these guys are just good developers with no conviction whatsoever in what they want to build. They don’t know what customer they want. They’re just like, “We want to build developer tools,” so that’s where we feel comfortable.

But honestly, it’s not that hard to take a stand and be full-stack and verticalize in some particular agent field that you want. Guess what? The business and the economics are aligned that way.

I’m not saying that you cannot make it as an infrastructure company. There are some fantastic infrastructure companies that I admire and would invest in myself. It’s just that, comparatively, those are a lot harder. Agent companies seem like they’re shooting fish in a barrel. They seem like they’re ramping up in ARR a lot faster, and it seems like their margins are better, so why not?

Speaker 1

Yeah. So, I mean, for us, it’s certainly been— as the models get better, and as we were talking about, “What is it? Let’s build Jules for where things are going”—I think it just becomes clearer and clearer that agents are super powerful.

High-context management and all that stuff is important. We had a funny story: we store some data for a session, but it only lasts 30 days. We only store it for 30 days, and so after 30 days your session becomes locked. When the first user started hitting that, they were upset. We were like, “There’s no way anyone’s going to be using a single session for 30 days.” Are people doing a single track of work for 30 days? That’s just how powerful that could be.

How do you compress context when you run into it?

Jed Borovik

We have—I can’t talk too much about it, but we do a lot of the standard things. We’re also developing a bunch of stuff. It’s an active area of research for us.

Speaker 1

Yeah. I think, just to be clear, I’m not asking you exactly how Jules does it. There are a number of approaches, right? You just have to pick one, because you can’t just use up your 2-million-token context window.

Jed Borovik

Is it 2 million? It is up to 2 million, especially for coding agents, because you’re reading files and running commands with huge outputs. I think coding agents are a really interesting area, both product-wise and in terms of the impact they’re having, but also for research. They really push the limits: what other domains are you running an agent for 30 days, and what other domains are you accumulating so much context and so many turns? Coding agents are kind of a special spot—super interesting from a product-impact and research perspective.

Speaker 1

Yeah, I see the Anthropic folks have dropped auto-compaction for a handoff mechanic, which was pioneered by the Agents SDK.

Jed Borovik

Which is basically the subagents pattern: you spin up a subagent, have it do a thing, and you don’t need all of the context that subagent is using.

Speaker 1

And then you can sort of come back to the main thread.

Jed Borovik

Totally. Yep, yep, yep. It’s a good pattern, but it also has this challenge: how do you make sure enough information is going back and forth? Summarization is a pattern. Externalizing some of that context, whether it’s writing it to a note or something like that, is a common pattern. There are tons of things to try and do.

Speaker 1

Yeah. One thing I do want to get more consensus about is what the best method is, because I don’t think I’ve read any papers—

Jed Borovik

—about which methods compare better.

Speaker 1

Yeah. As models change, the answers change a little bit too.

Jed Borovik

Yeah, yeah. Claude probably externalizes too much.

Speaker 1

Yeah. [laughter]

Jed Borovik

Yeah.

Speaker 1

How much does your work actually— I feel like I switched back to Jules mode.

Jed Borovik

Yeah, yeah. Keep it free-flowing here.

Speaker 1

Yeah. Well, I mean, how much does your work inform model creation? At the end of the day, you’re obviously a very big consumer of Gemini models, but you’re not the only consumer, and they have other priorities than you.

Jed Borovik

Yeah, totally. Totally. I think we’re lucky in how we’re positioned. We have very close relationships with DeepMind, and coding agents are an important area. Let’s be honest: for any company building models, you can see it in all the labs—coding agents are important, and coding capabilities are really important.

Speaker 1

My OG image of the AI coding UI—I wrote something obnoxious like, “Code is the first spark of AGI.”

Jed Borovik

Yeah.

Speaker 1

Which is probably true.

Jed Borovik

Totally. Yeah, it’s important from an AGI perspective. It’s important from a dollars perspective. It’s important for all of it. I think we’re in a really lucky position where we’re able to have a lot of good collaboration, both ways. All kinds of capabilities are being developed, and it’s interesting because it’s a whole host of things. In terms of AGI and the capabilities of these systems, there are also computer-use models and browser-use models. It’s models that output code, but it’s also the whole suite of things that you’d want an intelligent agent to be able to do. It’s multimodal; it’s all kinds of stuff that goes into it.

Speaker 1

What would you want to find out from your peers at other coding-agent companies? You’re going to meet all of them, basically.

Jed Borovik

Yeah. I think one thing—and I don’t think of this as a zero-sum thing—is that there’s a tide that’s going to lift all of our boats. We’re inventing a new way to do our art: how to create good art as a software engineer. What does that look like, and how does that feel? What is the experience we want to create?

As people working in AI, sometimes we don’t do a good enough job describing this beautiful future we’re creating. I know the CEOs and heads of these labs have started writing their think pieces on this, but for software engineers, what is this beautiful future we’re creating? I think that’s inspiring. It makes it less scary for people who are thinking about these tools, but if we can’t articulate it and think about it, it’s less likely we’ll get there.

What is this great place we want to create? Writing software is so hard. At so many companies, especially big companies, it becomes so challenging to manage a codebase. What can we do to make being a software engineer an absolutely incredible experience? How do you want to interact with your model? How are you doing things locally versus in the cloud, and how do they interoperate?

As an industry, we’re trying to change how we do our art. In some ways, we’re inventing it. The better we can create this experience, the more we all win to some degree.

Speaker 1

Yeah, local-to-cloud sync is the most contentious—or important, I guess—topic for a lot of people. I wonder if we’ll ever get some kind of interrupt thing. Probably not. But in your dream, tell me more about your dream flow here.

Jed Borovik

I don’t know. Start with the Jules CLI, end up in Devin. I don’t know.

Speaker 1

Oh, interaction between agents, yeah.

Jed Borovik

It’s probably meaningless. So, no, I’m not actually serious about it, but—

Speaker 1

Actually, well, I think Codex—or is it Claude Code Web?—can do this teleport.

Jed Borovik

Mhm. It can do this teleport.

Speaker 1

Yep.

Jed Borovik

They basically dump the entire history, and you can pick it up in Claude Code on your desktop. That’s probably the right move.

Speaker 1

Yeah.

Jed Borovik

Maybe there are more elegant things, but they were first, so why not?

Speaker 1

Yeah.

Jed Borovik

Maybe the real thing is that it’s not the conversation. Maybe you don’t need to teleport if the unit of the artifact that you pass back and forth is the Linear ticket or the GitHub PR.

Speaker 1

Right. You don’t need the full JSON. You don’t need the full chat history. You just need to pick up where other people left off, because that’s how humans do it.

Jed Borovik

Right, right, right.

Speaker 1

Right. I don’t transfer my brain state to you. I just tell you what I did.

Jed Borovik

Yeah.

Speaker 1

And then, if I forgot to say something, you find out eventually. The cloud agent dumps some kind of summary onto the ticket, or whatever it needs to pass on to the next—

Jed Borovik

—in Slack, Linear, and whatever.

Speaker 1

Yeah, yeah. That’s interesting. There are some patterns emerging, though: IDE, CLI, cloud. Those are the pieces, along with a VS Code extension.

Jed Borovik

Yeah, VS Code.

Speaker 1

Whether you guys have one or not, the surface area is standardizing. It feels a little bit—how these things interoperate and how you can make this a great experience across all of those is really interesting.

Yeah. I want to backtrack a little bit to something else you said: the think pieces these CEOs and others put out. I think there are a lot of questions about the impact that coding has on the software-engineering industry in general, on the humans. Do we stop hiring juniors altogether? Is it actually increasing productivity, or do you just feel like you’re increasing productivity? I don’t know if you have any take on that stuff.

Jed Borovik

Yeah, totally. This is something I spend a lot of time talking and thinking about with folks. I also spend time talking to people at companies, and sometimes, working on these tools, it’s interesting to see that this technology isn’t as diffused across software engineers as I sometimes expect. There are plenty of places that aren’t really using AI a ton. A lot of companies and a lot of software engineers aren’t.

That being said, I’m very excited about what the future of software users looks like. Could you imagine going back to not having these tools? No, that sounds horrible. That’s one aspect of it.

I also don’t really buy this story that we’re not going to hire more software engineers, for a few reasons. This is an example that often comes up: the elasticity of the demand for software.

Speaker 1

Okay.

Jed Borovik

Jevons paradox.

Speaker 1

Exactly.

Jed Borovik

A lot of the cases that sometimes come up involve farming. There was a time in America when the vast majority of Americans were farmers, and then technology happened. Today, it’s less than 1%.

Speaker 1

Yeah.

Jed Borovik

That’s one example, but the flip side is electricity. As it gets cheaper and cheaper, people just consume more and more and more electricity. With food, there’s only so much food we’re going to eat. There’s an inelastic demand for that, whereas software has very elastic demand.

Speaker 1

It seems like software keeps getting better and better. The ability to create more and more software, from punch cards through to where we are today, is remarkably different in terms of how you're able to create software. So much more software is being made, and software keeps becoming more and more of our GDP. I'm bullish on the amount of software we'll be able to create and how it will be created.

I think there's also something here about how, as an engineer, being able to be more productive encourages more investment in people building software. If a software engineer can now do 50% more, 100% more, or 10x more, justifying investment dollars into projects dramatically changes. I'm bullish on the idea that this is going to be great for software, both for our ability to do our craft and for what it means for the number of companies, the amount that's made, the quality of it, and what we're able to do with it. That's my rose-colored-glasses take.

Speaker 1

Rose-colored glasses indeed. I have this take on the different kinds of work. We're splitting up the different kinds of software work, and there's a lot of commoditized work that we used to spend a lot of time on that we can now basically entirely delegate to agents.

Speaker 1

Then that leaves us, ideally, for more strategic, important, novel, high-risk—whatever—work: deep, focused work that is meaningful.

Speaker 1

I feel like it's not vibe coding—whatever the opposite of it is. Actually, that's my talk. I've been thinking about this.

Speaker 1

So I tweeted out this phrase because I think it's in the air. The term “vibe coding” was obviously coined by Andrej Karpathy, who's super influential, in February, and people have come to use it as a blank check to just YOLO on prompts and create the worst code imaginable, leaving other people to clean it up.

I think people are reaching their limits with this. It was probably maxed out in terms of popularity, but we don't yet have what's next.

Speaker 1

Right?

Speaker 1

My talk is really challenging every attendee and every speaker to come up with the aspirational, good version of vibe coding that we can actually trust.

Jed Borovik

Yeah. What is it?

Speaker 1

The punchline right now—the current leading candidate—is agentic coding, which is what DHH says. I don't know if you know who DHH is, but he has a pretty good track record when he's naming things.

Jed Borovik

It's too many syllables. I don't think it has the joy that vibe coding invokes, which I think people want. But people also want care, craft, reliability, and all that stuff.

Speaker 1

If we don't have the term to describe it, maybe we don't have a catchy phrase for it, but what does it look like? Even if we don't have the phrase, what does it look like?

Speaker 1

That's a great question. We have some speakers who are going to be pitching spec-driven development, where you have to be really thoughtful and effectively write a PRD. I think that is obviously very correct in the sense that it's just a glorified prompt, but a very, very good one. Models are tuned to follow your prompt, for good and for worse. If you prompt sloppily, you're going to get slop.

Speaker 1

A spec sounds good. I don't know how often it will be followed in practice, because effectively what that transitions us to is a waterfall development approach, where you spend 3 days writing a 50-page document and kick off the agent. That doesn't seem right.

I obviously have some bias here, because Cognition has believed in interactive planning from the start. You kick off a thing, you get some feedback, and then you're like, “That's not what I meant. Let me correct myself,” because I don't know what I wanted when I started. You work with the machine to discover what you wanted, and the machine works with you to either get you what you wanted or show you the errors of your ways. Then you correct it from there.

Speaker 1

One thing we talk about, which is very aligned with that thinking, is that there are 2 problems as these things get better. One is how you specify what you want, and the other is how you verify that what you got is what you were thinking.

To my knowledge, you guys don't emphasize tests that much, right? It's not like you volunteer to write my tests.

Speaker 2

It depends. If there are tests in your codebase, it's right out of the box here. Jules will run your test suite.

Speaker 1

Exactly. But it's not like after everything there must be a matching test for the prompt that was mentioned. That would be the extreme of what we were talking about. I don't know if people always want that. Maybe it would be helpful to do that to show that it was right.

But let's say I don't write tests in my codebase. I want to merge a pull request that is introducing tests just for this one thing. I think in some ways the engineer should be able to control what kind of outputs they want. If it helps and they want it, absolutely.

Do you think there are other innovations in specifying apart from just chat?

Jed Borovik

Oh, totally. Agent IDEs, for example. Spec-driven development is in this category. One of them is multimodal. If I'm going to show a bug on our website, do I want to type out words to describe it, or am I going to point at the picture?

With Jules, you can upload images now. We have certain ways we communicate as humans that are easier in certain situations. Let's bring that to our engagement with the software.

Speaker 1

Of all people, I expect you guys to be best at this because Gemini has video understanding. I just want to submit a video, because some things cannot be screenshots.

Speaker 2

Yep.

Speaker 1

It's more about the behavior of things appearing and disappearing. I would love that if you guys did it, because no one has it yet.

Jed Borovik

I know. I would love it too. I'll tag you now.

Speaker 1

On my side, the vision—the version of that that we're exploring—is computer use.

Computer use was introduced by Anthropic, and then OpenAI dipped their toe in with Operator and now Agent Mode in Atlas. I don't know if you guys have done anything super splashy on computer use, but it's coming back. I can feel it. It ties into coding agents and just using AI systems in general.

Jed Borovik

Yeah, definitely.

Speaker 1

Basically, your VM now needs to render a UI or a browser, and then you need to let the agent click around in it.

Jed Borovik

Absolutely.

Speaker 1

You need precision and speed, as well as an affordable cost.

Speaker 2

Yep.

Speaker 1

It's a lot.

Jed Borovik

Yeah. These are the kinds of projects that are so fun. There's just so much to build. I think one of the reasons you see so many companies in the space is partly that it's just so fun. There are so many things to build and so many tools that seem like science fiction.

It brings up a demo of what I've worked on. It's clicking around, and I can see a video of it, or I can even take over and use it.

Speaker 1

Yeah, it's awesome.

Okay, moving toward wrapping up: if people run into you at AI Engineer after they've heard your pitch on Jules, what else should they talk to you about? What can you help with, and what are you looking for?

Jed Borovik

Anyone should feel free to come up and talk to me at any point. I'm obviously very interested in anyone who's doing stuff with coding agents or using coding agents in an interesting way. I'm always curious about the workflows people have with their agents, whether it's, “I'm using this tool in this way, and I've configured this crazy thing.” I always love hearing how people are using it.

I also love hearing from people who are having a bad time with it. Maybe they're not coming to this conference, but I want to hear, “I've tried all these tools, I don't like them, I don't use them, and here's why.”

Jed Borovik

Yeah. I’m totally open for any side of it, all the way from full AI-pilled coding AI lovers to people who hate it. As far as what I’m looking for, I think I’m really just going to connect and meet people. We’re always hiring, so anyone who’s interested in working on this stuff, I’m always happy to talk. But, yeah, really just meeting people, spending time geeking out on this stuff.

Speaker 1

Yeah, there’ll be lots of geeking out.

All right. Thanks for your time. Looking forward to it.

Jed Borovik

Yeah, same.

⚡ Google Labs 内部:打造 Gemini Coding Agent——Jed Borovik、Jules 与 AIE CODE Preview — 文字稿与摘要 | BidClub