AI 编程代理与产品管理瓶颈

大家好。感谢你来到这里，Andrew。很高兴你第二年回来。

Hey everyone. Thank you for being here, Andrew. It's great to have you back for year two.

很高兴回来。你组织的这个聚会一直都很棒。

It's good to be back. This has always been such a cool gathering that you put together.

我之前跟你提过，Andrew 去年的炉边谈话是 YouTube 上点赞最多、观看最多的。所以我们很高兴他第二年回来。

I was telling you this earlier, but Andrew's fireside chat last year was the most liked and the most watched on YouTube after hours. So, we're thrilled to have him back for year two.

也许从这个话题出发，自从我们上次见面以来的一年里，我觉得 AI 领域发生了很多事情。哪些比你预期的更快，哪些更慢？

Maybe jumping off of that, in the year since we've been here, I feel like there's been a ton that's happened in the AI space. What has happened faster than you would have expected and what's been slower?

我认为炒作超出了我的预期。而且不幸的是，末日论调也比我想象的更有市场，包括工作末日论，我不认为这会发生。更积极的一面是，编码智能体可能比我预想的起飞得更快。前沿编码智能体——我知道炒作说 AI 每几个月就变一次，这不完全正确，但对编码智能体来说确实如此，我们能做的事情的前沿竞争非常激烈。六个月前我几乎只用 Claude Code。现在我还是大量用 Claude Code，但也越来越多地用 OpenAI Codex，混合使用 Gemini CLI，还想支持 Open Code，因为它是开源的。所以我们使用的编码智能体组合变化很快。一年前我没想到自己会在手机上大量编程。这些工作流——就像你们很多人办公室里有一台 Mac mini——所有这些工作流都在快速变化。而且智能体工作流开始真正进入企业。这感觉也很好。

So, I think the hype has exceeded my expectations. And also the doomsaying narratives also got more traction, unfortunately, than I would have guessed, including the jobpocalypse, which I don't think is going to be a thing. On the more positive side, coding agents probably took off faster than I would have guessed. The frontier coding agents—I know the hype is that everything AI changes every few months, and that hype isn't entirely true, but it does feel true for coding agents where the frontier of what we can do with coding agents is so competitive. Six months ago I was almost all Claude Code. These days I'm still a lot of Claude Code, but also increasingly OpenAI Codex with a mix of Gemini CLI and want to support Open Code as well because it's Open Code. So, the mix of coding agents we use has been changing rapidly. I wouldn't have guessed a year ago that I'd be coding so much on my phone as well. These workflows—like many of you have a Mac mini in my computer in my office—all these workflows are changing really rapidly. And agentic workflows are really starting to make their way into enterprises. That feels pretty good as well.

那么，关于软件工程，你心目中软件工程的未来是什么样的？

So, on that note, on the software engineering note, what does the future of software engineering look like in your mind?

大约一年前，我写过关于产品管理瓶颈的文章，观察到如果构建变得更快，那么决定构建什么，或者产品管理的工作——确定项目范围、获取客户反馈、决定构建什么——就变成了瓶颈。过去一年里，产品管理瓶颈变得更严重了，从好的方面说，因为软件构建变得更快了。但事实证明，当编写软件的速度提高 10 倍或 100 倍时，不仅产品管理成为瓶颈，几乎所有其他事情都成了瓶颈。所以，我的一些团队看到了营销瓶颈，因为我们可以构建这么多功能，我们的营销人员手忙脚乱地弄清楚工程师到底做了什么，以便想办法沟通。以前，如果你有一个需要法律合规的产品，如果构建需要三个月，等一周让法律部门批准可能还行。但现在，如果你一天就构建好了，然后等一周让法律部门批准，这就成了法律合规瓶颈。还有设计瓶颈，等等。所以我一直在思考未来软件工程团队将如何组织，我不确定答案。但我越来越多地组建非常小的团队，从 1 到 10 个工程师不等，通常是通才，高语境、高度授权的通才。他们被给予非常宽泛的指导原则，在这个范围内他们可以疯狂地构建和发布代码，甚至推动决策，比如写营销文案，这传统上不属于工程范畴。也许从定义上说，假设你有一个团队需要软件工程、产品管理、一点服务条款、一些营销文案、一些设计。假设你需要五个职能，但团队只有两个人，那么根据鸽巢原理，这两个人每人必须扮演不止一个角色。但好消息是，我发现我不是一个好的营销人员，但当我使用 AI 时，我仍然不是好的营销人员，但比我独自做要好一点。所以我发现这些高语境通才的小团队，他们技术深厚，但也能利用前沿技术做一些其他角色的事情。比如，每个工程师都用 AI 起草服务条款的初稿，然后交给律师最终润色。我发现这些流程让团队移动得更快。所以这非常令人兴奋。

About a year ago, I was writing about the product management bottleneck, which is this observation that if building becomes much faster, then deciding what to build, or the product management work of scoping the project, maybe getting customer feedback, deciding what to build, becomes the bottleneck. It feels like over the last year, the product management bottleneck has become much worse, in a good way, because software building has become much faster. But it turns out when writing software becomes 10 or 100 times faster, not only is there a product management bottleneck, pretty much everything else becomes a bottleneck. So, some of my teams have seen the marketing bottleneck, because we can build so many features, our marketers are scrambling to figure out what on earth the engineers did, in order to figure out how to communicate it. Previously, if you had a product that needed legal compliance, if it took three months to build it, waiting a week for legal to sign off is maybe okay. But now, if you build in a day, then wait a week for legal to sign off, that's a legal compliance bottleneck. And there's a design bottleneck, and so on. So, I've been thinking a lot about how software engineering teams in the future will be organized, and I don't think I know the answer. But increasingly, I find myself setting up very small pods, anywhere from one to ten engineers in a team, of often generalists, high-context, highly empowered generalists. They're given a set of very wide guardrails, within which they can just run like crazy and build and ship code, and even drive decisions like writing marketing copy, that traditionally outside the purview of engineering. Maybe by definition, let's say you have a team that needs software engineering, product management, a little bit of terms of service, some marketing copy, some design. Say you need five functions represented in a team of two humans, then by the pigeonhole principle, these two humans have to play more than a single role per human. But the good news is it turns out I don't think I'm a very good marketer, but when I use AI, I'm still not a good marketer, but I'm slightly less bad compared to if I had to do it alone. So, I find these small teams of high-context generalists that are deeply technical, but able to use frontier technology to do a little bit of other roles as well. Like, every engineer uses AI to take the first draft of a terms of service, to then take to a lawyer for the lawyer to finally polish it before it goes out, but I find that these processes allow teams to move much faster. So, that's really exciting.

这些人应该有什么背景？他们是工程师背景吗？还是来自不同学科，第一次学习编程？你看到了什么？

And what's the right background for these folks? Are these engineers by background? Are they coming in from different disciplines and learning to code for the first time? What are you seeing here?

是的，我密切合作的很多人都有深厚的工程和技术专长。他们也是高度授权的轻微通才，能够进入其他角色，并在 AI 的支持下获得这些技能组合，即使他们没有接受过相关培训。我认为人们可以从任何方向成功。我见过产品经理编程能力变得很强，然后参与这些团队。我认为因为 AI 编码很多，工程师可能天然有优势理解前沿技术，所以我看到工程师最常成功扮演这个角色，但确实也有少数产品经理、营销人员以非常有效的方式学习编程。我见过运营人员开始构建越来越多的产品。我认为任何背景的人都有可能学会做很多这些事情，但目前做得最好的人中，最多的是来自工程背景的，但我们鼓励任何背景的人都试试看能否扮演这些角色。

Yeah, so a lot of the people I work with most closely have deep engineering and technical expertise. And then also are highly empowered slight generalists that step into other roles and acquire this mix of skills often with AI supporting where they didn't have that training. I think people can succeed from any direction. I've seen product managers become much stronger at coding and then participate in these teams. I think just because so much of AI coding and engineers maybe had a natural advantage understanding the frontier tech, so I see engineers play this role successfully the most often, but there's definitely a smaller number of product managers I've seen marketers learn to code in pretty effective ways. I've seen operations people start to build more and more products. I think it's actually possible people of any background to learn to do a lot of this, but the largest number of bodies doing this well right now seems to be people that came from an engineering background, but we encourage everyone from whatever background to see if you can play these roles.

对于那些想更多进入这个新软件工程领域的人，你有什么建议？无论是尝试特定工具、拥有某种心态还是学习某些技能？

What advice would you have for folks who are trying to get more into this in this new software engineering space, whether it's particular tools to try or mindsets to have or skills to pick up?

是的，我一直在思考软件工程未来的一种方式。这是我脑海中的一个思维模型：由于许多工具提供商提供了 RAG、智能体框架、评估、护栏等，这些 AI 构建块，还有非 AI 构建块，比如用户界面组件、身份机制、前后端持久化数据库等等。

Yeah, so there's one way I've been thinking about the future of software engineering. This is a mental model I have in my head: because of a lot of providers of many tools like RAG, agentic frameworks, things like evals, guardrails, it turns out that as well as these AI building blocks, there are also non-AI building blocks, things like user interface components or identity mechanisms and front and back end persistence databases and so on.

我认为在计算机科学中，我们一直拥有大量优秀的构建模块。随着智能体式编码的发展，这些模块正在激增，因为越来越多的人在构建开源或专有的基于 API 的模块。所以，我们周围到处都是优秀的构建模块。我发现，那些熟练掌握足够多构建模块的开发者，通常能以组合的方式将它们快速组装成软件。就像用乐高积木搭建一样：如果只有白色积木，能搭的东西有限；但如果加入黑色、黄色、棕色、绿色积木，甚至一些异形件，能搭建的东西就会组合式增长，甚至指数级增长。我们现在能接触到的许多构建模块也是如此。开发者需要真正理解这些模块的功能。DeepLearning.AI 提供了大量长形式的短期课程，帮助人们掌握这些由许多人提供的优秀模块。另一个挑战是使用编码智能体快速将这些模块组装成你想要的软件。编码智能体的一个问题是，很多模块太新，它们不知道如何使用。比如，直到最近，领先的编码智能体——Nano Banana 是在许多领先模型的知识截止日期之后发布的，所以它完全不知道如何调用 Nano Banana API，甚至不知道它的存在。我和我的朋友 Rohit Prasad 热衷的一个项目是 Context Hub，它有点像 AI 智能体的 Stack Overflow，为智能体提供最新的文档，包括最新的 API、SDK 和可用模块，同时也让智能体能够反馈文档以改进它。我发现，我个人使用的许多 API 语法有点难记，但通过 Context Hub 加载最新文档，我可以让编码智能体准确地为我进行所有 API 调用。这确实大大加速了我的编码工作。

So I think that in computer science we've always had a wonderful set of building blocks and with agentic coding building blocks are proliferating because more and more people are building open source or proprietary API based or whatever types of building blocks. So there's just wonderful building blocks all around us. And so I find that developers that have a good mastery of enough building blocks can often put them together in combinatorially many ways to very rapidly build software. Right, maybe you have a picture of building with LEGO bricks. If all I have is like a white colored LEGO brick, you know, I can build some stuff, but it's not that interesting. But if I mix in a black LEGO brick, a yellow one, and a brown one, and a green one, and throw in some squiggly pieces of LEGO, then the what I can build grows combinatorially or grows exponentially as a function of the number of Lego bricks I have. And I think a lot of building blocks we now have access to as being akin to that, too. Um so, I find that the developers they're able to have a good sense of love what these building blocks do. And DeepLearning.AI offers a lot of long-form short courses to help people master these wonderful building blocks provided by tons of people. And then the other challenge is to use coding agents to rapidly assemble these building blocks into the software that you want. Um one challenge that coding agents have is a lot of building blocks are so new that the coding agents do not know how to use them, right? I I think until recently, the leading coding agents were, you know, Nano Banana was released after the knowledge cutoff date of a lot of leading models. So, it just had no idea how to call the Nano Banana API or even knew that Nano Banana existed. Um so, one project that one of my friends, Rohit Prasad, and I have been passionate about is a Context Hub, which is um kind of a Stack Overflow for AI agents for AI agents to get the latest documentation on what are the latest APIs, SDKs, building blocks you can use, um as well as a way for agents to give feedback to the documentation to try to improve it for everyone. And so, it turns out there are a number of APIs that I personally use that, you know, I find the syntax slightly annoying to remember, um but but I find that uh by using Context Hub to load the latest docs, um I let the coding agent accurately make all of these API calls for me, right? And and so, it actually um has helped my own coding work, you know, accelerate quite a bit.

这里有两个小点。我们也推出了一个叫 Context Hub 的东西，所以名字撞了，但我们的 Context Hub 是完全不同的类型。他的那个对编码智能体工作更有用，所以大家应该去用他的。另外，关于深度学习，我们 LangChain 是 OpenAI 深度学习课程背后的团队之一，我知道很多人通过深度学习课程知道了 LangChain，在座很多观众也是如此。如果你还没试过深度学习课程，绝对应该去上一些。那么，在这个 AI 新时代，你认为教育会如何改变？你是否已经开始将这些实践融入到深度学习课程的运营中，或者你是如何看待这一点的？

Maybe maybe two notes there. We we also launched something called Context Hub. So, we're colliding on names, but it's a very different type of Context Hub. Um and so, yeah, his is much more useful for working with coding agents. So, you should go to use that. And then, deep learning. So, I think we at LangChain were the the the people behind Open AI I want to say to do deep learning class and I know I've talked to so many people who have heard of LangChain through deep learning and I'm sure a lot of the audience members here as well. So, if you haven't tried out deep learning you should absolutely go take some courses. Maybe maybe on that note, how do you how do you think about education changing in this new world of AI and have you started to bake any of those practices into how the deep learning courses are run or how you think about that?

是的，我们正在尝试多种方式来改善教育体验。在培训内容方面，很明显人们需要学习的东西已经发生了巨大变化。对于开发者来说，需要学习编码智能体、这些构建模块，可能还要学习一些产品管理或通用技能，以提高效率。所以学习内容在变，DeepLearning.AI、Coursera、Udemy 等平台也在提供这些培训。但除了学什么，还有培训的交付方式。我们一直在思考学习将如何转型，但感觉真正的变革尚未到来。几周前，我们推出了一个预览版的新网站，其愿景是：与其上在线课程，不如来对话。它不是课程，而是一场对话。我们试图构建的体验是，你和我进行模拟视频通话，如果你只想放松听我讲，我会一对一地给你展示关于编码智能体上下文的一些想法；如果你想打断我或我的 AI 提问，随时都可以。我个人还在大量尝试用 JavaScript 替代视频和幻灯片。这意味着，当我在视频中演示时，你可以点击视频并输入自己的提示或查询。视频区域不再是静态播放，而是交互式的，创造了更多互动方式。所以，如果你愿意，可以访问 codedream.ai，与我的 AI 进行对话，我会以 AI 形式向你展示如何使用这些编码引擎。但坦率地说，我们仍在每天迭代和改进这些体验。

Yeah, so um we're trying a lot of ways to improve the education experience. So, maybe in terms of training, uh the thing that's clear is that what people have to learn has changed significantly. Um I think for developers with the learn coding agents, learn these building blocks, maybe learn some product management or these type of general skills to make us more effective. So, what we learn is changing um and DeepLearning.AI, Coursera, you know, Udemy try to provide a lot of that training. Um but separately from how to what to learn, there's the delivery of training and it feels like we've been, you know, thinking about how will learning transform for a long time and it feels like it's actually not quite here yet. Um one thing we launched just several weeks ago is a new website um in our preview called in which the vision was rather than taking an rather than taking online course, come and have a conversation. So, it's not a course, it's a conversation where the experience we tried to build was um for you to come and uh get on a simulated video call with me, say, where if you feel like leaning back and listening to me talk and present to you in a one-on-one video simulated video call about context of encoding agents, you lean back and I'll just show you some ideas. Or if you want to interrupt, you know, me or interrupt my AI and ask a question, uh you could do so at any time. Um and one one thing I actually personally, playing around with lots with is um, replacing videos and slides with JavaScript. Um, and what that means is instead of a video when I present when I demo something in a video, if you could, you know, click into the video and type your own prompts or type your own queries into the video windows. So, instead of a static video that just plays, the video area is interactive and just creates more ways for people to interact. Um, so check out codedream.ai if you want and have a kind of a conversation with me or with my AI where I'll present to you in AI form how to use contact some of these coding engines. But, I think we're still we're actually, frankly, still iterating and improving these experiences every day.

那个点击视频并输入的功能，现在是实时的吗？还是说这更多是未来的方向？

Is is that clicking into the video and and typing Is that live today or is that more of a future direction we're going in?

那是实时的。想象一下，不是我在视频中共享屏幕，而是用 JavaScript 共享。所以你可以与我共享的任何内容互动，因为那是运行的 JavaScript 代码，而不是录好的视频。所以，是的，我们仍在改进，如果你有任何反馈，我们很乐意听取。但我觉得教育的转型被过度炒作了一些。变革即将到来，但今天，在线课程——我希望我们有比在线课程好得多的东西。不过，我可以说，我们现在的课程比十年前好多了，交互性更强。比如今天早上，我们刚推出了一门由 Indee Sharan Jou 讲授的 Transformer 新课程。我发现，与十年前主要只有视频不同，我们现在构建了更多交互式可视化内容，有很多有趣的东西可以玩。但最大的转型，我确实花了很多时间思考。

Uh, that's live. So, imagine if instead of me screen sharing in a video, I am, you know, JavaScript sharing in the video. And so, you can interact with whatever I'm call screen sharing of because it's running JavaScript code, not not a not a canned video. So, yeah, hope we're we're still If any if you say say that we'll love your feedback. But, it feels like I think the transformation of education has been over hyped. I think something is coming, but today, um, taking online courses, you know, I wish we had something way better than online courses. And I will say we have something better than the courses we had 10 years ago. They're much more interactive. It turns out for a lot of our courses, uh, this morning, we actually just we just launched a new course on transformers taught by Indee Sharan Jou. Um, and I find that rather than just having videos, which is mostly what we had, you know, a decade ago, um, we now build much more interactive visualizations. There's a lot more fun stuff to play with than courses had a decade ago. But, that biggest transformation, um, I actually spend a lot of time thinking about that. Yeah.

也许从软件工程扩展到其他所有领域，你如何看待企业采用 AI？是比你预期的更快还是更慢？正确的方法是什么？人们可以学到什么教训？

Maybe going from software engineering to everywhere else, how do you see enterprises adopting AI and is it faster than you expected, slower, what's the right way to do it, what lessons can people learn?

我认为每家企业都对采用 AI 感到兴奋。从我的团队 AI Aspire（我和商业伙伴 Christy Tan 共同创立的 AI 咨询公司）看到的情况是，我们经常与大企业——财富 50 强、500 强、G2000——讨论 AI 战略和转型。有一些共同的主题：我们都投资了自下而上的创新策略，即“百花齐放”。但大部分情况下，这并没有带来回报。CEO 和董事会都在问：“AI 的投资回报率在哪里？”我认为我们应该继续投资自下而上的创新，但它往往导致点状解决方案，带来增量效率提升——这很好——但不是 AI 所承诺的更广泛的转型。例如，我的团队与银行合作。贷款承销可能有五个步骤：营销贷款产品、获取申请、审核批准、最终尽职调查和执行。许多团队注意到，贷款审批这一步可以用 AI 自动化，节省一小时的人力时间。这很好，但如果整个流程除了那一小时外保持不变，那只是微小的增量收益。一些银行说：“与其追求这种效率提升，不如重新思考整个工作流程，推出一款‘10 分钟获批’的贷款产品。”因为与其等一周让人类有空闲一小时，我们可以立即将申请发送给 AI 做决策。挑战在于，这需要有人以更广泛的视角重新设计整个工作流程——营销、数据基础设施、AI 决策和最终执行都需要参与。自下而上的创新很有价值，能产生想法，但必须辅以自上而下的行动，让具有更广泛视角的人改变所有步骤的运作方式，从而创造增长。许多企业谈论成本节约，这没问题，但我推动更具想象力的事情：驱动增长。我们只能节省那么多钱，但增长几乎没有实际天花板。

I think every enterprise is excited about AI adoption. One thing we're seeing from my team at AI Aspire, an AI advisory firm my business partner Christy Tan and I co-founded, is that we talk to large businesses all the time—Fortune 50, Fortune 500, G2000—about AI strategies and transformation. Some consistent themes: all of us have invested in the bottom-up innovation 'let a thousand flowers bloom' strategy. For the most part, it's not paying off. CEOs and boards are asking, 'Where is the ROI of AI?' I think we should keep investing in bottom-up innovation, but it often results in point solutions that drive incremental efficiency gains—which are good—but not the broader transformation AI has promised. For example, my team works with banks. Underwriting a loan might have five steps: market the loan product, get the application, review and approve, do final diligence, and execute. Many teams have noticed that the step of loan approval could be automated with AI, saving an hour of human time. That's great, but if the entire process stays the same except for that one hour, it's a small incremental gain. Some banks have said, 'Instead of that efficiency gain, let's rethink the entire workflow and market a get-approved-in-10-minute loan product.' Because rather than waiting a week for a human to be free for an hour, we can send the application to AI right away. The challenge is that this requires someone with broad scope to redesign the entire workflow—marketing, data infrastructure, AI decision-making, and final execution all need to be involved. Bottom-up innovation is valuable and generates ideas, but it must be complemented with a top-down motion where someone with broader scope changes how all steps operate to create growth. Many businesses talk about cost savings, which is fine, but I push for more imaginative things: driving growth. We can only save so much money, but growth has almost no practical ceiling.

你有没有看到一些推动业务增长的好例子，让你特别兴奋，或者认为其他人应该关注和学习？

Are there any good examples of driving that business growth that you've seen that you're particularly excited about or think other people should look at and learn from?

银行的例子是真实的——我们正在与多家银行和金融机构合作。另一个模式是客户服务和联络中心，通常被视为成本节约的事情。成本节约很好，但当你自动化或增强客户服务时，你可以服务更多客户，速度更快，提供更愉快的体验并推动增长。我还与一些致力于自动化得来速订单流程的企业交谈过，这也带来了更愉快的客户体验并推动了增长。我看到越来越多的这类例子出现在经济的不同领域。有些我知道但不能谈论，但我相信会有更多例子。

The bank example is a real one—we're working with a number of banks and financial institutions on that. Another pattern is customer service and contact centers, often viewed as a cost-saving thing. Cost savings are nice, but when you automate or augment customer service, you can serve customers many more and much faster, delivering a more delightful experience and driving growth. I've also spoken with businesses working on automating drive-thru order processes, which also results in a more delightful customer experience and drives growth. I'm seeing more and more of these examples popping up in different parts of the economy. There are some I know about that I don't have permission to talk about, but I'm confident there will be more examples.

你之前提到了投资回报率。从我这几天进行的许多对话中，我知道很多人都在思考如何衡量它。在某些场景下，比如成本或呼叫中心，可能很容易衡量。但你会如何建议人们思考衡量投资回报率？

You mentioned ROI earlier. From a lot of conversations I've been having, I know many people are thinking about how to measure that. In some scenarios like cost or call centers, it might be easy to measure. But how would you advise people to think about measuring ROI?

我希望我知道。企业如此多样化，衡量投资回报率就像衡量业务本身——很难有一个放之四海而皆准的答案。但我觉得：最让我兴奋的项目，即使难以衡量，也值得衡量。但有些事情我们全力以赴，创造了巨大的价值，明显是在改变业务。当然我们仍然需要衡量，尤其是对上市公司。但我学到的是，有时推动增量收益比推动变革性收益更难。如果你告诉某人明年将业务结果提高 2%，他们会认为只需要多努力 2%。但如果你寻找推动 20% 或 50% 增长的方法，你不能让每个人都多努力 50%——你必须想出更有创意的解决方案。这往往会带来变革性的结果。

I wish I knew. Businesses are so diverse that measuring ROI is like measuring business—very hard for a one-size-fits-all answer. But one thing I feel: the projects that excite me most, even if unmeasurable, deserve measurement. But there are some things where we swing for the fences and create so much value that it's glaringly obvious this is transforming the business. Of course we still need to measure, especially for public companies. But I've learned that sometimes driving incremental gains is harder than driving transformative gains. If you tell someone to improve business results by 2% next year, they think they just need to work 2% harder. But if you search for ways to drive 20% or 50% growth, you can't just work everyone 50% harder—you have to come up with more creative solutions. That often leads to transformative outcomes.

在 AI Inspire，我们有很多企业真的给我们发来了包含数百个想法的电子表格。有一家金融机构发来一个包含 300 多个想法的表格，请我们帮他们筛选出哪些值得投入真金白银。结果发现分析起来非常困难。我希望自己足够聪明，能一眼看出哪些想法可行，但面对这么多想法，通常需要自上而下和自下而上相结合的方式，做大量的技术分析来判断可行性，同时还要做业务分析来找出哪些能带来有意义的改变。然后，还需要大量的技术和业务分析工作，才能缩小到少数几个值得投入大量资源的项目。

At AI Inspire, we've had many businesses literally send us spreadsheets with hundreds of ideas. One financial institution sent us a spreadsheet with over 300 ideas and asked us to help them sort out which ones to invest real capital behind. And it turns out that the analysis is really difficult. I wish I was smart enough to glance through it and say, oh, this idea and this idea, but I find that when faced with that many ideas, often brainstorm in a top-down and bottom-up motion, it's actually a lot of work to do the technical analysis to figure out what is possible and then also the business analysis to figure out which ones could drive meaningful change. And then it is actually a lot of work on the technical and the business analysis to then narrow down to what's the small handful of bets to put very meaningful resources behind.

而这些全力以赴的大项目，通常都是自上而下的。

And these swing for the fences type things, you're often seeing these being the top-down ones.

没错。我发现企业通常不会孤注一掷，而是会建立一个由几个深思熟虑的项目组成的组合，其中任何一个成功都会对业务产生重大影响。但你们代理机构的编码方式我很喜欢，就是做大量实验，不断原型设计。原型成本已经大幅下降。但遗憾的是，你不可能什么都做，对吧？在 10 万美元的预算下，把有意义的资源投入到少数几个项目中的每一个确实是有意义的。但由于需要这样的资源分配，往往需要更多自上而下的方式来分配所需的资源。

That's correct. Yeah, I find that businesses hopefully not take one wild swing for the fences; it's more a portfolio of a handful of thoughtful bets where if anyone pays off, it will be meaningful for the business. But it turns out one of the things I love about your agency coding is you run tons of experiments, right? Prototype all the time. So the cost of prototype has plummeted. But sadly, you can't do everything, right? On a $100,000 budget, at some point putting meaningful resources behind every one of a small portfolio of a handful of projects does make sense. But because of the resource allocation needed at that level, it often takes a little bit more of a top-down motion to allocate the amount of resources needed.

最近在企业采用 AI 方面，我听到很多关于前向部署工程师的讨论。每家公司都会有前向部署工程师吗？您认为他们为什么如此有影响力，以及您如何看待未来的发展？

One of the things that I feel like has been talked a lot recently about enterprise adoption of AI is forward-deployed engineers. Will every company have forward-deployed engineers? How do you see why do you think they're so impactful and how do you see this playing out in the future?

我认为硅谷的热潮中，FTE 确实很受关注。我觉得 Aaron 一两天前也在台上发过一条很有见地的推文。所以我认为 FTE 是个好主意。但展望未来，你认为公司中 FTE 与公司雇佣的 AI 工程师的比例会是多少？我认为大多数公司会有更多的内部工程师，以及一个较小的嵌入式 FTE 团队。这就是为什么我喜欢 FTE。我对它的增长感到兴奋。让我们帮助更多人成为 FTE。但炒作往往比实际情况更夸张。不过它确实是好事。但构建 GenAI 工作流很难。它需要理解业务，需要面向客户的技能，为了可靠性，你甚至要推动可观测性、评估，与客户合作，如果某些事情技术上不可行，要敢于拒绝，与利益相关者一起确定哪些工作流可以自动化，帮助进行变革管理。所以这是一个非常有价值的角色，需要深厚的技术判断力，而嵌入式 FTE 确实能加速项目。我还看到另一个对许多企业来说具有挑战性的问题：有没有办法获得一个供应商中立的 FTE？这其实很难，取决于你想与哪些供应商深度绑定，因为 AI 领域领先的模型变化很快。我不知道一年后领先的 AI 模型会是什么。我甚至不确定一年后领先的编码智能体会是什么。在这种不确定的时刻，可选择性非常有价值。坦率地说，许多供应商都来找我们，提供 20-30% 的折扣来签三年合同。我个人几乎从不签超过一年的合同，无论折扣多少，因为我珍视这种可选择性，以便与一年后我不知道的最好的供应商合作。当你与 FTE 合作时，我认为企业会问的一个问题是，当你公司里有来自同一家公司的几个 FTE，让他们把所有东西都嵌入到一个 AI 模型中，会在多大程度上降低你一两年后的可选择性？所以我认为这些都是企业正在纠结的问题。这也是我个人多次使用 LangSmith 的原因。我认为 Harrison 做得很好，让它非常易用。我认为这类更中立的工具对于长期观察和保持可选择性非常有价值。供应商很好，与他们合作，但为自己保留长期的可选择性似乎也很重要。

So I think the Silicon Valley buzz, things definitely having a moment of FTEs. I think Aaron was on stage here only a very thoughtful tweet about it like one or two days ago as well. So I think FTEs are a great idea. And many businesses but I think looking into the future, what do you think is the ratio of FTEs in the company versus the number of just AI engineers employed by the company, right? I think that most businesses will have a lot more in-house engineers and a smaller team of FTEs maybe embedded. So that's why I like FTEs. I'm excited about the growth. Let's help more people get jobs as FTEs. But I think the hype is also, as is often the case, a bit greater than the actual reality. But it is a good thing. But building a GenAI workflow is hard. It requires understanding the business. It requires customer-facing skills, often to make reliable you have to drive even observability, evals, work with the customer to push back if something's not actually technically feasible, work with the stakeholders to figure out what workflows to automate, help with the change management. So, this is a very valuable role that takes deep technical judgment and having FTEs embedded can really accelerate projects. There's one other thing I see as challenging for a lot of businesses, which is: is there any way to get a vendor-neutral FTE? That turns out to be challenging and depending on what vendors you want to be really embedded with because what we see in AI is that the leading AI model rapidly changes. So, I have no idea what will be the leading AI model a year from now. I'm actually not at all sure what will be the leading coding agent a year from now. And so in moments of uncertainty like this, optionality is very valuable. So, candidly, many vendors are coming to all of our businesses and offering 20-30% discounts for signing a 3-year contract, right? Whatever. I personally almost never sign longer than a 1-year contract, regardless of the discounts offered, because I value that optionality to work with whatever vendor would be the best in a year's time that I don't know about. And then when you work with FTEs, one question that I think businesses are asking is, when you have a handful of FTEs from one company in your company, how much does letting them embed everything with one AI model reduce your optionality one or two years from now? So, I think these are the businesses that companies are wrestling with. And this is why I personally have used LangSmith a bunch of times. I think Harrison did a great job making it so easy to use. I think those types of more vendor neutral tools are very valuable for observing, maintaining optionality for the long term. And the vendors are great. Work with the vendors, but preserving optionality for yourself for the long term also seems important.

关于供应商中立，特别是在模型领域，过去几天我们讨论过的一个话题是开源模型。您如何看待它们的发展，以及它们与前沿模型相比如何？

On the topic of vendor neutral, especially in the model space, one of the things we've talked about a little bit throughout the past few days is open source models. How do you see those progressing and how do you see them relative to the frontier models?

是的，有趣的是，它们一直落后于前沿模型，大概 6 到 9 个月。但前沿模型非常昂贵，以至于在许多用例中，我的团队大量使用了开放权重模型，有时微调，有时不微调。所以我希望我们都能继续支持开放权重模型。过去两周，白宫传出了一些令人担忧的声音，关于在模型发布前进行检查。我对此非常担忧，并与政府中的一些朋友谈过。我感觉一场针对开源开放权重模型的战争正在打响。有时以中美竞争的名义，有时以人们提出的各种论据为名，但我认为如果我们都能保护开源开放权重，它将使世界更加丰富，并帮助我们所有人保持可选择性。

Yeah, it's been fascinating how it's remained persistently, I'm going to say, maybe 6 to 9 months behind the frontier models. But the frontier models are expensive enough that for many use cases my team has used a lot of the open weight models, sometimes fine-tuned, sometimes without fine-tuning. So, I hope we can all keep on supporting the open weight models. Over the last 2 weeks I've been concerning noises out of the White House about inspecting models before they're released. So, I'm actually quite concerned about that and touched a few friends in the administration about this. And I feel like there is a war on open source open weight models being waged. Sometimes in the name of US-China, sometimes in the name of whatever arguments people are coming up with, but I feel like if we can all protect open source open weight, it will make the world much richer and also help all of us preserve optionality.

我和一些人讨论过一件事，就是在围绕数据构建智能体之前，先要把数据策略做对。那么，当您与正在构建智能体、并且希望这些智能体以某种形式连接到数据的公司合作时，您怎么看？

One thing I've discussed with a few folks is basically the importance of getting the data strategy right before building agents around them. And so, as you work with companies who are building agents and presumably want those agents to connect to data in some form.

你看到哪些做法行之有效？这些要求归结为什么？

What have you seen work well there? What do those requirements boil down to?

这是个好问题。谈到大型企业时，一个非常常见的痛点就是重新思考数据架构。过去一二十年，我们投入了大量精力来组织结构化数据——表格、关系型数据、电子表格。这很好，显然也很重要。但现在 AI 可以处理非结构化数据——文本、图像、PDF、音频，甚至视频——在正确的时间和地点将这些数据提供给 AI 或智能体以创造价值，这比以往任何时候都更有价值。坦白说，我做了很多市场调研。有很多供应商开始谈论处理非结构化数据，但我还没有找到一个让我特别满意的单一解决方案。所以，在我的 AI Fund 和 AI Aspire 团队中，我们进行了一系列疯狂的实验，构建自己的数据重构。如果成功了，我可能会多谈谈。但我确实花了很多时间思考如何重构我们内部的非结构化数据，以便在正确的时间将其提供给智能体使用。我预见到，就像许多企业过去有大型数据架构项目来重组结构化数据一样，未来几年，许多企业将会有价值数千万甚至数亿美元的项目来重新思考数据架构，使数据更 AI 就绪或智能体就绪。

Yeah, this is a great question. When we speak of large businesses, one very common pain point is rethinking the data architecture. Over the last 10, 20 years, we've put so much effort into organizing structured data—tables, relational data, spreadsheets. That's great and clearly important. But now that AI can process unstructured data—text, images, PDFs, audio, maybe video—organizing that to get it to AI or agents at the right time and place to create value is suddenly much more valuable than before. Candidly, I've done a lot of work looking at the market. There are many vendors starting to talk about dealing with unstructured data, but I've not been able to find a single good solution that I'm particularly satisfied with. So within my teams at AI Fund and AI Aspire, we've been running a bunch of crazy experiments building our own data rearchitecture. If it ever works, I'll probably talk more about it. But I actually spend a lot of time thinking about how to rearchitect our own internal unstructured data to get it to the agents for them to use at the right time. I foresee that just as many businesses had very large data architecture projects to reorganize their structured data, over the next few years there will be very large—tens of millions, maybe hundreds of millions of dollars worth—of projects in many businesses to rethink their data architecture to make their data more AI-ready or agent-ready.

他们现有的数据架构存在什么问题，导致它不适合 AI 就绪？

What's the issue with their existing data architecture that doesn't make it AI-ready?

碎片化、治理问题、数据散落各处、没有一致的架构、有些数据存放在某人的笔记本电脑上、权限是为人类设计的而不是为智能体。那么，智能体会继承我的权限吗？我们如何管理治理和可观测性？我觉得我们都见过——很多企业有大量堆积如山的 PDF 文件，过去 20 年没人看过。在金融服务领域，很多文档因合规原因被保留。以前，没人有时间去看它们，但将数据整理出来让 AI 查看，结果发现非常有价值。

Fragmentation, governance, data is all over the place, no consistent schema, some of it sitting on someone's laptop, the permissions were designed for humans, not for agents. So, does the agent inherit my permissions? How do we manage governance and observability? I feel like we've all seen it—so many businesses have massive buckets of tons of PDF files that no one has looked at for the last 20 years. In financial services, a lot of documents are retained for compliance reasons. Previously, there was no point looking at them because no one had the time, but sorting data off for AI to look at turns out to be really valuable.

哦，顺便说一句，有一件小事——这跟整个数据架构无关，但我想 CJ 接下来会发言。我只想说一个我在 AI 编程中学到的小教训，希望 CJ 听到会高兴。我个人经常使用 MongoDB，因为 CJ 的 MongoDB。我们都喜欢关系型数据库，对吧？但我发现，当我在快速迭代和原型开发时，需要重新设计数据库架构非常烦人。而且我们都遇到过那种百分之一的情况，我们让 AI 做数据库迁移，它却聪明地做了别的事，比如删除了整个数据库，对吧？几乎从不发生，但几乎从不发生不等于从不发生，这有点烦人。所以我发现，使用 NoSQL，我可以把任何数据丢进数据库，然后在读取时而不是写入时确定架构，这让我迭代得更快。NoSQL 并不总是能扩展到最大的生产工作负载。所以对于非常大的生产工作负载，企业级应用，最终我会使用更多关系型数据库，更可扩展的解决方案。但我认为 NoSQL 现在比大多数人意识到的更可扩展，它推动了迭代速度。也许我只是太沮丧了，如果我设计了一个数据库架构，然后说‘哦，糟了，我想添加一个字段。’必须重构整个数据库实在太烦人了。所以我认为这些都是我们推动更快迭代的工作流示例，以利用 AI 智能体可以快速编码的事实。所以我们也不要被这些其他事情拖慢速度。

Oh, by the way, one small thing—this doesn't relate to the whole data architecture thing, but I think CJ is speaking next. I'll just say one little lesson I've learned for AI coding, hopefully CJ will be happy I'm saying this. I personally use MongoDB a lot because of CJ's MongoDB. We all love relational databases, right? But I find that when I'm iterating and prototyping rapidly, the need to redesign the database schema is so annoying. And we've all had that one in a hundred times that we ask AI to do a database migration and it does something clever like erase my whole database instead, right? It almost never happens, but the fact that it almost never happens but doesn't never happen is a little bit annoying. So I find that having a NoSQL where I can dump whatever data I want into a database and then figure out the schema when I'm reading it rather than when writing the database lets me iterate much faster. NoSQL doesn't always scale to the largest production workloads. So for very large production workloads, enterprise grade, eventually I use more relational databases, more scalable solutions. But I think NoSQL is more scalable than most people realize these days, and it drives that pace of iteration. Maybe I just get so frustrated if I've designed some database schema and go, 'Oh shoot, I want to add a field.' It's just so annoying to have to refactor the entire database. So I find that these are examples of the workflow that we're all making to drive faster iteration to take advantage of the fact that AI agents can code really fast. So let's not get slowed down by these other things either.

是的，有趣的是，编码智能体不仅改变了我们做的事情，也改变了适合在其上构建的技术选择。我想我代表所有人说，非常感谢你来到这里。感谢你分享所有的想法，感谢你为生态系统所做的一切。

Yeah, it's interesting how coding agents change not only what we do, but also the technology choices that are good for what to build on top of. I think I speak for everyone when I say thank you so much for being here. Thank you for sharing all your thoughts and thank you for all you do for the ecosystem.

谢谢。

Thank you.