本集简介
双语字幕
仅展示文本字幕，不包含中文音频；想边听边看，请使用 Bayt 播客 App。
AI编程是AI的第一个真正大规模市场。
AI coding is the first really large market for AI.
我们什么时候会说这全是智能代理？
When do we say this is all agents?
在价值链的末端，我们只是想知道：这个东西到底行不行？
We just, at the end of the value chain, we're like, does this work or not work?
点击是或否。
Click yes or no.
智能代理比以往任何时候都更需要一个运行这些任务的环境。
Agents more than ever need an environment to run these things.
为人类和智能代理进行上下文工程。
Context engineering for both humans and agents.
它的每一个部分都正在被颠覆。
Every single part of it is getting disrupted.
这不仅仅是像你传统的开发者那样写代码的人被颠覆，而是价值链上的每个人都在被颠覆。
It's not that there's just somebody writing code like your classical developers being disrupted, but everybody along the value chain.
我们重新推出一期来自AI plus a 16 z播客的节目，我们认为它值得获得更广泛的受众。
We're resurfacing an episode from the AI plus a 16 z podcast that we think deserves a wider audience.
a 16 z的合作伙伴杨小莉和吉多·阿彭策尔认为，AI编程是AI首个真正庞大的市场，潜在价值达万亿美元。
A 16 z partners Yoko Lee and Guido Appenzeller make the case that AI coding is the first truly massive market for AI, potentially worth trillions.
他们剖析了开发流程中的变化、ROI首先显现的环节，以及创业者接下来应该打造什么。
They break down what's changing in the dev loop, where ROI is showing up first, and what founders should build next.
希望你们喜欢。
Hope you enjoy.
所以，杨戈，我们刚刚推出了这个我认为非常棒的AI编码环境新DevStack。
So, Yogo, we just launched this, I think, amazing new DevStack for the AI coding environment.
我对此感到非常非常兴奋。
And I'm really, really excited about this.
是的。
Yeah.
我的意思是，让我先从一个高层次的定位说起，为什么我认为这如此令人兴奋。
I mean, the and let me start with a very high order pitch why I think this is so incredibly exciting.
我认为AI编程是AI的第一个真正大规模市场。
I think AI coding is the first really large market for AI.
对吧？
Right?
我的意思是，我们已经看到大量投资涌入。
I mean, we've seen there's a ton of investment that has flown.
而现在，某种程度上，问题在于价值，对吧？
And the question now, to some degree, is about the value, right?
我们为什么要这么做？
Why are we doing all this?
AI编程可以创造巨大的价值。
AI coding can create an incredible amount of value.
如果你想想，全球大约有三千万名开发者。
If you think about this, we have about 30,000,000 developers worldwide, roughly.
假设每位开发者创造十万美元的价值。
Let's say each of them generates $100,000 in value.
在美国，这个数字可能偏低，因为很多开发者的薪酬要高得多。
In The United States, it may be low because many of them get paid a lot more.
但在国际上，这个数字可能偏高。
But internationally, it might be a little high.
但我认为，从数量级上看，这个估算还是成立的。
But I think, in order of magnitude, it holds.
因此，总体而言，我们创造的价值大约是3000万乘以10万美元，即3万亿美元。
So in aggregate, the value we're creating here is about $30,000,000 times $100,000 so $3,000,000,000,000
我甚至会说更多，因为这还只是开发者，还有那些对开发感兴趣的人。
I will argue even more because that's just developers, but then there's also people who are development curious.
他们并不是开发者。
That's They're not developers.
比如，现在设计与工程结合已经变得非常重要。
Maybe they're, I mean, design engineering now is a big thing.
每个设计师
Every designer
产品经理。
Product managers.
你知道的，写代码。
You know, write code.
文档撰写者。
Doc writers.
没错。
Exactly.
是的。
Yeah.
我的意思是，这些影响太多了。
Mean, there there's so many of these effects.
但如果你只看3万亿美元这个数字，这差不多是法国的GDP。
But if you just take the $3,000,000,000,000 figure, that's about the GDP of France.
因此，我们在这里提出的主张，听起来虽然疯狂，但实际上是说：全球第七或第八大经济体的全部人口所创造的价值，大约相当于几家正在重塑AI软件开发生态系统的小型初创公司所创造的价值。是的。
And so so the claim we're making here, crazy as it sounds, is that we're saying the entire population of the seventh or eighth, I think, largest economy on the planet generates about as much value as a couple of startups that are reshaping the AI software development ecosystem Yeah.
还有大语言模型
Plus the LLMs
我们现在看到、触摸和使用的一切都是软件。
And every everything we see and touch and use nowadays are all software.
没错。
That's right.
是的。
Yeah.
所以软件已经颠覆了世界上的一切，而如今软件自身也正遭受巨大的颠覆。
So we've software has disrupted everything in the world, and now software itself is getting massively disrupted.
完全正确。
Totally.
你在博客文章中提到的这一点非常有趣，因为我们现在更能利用大语言模型来生成代码、编写软件。
And then what you mentioned in the blog post is really interesting just because we now are more capable at using LLM to generate code and coding and produce software.
但结果并不是工作变少了。
But then as a result, it's not like it's less jobs.
实际上，生产的软件越来越多。
It's actually more and more software is being produced.
以前，也许作为面向数百人或数千人需求的SaaS服务，现在你可以真正地为每个人量身定制软件。
Before, maybe as a SaaS service catering to hundreds of people's needs, to thousands of people's needs, now you can really just vibe code things software by one for one.
是的。
Yeah.
是的。
Yeah.
我就是这样写代码的。
I vibe code that.
是的。
Yeah.
你就是这样做的。
You do that exactly.
然后我自己写了个邮件过滤器。
And then I vibe code my own email filter.
你知道吗？
You know?
我其实不太用大模型来回复邮件，但我有一个过滤器，可以对标签进行分类，比如这样。
I I don't do so much of using LM to reply to my email, but I have a filter where I categorize the labels, like that.
只针对部分邮件。
Only to some emails.
只针对部分邮件。
Only to some emails.
第一个问题就是，你觉得开发流程正在如何变化？
The first question becomes like, how do you think the development loop is shifting?
我认为答案很复杂。
I think the answer is complex.
坦率地说，这场人工智能革命还处于非常早期的阶段。
And and very frankly, it's so early, I think, in this AI revolution.
我们还没有完整的答案。
We don't have the full answer yet.
对。
Right.
对吧？
Right?
但我们有自己的小技术栈，也就是博客文章中提到的AI之后的软件开发生命周期。
But, I mean, we have our little stack, our little software development lifecycle post AI in the blog post.
我认为从中学到的最大启示是，整个流程的每一个环节都在被颠覆。
And I think the biggest learning from that is probably that every single part of it is getting disrupted.
这不仅仅是传统的开发者在写代码时被颠覆，而是价值链上的每个人都在被颠覆，没错。
It's not that there's just somebody writing code, like your classical developer is being disrupted, but everybody along the value chain Yeah.
都在被颠覆。
Is getting disrupted.
对你来说，最令人惊讶的是什么？
What's the most surprising part for you?
如今在编程领域，哪个部分被颠覆得最厉害？你认为AI接下来会冲击什么？
What's the most disrupted field today in coding, and what do you think AI will come after next?
所以我认为，我们看到增长最显著的，可以说是传统的编码领域，比如集成开发环境中的编码助手，或者更具代理性的编码助手，像Cursors、Devin、GitHub Copilot和Cloud Code这些产品。
So I think, well, we've seen the biggest growth, I think it's safe to say, in the classic sort of coding, IDE integrated coding assistants or more agentic coding assistants, right, the Cursors and Devins and GitHub Copilots and Cloud Codes of the world.
对吧？
Right?
我认为，正是在这个领域我们看到了最大的市场反响和惊人的收入增长。
I think that's where we see the most traction, where we see an incredible revenue growth.
我的意思是，我想说，这个细分领域可能是有史以来所有创业领域中收入增长最快的，这本身就是一个惊人的说法。
I mean, I want to say that segment possibly has the fastest revenue growth of any startup sector we've seen in the history of startups, which is, again, an incredible statement.
所以我认为，这目前是前沿领域，对吧？
So I think this is currently the vanguard, right?
而且每个人都意识到了这一点。
And everybody's aware of it.
我们正看到数十亿美元的收购兼并或收购要约。
We're seeing billion dollar acqui hires or takeover offers.
因此，这是一个极其活跃的领域。
So that's an incredibly vibrant sector.
那么，下一个会是哪个呢？
Now, which one is next?
这是个非常好的问题。
That's a really good question.
所以，具体来说，我们写过一篇关于基本循环的博客。
So to be very specific, in a blog we wrote about the basic loop.
基本循环就是你的计划、你的代码、你的审查。
The basics is your plan, your code, your review.
没错。
Yeah.
大模型在哪里介入呢？
Where does LM coming in?
你认为这个循环的哪个部分最有可能被颠覆？
Where do you think more of the loop would be disrupted?
你觉得这个循环还会和我们以前的基本循环一样，还是会有很大不同？
Do you think the loop will still be the same as what we used to have the basic, or do you think it will look very different?
我认为在这一点上，很难推测最终状态。
I think at this point, it's very hard to speculate about the end state.
但如果你假设你已经看到了这里的这封邮件。
But if if you let's assume you've seen the first email here.
不。
No.
不。
No.
不。
No.
我会说到那里的。
I'll I'll get there.
但如果你看过互联网上发送的第一封邮件，对吧，你可以大致预测我们可能会有网站这些东西。
But if you looked at the first email sent over the Internet, right, you can sort of predict that probably we'll have websites and these things.
也许如果你很厉害，你可以。
Maybe if if you're good, you can.
对吧？
Right?
但你知道，说这种事的最终影响是每个人都可以出租自己的房子，和酒店竞争，然后世界上会出现最大的酒店公司。
But, you know, saying, like, hey, the net effect of this is that everybody can rent out their house and compete with hotels, and there's gonna be the biggest hotel company on the planet.
你会觉得，这有点太离谱了。
You'd be like, well, that's a little far fetched.
但现在我们有了Airbnb，对吧？
But now we have Airbnb, right?
所以这些次要影响，我觉得真的很难预测。
So so these secondary effects, I think, are really hard to guess.
我目前的假设是，我认为我们仍然会需要软件开发者。
My current hypothesis is I think we'll still have software developers.
我觉得他们不会消失。
I think they're not going anywhere.
是的。
Yeah.
对吧？
Right?
我认为他们的工作方式会完全不一样。
I think what they do will look completely different.
对。
Right.
对吧？
Right?
嗯。
Yeah.
坦白说，我认为如今任何顶尖大学教授的计算机科学教育，都更像是一个过时时代的遗迹。
I think the CS education, frankly, any CS class taught today at any major university is probably best seen as this historical relic from a bygone time.
对吧？
Right?
我的意思是，如果你看看最顶尖的初创公司，他们所做的、开发者所处的循环，和以前的做法截然不同，对吧？
I mean, if you look at the best of breed startups, what they're doing, the loop that the developer is in looks so different from what you did before, right?
你有多个代理，你向它们发出提示，告诉它们各种事情，然后把结果拉回到用户界面，试图理解它们做了什么，并试图把它们重新拉回正轨。
You have multiple agents that you're prompting, that you're telling things, you know, you pull that back into UI, you're trying to understand what they did, you're trying to put them back on the rails.
这需要在更高层次上进行更多思考。
It's a lot more thinking at a higher level.
我的意思是，所有的编程本质上都充满了各种干扰，但我觉得我们这里正在实现巨大的飞跃。
I mean, all of coding sort of has been high levels of distraction, but I think we're making a huge leap here.
那么它会是什么样子呢？
So how it's gonna look like?
我完全不知道。
I have no idea.
我的直觉是，我们可能会有更多开发者。
My gut feeling is we'll probably have more developers.
但这种基本的计划-执行循环，我猜可能还会以某种形式继续存在。
But this basic plan execute cycle, there's probably gonna be some flavor of that still around is my guess.
但你觉得呢？
But what do you think?
我最关心的问题之一是，这会是一个逐步循环，还是会融合成一个步骤？
So one of my top questions is that, would this be a step by step loop, or would this mesh into just one step?
举个例子，如果我的代理在编写代码，我是否仍需要亲自审查，还是另有另一个代理负责审查？
So, one example is if my agent is writing a code, do I still need to review it, or do I have another agent that just reviews it?
如果是由同一个代理完成，那么实现细节就是另一回事了。
If it's the same agent, like implementation detail is one thing.
你可以将生成代码的代理与审查代码的代理分离开来。
You can separate out the agent generating code from the agent reviewing code.
但如果生成和审查代码都由代理完成，这是否就只是一个步骤？
But then, if it's all agent, both generating and reviewing code, is it just the same step?
我们是否真的要将这个逐步过程拆解，并让人类参与其中？
Do we actually disaggregate the step by step process and have human in the loop?
而如果作为人类，我编写代码并希望代理来审查，这对我来说是合理的。
Whereas if, as a human, I write code and I want agent to review code, that makes sense to me.
所以我很好奇，什么时候我们应该把某个环节视为一个独立的工具、由代理负责的单独步骤，什么时候又该说，这一切都由代理完成？
So I do wonder when do we pull out something as this is an individual tool and individual step an agent takes care of, And when do we say, this is all agents?
我们只是在价值链条的末端，判断它是否有效。
We just at the end of the value chain, we're like, does this work or not work?
点击是或否。
Click yes or no.
我认为代理能够自主工作的时间段将会变长。
I think the time periods over which an agent can work autonomously will get longer.
你知道，如果有人告诉我，我想为我的跨国企业开发一个完整的ERP系统，我无法想象它能直接运行并返回完全符合需求的软件。
You know, still, if somebody says, look, I want to write a complete ERP system for my multinational enterprise goal, there's no way I could imagine that it'll just run and back come software that actually fits the requirements.
部分原因是，模型仍然远远无法长时间自主运行。
And in part, I think it's a problem that models are still very, very far away from being able to run autonomously for that long.
但另一个问题是，假设这是一个全由人类组成的团队。
But the other problem is, let's assume this was an all human team.
我们在一开始并不会理解所有挑战。
We wouldn't understand all the challenges yet at the beginning.
对吧？
Right?
我们需要重新审视设计。
We'd have to revisit the design.
我们需要重新审视架构，这会带来成本影响等等。
We'd have to revisit the architecture that has cost implications and so on.
所以，在某个时刻，你必须回去找架构师和产品经理，说：嘿，我们原本有个计划A。
So at some point, you sort of need to go back to the architects and the product managers and say, hey, we had a plan a.
但没完全奏效，或者我们发现了新的挑战，所以这是我们的更新版计划A。
Didn't quite work, or we have found new challenges, so here's our updated plan a.
这是你们想要的，你知道的，计划B，对吧？
Is that the you know, and plan b, right, is this what you wanna do?
所以我认为这个循环仍然会存在。
So I I think the loop will still be there.
时间尺度可能会改变，但目前很难准确预测。
The timescales will probably change, but, yeah, it's very, very hard to guess right now.
是的。
Yeah.
我们越来越常看到的一点是，与人类需要频繁介入循环相反，我们实际上开始为代理提供工具，让它们知道自己该做什么。
Another thing we start to see more often is contrary to how much humans need to come and intervene in the loop, we actually start to give agents tools for them to know what they have to do.
一个常见的例子是这个我经常看到的循环。
One example is this loop I see so so often.
比如，代理想要在他们的应用中实现ClerkAuth。
Like, the agent wants to implement, say, ClerkAuth in their app.
于是他们需要去Medlify联系7，询问Clerk的最新版本是什么。
Now they need to go to Medlify and contact 7 to say, what is the latest version of Clerk?
如何正确实现它，以及应该在哪个文件中操作？
How can I implement it correctly and in what file?
我不会把代码复制粘贴给Cursor，也不会交给代理，因为作为人类，我现在太懒了。
I'm not going to copy paste it to cursor or give it to the agent because I'm too lazy as a human now.
代理应该能够自己调用API，将相关信息放入上下文，以使其正常运行。
The agent should be able to call the API themselves to put stuff in the context to make it work.
这只是我们正在观察到的行为变化的一个例子。
This is just one example of what behavior change we're seeing.
以前，作为开发者，我们习惯于反复查阅文档，并告诉代理该做什么。
Because before, as developers, we're so used to go back to the docs and refer to the docs and tell the agent what to do.
现在，代理显然可以直接
Now agents can obviously just
所以我们绕过了中间人。
So we cut off the middleman.
没错。
Right.
我们绕过了中间人。
We cut off the middleman.
我不再需要为这些代理处理所有请求了。
I don't need to route all these requests for the agents anymore.
我认为还有其他例子，比如验证。
I think there's other examples, which is verification.
作为人类，在编写代码或审查他人代码之前，我会先提取代码。
As a human, before I write code or review other's people's code, I pull out the code.
而我做的第一件事其实不是去审查，因为我讨厌读代码。
And then the first thing I do is actually not to review because I don't like reading code.
我不是人肉编译器。
I'm not a human compiler.
我做的第一件事是克隆这个更改，看看它是否还能正常工作。
The first thing I do is to fork the change and see if it still works.
如果它不能工作，我就根本不审查。
If it doesn't work, I just do not review it.
如今，我们有机会为代理提供一个原生环境，先去验证一下：这个代码是否能运行？
Nowadays, there are opportunities to give just agents a native environment to first see, does this work?
用户界面看起来是否仍然良好？
Does the UI still look good?
所有的请求是否都能通过？
Do all the requests don't check
检查？
out?
是否
Did
在人类需要介入审查之前，它就已经破坏了我的构建？
it break my build before the human needs to come in and review?
也许这体现在本地开发过程的某个部分。
Maybe that manifests itself in part of the local development process.
也许它体现在PR审查过程中。
Maybe it manifests itself in the PR review process.
但无论如何，如今代理程序比以往任何时候都更需要一个环境来运行这些内容。
But in any case, now agents more than ever need an environment to run these things.
当我过去为自己写一些东西，比如某个地方需要的小脚本时，我通常不会包含单元测试。
When I used to write something just for myself, like a little script I need somewhere, in the past, I usually didn't include unit tests.
对吧？
Right?
但对于生产代码，情况就不同了。
For production code, it's different.
但对于个人事务来说，你知道，这就像是单个开发者。
But for just personal things, you know, it's like, yeah, that's a single developer.
我知道自己在做什么。
I know what I'm doing here.
对于代理来说，我现在开始加入单元测试，因为它们更容易编写，而且正如你所说，它们能让代理判断他们的更改是否破坏了其他部分。
With agents, I now start including unit tests because they're so much easier to write, and they allow an agent, as you said, to understand if the changes that they did broke anything else.
而且它们可能已经不再了解最初是如何构建的，也无法像以前那样轻松理解，因此这非常有价值。
And they may not have the context how this originally was built anymore and then easily digested before, so that's super valuable.
从整体来看，这种技术能产生多大的经济价值？你认为它在价值链的哪个环节增长最快？
On the grand scheme of, like, how much economic value this generates, where in the value chain do you think it's growing the fastest?
比如，你看到
Like, you see
现在。
Right now.
代理在哪些领域产生的价值远超其他领域，但你觉得哪些领域会是下一个爆发点？
Where the agents is producing so much more value than other areas, but what are the areas you feel like would be the next takeoff?
所以，我每年会和大约一百家企业讨论这个问题。
So, look, I'm I'm I'm I'm talking about a 100 or so enterprises about this per year.
只是当我们把我们的投资组合公司介绍给他们作为潜在客户时。
Just when we, you know, take our portfolio companies to them as potential customers.
我从他们那里听到的是，目前投资回报率最高的使用场景是遗留代码移植。
What I'm hearing from them is that the number one use case in terms of ROI right now is legacy code porting.
对吧？
Right?
这并不令人意外。
It's not super surprising.
比如，这个领域最早的一篇论文来自谷歌。
Like, one of the first papers in the space from Google.
对吧？
Right?
他们写了一篇非常出色的论文，详细描述了做一些非常平凡的事情，比如在一个庞大的代码库中替换某个Java库。
They they wrote a fantastic paper on, you know, where they're detailed on, you know, just doing very mundane things, like replacing a a Java library across a very large code base.
对吧？
Right?
不是数百万行代码那种。
Not, like, millions of lines of code.
对吧？
Right?
所以这是一个非常大的代码库。
So it's very large codebase.
你认为什么是遗留技术栈？
What do you consider as legacy stack?
你认为什么是新技术栈？
What do you consider as new stack?
这完全取决于你。
It totally depends on you.
但对于银行来说，通常是COBOL或Fortran转向Java。
But, I mean, for the banks, it's often COBOL or Fortran to do Java.
哦，COBOL。
Oh, COBOL.
我好久没听到这个词了。
I haven't heard that word for a long time.
你知道吗，我确实在九十年代写过COBOL代码，现在这么说可能暴露年龄了。
You know, I actually wrote COBOL code once in the nineties, and it probably dates me at this point.
好吧。
Okay.
实际上，大语言模型处理COBOL怎么样？
Actually, how are LLMs with COBOL?
它们显然非常擅长。
They're apparently extremely good.
这真是令人惊讶。
That's a surprise.
事情是这样的。
So here's the thing.
对吧？
Right?
如果你用大语言模型编写代码，最难的一件事就是把需求描述得足够精确，对吧？
One of the hardest things, if you implement code with LLMs, is just getting the specification precise, right?
如果我能非常精确地描述一个需求，那么大语言模型通常能很好地实现它。
If I can specify something very precisely, then usually the LL can do a good job at implementing it.
许多公司所做的就是：拿遗留代码，用大语言模型写出一个符合遗留代码的规范，然后说：根据这个规范重新实现，如果有什么不清楚的地方，可以拿原始代码作为参考。
So many of these companies do is they take legacy code, they have an LLM, write a specification that fits the legacy code, and then they say, Reimplement the specification, and you may look at the code as a tiebreaker if something is not clear.
这似乎效果非常好。
And that seems to work incredibly well.
所以我最近听到，从好几个渠道都听说，相比传统流程，这种方式能带来大约两倍的效率提升。
So I'm hearing that today, I heard from several sources now, that you can get about a 2x speed up versus traditional processes for that.
这太惊人了。
And that's amazing.
这导致的结果是，我接触过的那些企业中，大多数表示他们正在加速推进，尤其是那些对此比较精通的企业。
What this has led to is that actually, of those enterprises that I've talked to, the majority says they're currently accelerating at least the majority of those that are sophisticated about this.
他们表示正在加快招聘开发人员。
They're saying they're accelerating their developer hiring.
我们不知道这是否是长期趋势，但目前他们基本上在说：看，我们发现了许多低垂的果实型项目，只需少量前期投入，就能节省基础设施成本。
We don't know if this is a long term trend, but right now they're basically saying, look, because we found so many low hanging fruit type projects where, with a little bit of upfront investment, we can then save infrastructure costs.
这真是太令人兴奋了。
And that's super exciting.
那么，这将对大型机业务还能持续多久产生什么影响呢？
So, you know, what this will mean for the, you know, how much long is the mainframe business going to be around?
或者，我不知道。
Or, you know, I don't know.
但确实出现了一种转变，即遗留代码迁移现在比以前容易得多。
But there's definitely a shift there where suddenly legacy code migration is much, much easier than it was before.
我认为这将改变经典企业软件领域的许多格局。
You know, I think that'll change a lot of the dynamics in the sort of classic enterprise software space.
这很有趣。
That's interesting.
我不禁想知道，我们是否会编写新的主轴代码，因为以前除了专家，没人会编程这些东西。
I do wonder if we will get new mainframe code because now because before, no one knows how to program those things unless be.
是的。
Yes.
没错。
Right.
现在你意识到，你可以用自然语言来编程主轴系统。
And now you realize you can program mainframe using natural language.
是的。
Yeah.
完全正确。
Totally.
所以另一种可能是，底层的遗留编程语言将迎来复兴。
So another possibility is that we get renaissance of, like, the underlying legacy coding languages.
这些编码助手的多功能性真让我觉得不可思议。
It's it's crazy to me how versatile these coding assistants are.
对吧？
Right?
我的意思是，我们正看到它们编写CUDA内核。
I mean, we're we're seeing them write CUDA kernels.
是的。
Yeah.
这可是很难写的东西，对吧？
Which is like is difficult stuff to write by any Yeah.
我试过用一种几乎没有可用训练数据的语言，但它们仍然能根据几个代码示例，大致抽象出代码应该是什么样子。
I've tried them with a language which basically has no usable training data set, and they're still able to sort of abstract, you know, the with a couple of examples, you know, of of how the code will have to look like.
这并不完美，但我认为这绝对是一项非常广泛的技术。
It's not perfect, but so I I think it's it's a very, very broad technology for sure.
最近，就像我们之前讨论的，代码审查。
Recently, it's just like what we were talking about before, code reviews.
因为，正如你所说，大语言模型在编程和生成代码方面非常出色。
Because, like, to your point, LLMs are so good at coding and generating code.
有时候这超出了我们的理解范围。
Sometimes it's beyond our our comprehension.
我们花在审查代码上的时间比代码生成代理还要多。
We'll take more time to review the code than the coding agents.
这没什么好争议的。
Like, there's that's not a controversial opinion.
这就是现实情况。
It's just, like, how it is.
不。
No.
这就是现实。
That's the reality.
是的。
Yeah.
所以这让我思考，我们的开发流程和步骤今后会如何演变。
So it does make me wonder how our development chain and steps are gonna evolve from here.
当我们作为人类无法审查数千行代码时，我们该如何进行代码审查？
How are we going to do PRs when we can't possibly review thousands of code as humans?
那么，现在的正确抽象是代码本身，还是说我们应该审查开发计划？
So does that mean the right abstraction now is still code, or does it mean the right abstraction now is for us to review plans?
如果是这样，GitHub审查还是合适的抽象方式吗？
If that's the case, is GitHub review still the right abstraction for that?
我认为
I think
审查仍然有其作用。
there's still a role for review in general.
我认为问题在于，审查还会由人类来完成吗？
I think the question is, will humans do the review?
比如，现在LLM生成的大部分代码，如果你不是在深度‘直觉编码’的领域，你就会觉得，哦，这只是一个临时的尝试。
Like, right now, most of the code that LLM generates you know, unless you're you're if you're deep in vibe coding territory, you're just like, oh, this is a one off.
我只是想试试看。
I'm you know, I just wanna try something out.
也许那样的话，你就不用审查了。
Maybe then you you don't review it.
你直接点击接受，然后祈祷结果最好。
You just hit accept and hope for the best.
但任何其他情况，你还是会审查的，我仍然逐行审查代码。
But but anything that you know, anything else, you do review the the I still review the code line by line.
话虽如此，我们现在开始看到一些非常好的工具，可以集成到你的后端系统和 GitHub 中。
You know, that said, we're starting to see really good tools that plug into your back end system, your GitHub.
每当有拉取请求进来时，它们都会对其进行分析。
Whenever a pull request comes in, they analyze it.
它们会对此提出评论。
They comment on it.
它们会指出安全漏洞。
They point out security vulnerabilities.
它们会指出规范与实现不一致。
They point out that the spec is different from the implementation.
你知道，它们会指出这会带来依赖关系，而这些依赖可能并不理想。
You know, they they point out that this creates dependencies, which may not be desired.
它们会强制执行编码规范，这非常强大。
They, you know, enforce coding guidelines, which is very, very powerful.
对吧？
Right?
我还没遇到过任何人——如果你遇到过请告诉我——但我还没遇到过任何人说，我们会完全依赖AI来审查代码。
I haven't met anybody yet, and tell me if you have, but but I haven't met anybody yet who basically has said, We're going to rely purely on AI to review code.
对吧？
Right?
只要AI通过了，任何代码都可以提交。
We're just anything can go in if the AI checks off on it.
但我见过一些公司说，以前我们需要两位开发者审查代码，现在只需要一位。
But I have seen, for example, companies that are saying, before we had two developers review code, and now it's one developer.
对吧？
Right?
或者，你知道的，有些情况是AI只是在GitHub的讨论和评论中旁观并发表意见。
And or, you know, cases where basically just the AI hangs out in the sort of in the GitHub, you know, discussion and comments on things.
你知道，如果它们能帮你分配任务的话。
You know, there's if they you know, so you can basically delegate tasks.
你能看看这个吗？
It's like, can you look at this?
我们是不是在其他地方也用了这个库？
It's like, do are we using this library somewhere else?
所以，基本上你可以这么做，因为现在它们有了能帮助处理这些问题的人。
So, basically, you can because now they have somebody who can who can help with these
是的。
Yeah.
这些任务。
These tasks.
我对这个问题的见解是：如果拉取请求本应为我们开发者提供上下文，让我们了解其他编码代理或同事做了哪些改动，那么我认为‘代码审查’这个抽象层次并不合适。
My hot take on this is actually if PR is supposed to give us a context as developers on what did these other coding agents or my colleagues, you know, change that I should be aware of, I don't think code, reviewing code, is the right abstraction.
是的。
Yeah.
因为这可能是功能层面的。
Because it might be feature level.
也可能是性能层面的。
It might be performance level.
所以现在它可能就变成了一行注释。
So now now it might just become a white liner.
这个代理改进了你的 CUDA 实现。
This, you know, this agent improved your CUDA implementation.
也许我根本不了解 CUDA，但我能通过验证感受到改进。
And I maybe I don't even know CUDA, but I know the improvement when I can verify it.
所以对我来说，问题是：我还需要逐行审查 PR 吗？还是只需给我两句话，说明它的运作方式以及测试环境就够了？
So the question for me is, do I still need to go to the PR review every line, or should I just be given, you know, two sentences to know how this works and the environment to test it out?
我会直接合并
And I would just If merge
是那两句有效的表述
it's the right two sentences that works
嗯。
Yeah.
LLM 总能选出正确的那两句吗？
Will the will the LLM always pick the right two ones?
我还不知道。
I don't know yet.
嗯。
Yeah.
确实如此。
That's true.
我的意思是，如果你提供一个环境，问题是：你能根据这两句话验证环境吗？
I mean, if you give an environment the question is, like, can you verify the environment against the two sentences?
嗯。
Yeah.
如果答案是肯定的，那就会更容易解决。
If the answer is yes, that would be easier to solve.
如果答案是否定的，那就更难了。
If the answer is no, you know, that's harder.
但我认为这里还有一个更大的图景，那就是大语言模型在生成代码的文档和描述方面也非常出色。
But I think there's a bigger picture here, though, which is that LLMs are also very good in generating the documentation and description for the code.
对吧？
Right?
所以当我使用像 Cursor 这样的工具进行编程时，它生成代码后，我经常会让它随后更新内部文档。
So when I use something like Cursor for coding, and, you know, it generates code, I often ask it afterwards, and now take the internal documentation and update it.
因为内部文档对我很重要，对编码代理也同样重要，因为它们需要能够引用这些内容；你不可能每次都要把整个代码库塞进上下文窗口里。
Because the internal documentation is important for me, but also for the coding agents because they want to be able to refer to, you don't want every single time to take the entire code base and stick it into the context window.
这效率极低，而且很慢。
It's massively inefficient and slow.
所以，如果你能直接说：‘读一下这份文档，它会告诉你类的层次结构’，然后基于此实现一个新的子类，那就会快得多。
So if instead you can just say, like, read this document that'll explain to you the class hierarchy, right, and then based on that, implement this new subclass, or so it's much, much faster to do.
我认为这里有一个真正的机会，可以让代码的文档比以往更加完善。
And I think there's a real opportunity there to get to much better documented code than previously.
对吧？
Right?
我的意思是，编译器的厉害之处在于它能将高级抽象转化为低级实现，但现在我们有了这样的能力：如果有人已经优化了低级实现，我们可以用它来更新高级抽象。
I mean, you can almost a a compiler is great in that it takes a high level abstraction, translates it into a lower level one, but now we have the ability that if somebody has in hand optimized the lower level one, we can use that to update the higher level one.
这是真的。
That's true.
在人工智能时代，新的编译器是什么？
What is the new compiler in the age of AI?
大语言模型某种程度上就像一个编译器。
LLMs are sort of a compiler.
对吧？
Right?
在某些
In in some
也就是说，它们接受一个高层次的描述并将其细化下去。
way, they they they take a high level higher level description and fill and it down.
我的意思是，我认为
I mean, I think the
最大的缺失是它没有原生的运行环境。
biggest what's missing is it doesn't have a natively have a environment.
编译器告诉你的是：这段代码能运行吗？能编译通过吗？还是不能编译？
Compiler give you does this work, or does it does it compile, or does it not compile?
它不会告诉你这段代码是否能正常运行，而这是个非常主观的问题。
It doesn't tell you does this work, which is a very subject thing.
我觉得说得对。
I I think it's right.
对吧？
Right?
而编译器所强制执行的是对某些规则的严格约束。
And and a, like, a compiler enforces is a strict enforcement of certain things.
展开剩余字幕（还有 348 条）
对吧？
Right?
我可以依赖这个吗？
You you can I can rely on that?
我不知道。
I don't know.
我的意思是，我在用 Rust，东西都会被类型化。
I mean, I'm using Rust, things will be typed.
对吧？
Right?
所以这是一大步前进。
So so that's that's a huge step forward.
对吧？
Right?
然后我可以排除某些错误。
Then I can exclude certain bugs.
使用大语言模型时，情况并非如此。
With an LLM, that's not the case.
对吧？
Right?
不过话说回来，你可能会想，这只是一个初步的现象吗？
Now, that said, you sort of wonder, is this just an initial thing?
我的意思是，随着时间推移，大语言模型可以被赋予一些工具，使它们能够对代码进行语法解析。
Is this just a I mean, LLMs over time like, for example, we can give LLMs tools that allow them allows them to syntactically parse code.
对吧？
Right?
然后，它们突然就能开始对代码进行推理了。
And then now suddenly they can start reasoning about code.
它们可以问：我们是否能确定对象x在这些不同模块中的表示是一致的，即使中间经历了序列化之类的情况？
They can ask, are we sure that the representation of object x is the same across these different, you know, modules, even if it gets serialized in between or something like that.
我并不是有意让这一集变成对GitHub的批评，但GitHub在我们的工作流程中如此核心。
I don't mean to make this episode disaggregating GitHub, but GitHub is so central to so much of our workflow.
对吧？
Right?
所有事情都经过它。
Everything goes through it.
从社交层面发现其他开发者在做什么，到分发软件、下载内容，再到跟踪你所做的更改，Git
From the social aspect of discovering what other developers are doing to distributing the software, you can download things, to keeping track of what you have changed, Git
或者与构建系统的集成，对吧。
Or integration with the build system Right.
后端。
Back end.
是的。
Yeah.
是的。
Yeah.
所以现在我们开始看到，人们现在以非常不同的方式使用Git仓库。
So now another interesting thing we start to see is people use Git repos very differently now.
以前，是人类做一些更改，然后提交，其他人就能看到。
Before, it was like, oh, humans will make some changes, we'll commit it, and then other people will see it.
然后我们打开拉取请求，人们可以看到不同的修订版本。
And then we, you know, open the PR, people see different revisions.
现在代理程序做了太多更改，每一步都提交反而适得其反。
Now agents are doing so many changes, it's kind of counterproductive to commit everything.
而且代码库通常有很低的速率限制，因为它们是为人类使用而设计的。
And then repos usually have very low rate limits because it's designed for humans to use.
所以现在的问题是，新的代码库抽象应该是什么样的？
So now the question becomes, what is the new repo, like, abstraction?
它既要能处理分布式基础设施，又要能支持高频提交。
Like, that handles, like, a distributed, like, infrastructure but also has caters to high frequency commits.
而且有时代理程序在提交时，根本不想永久保留这些更改。
And sometimes when agents doing these commits, they don't even want to preserve this forever.
这更像是一个中间状态步骤，以便它们可以探索五条不同的路径，然后随时回退到其中任意一条。
It's more like an intermediate state step so that they can explore five different paths, you know, but then revert to any of them.
然后当他们满意时，就会回到 GitHub。
And then when they're happy with it, they come back to GitHub.
所以我一直在尝试的一个东西是，有一家叫 Relays 的公司，他们的文档中有一个仓库复制功能，你可以把一个仓库交给代理。
So one one thing I've been playing around with is there's this company called Relays, and then their docs has this repost feature where you can give a repo to the agent.
代理会进来，进行非常高频的操作，这与字节编码代理配合得非常好，体验非常棒。
The agent will, you know, come in and stuff, like, very high frequency, kinda works really well with byte coding agents, and that has been such a great experience.
过了一段时间，我开始看到有人也在内部构建类似的东西。
And in a while, I start to see people building this internally too.
不。
No.
这完全说得通。
It makes total sense.
看。
Look.
如果我们彻底改变了人类编写代码的方式，或者从人类转向将大部分编码工作委托给代理。
If we completely change how humans write code or we're shifting from humans to delegating the the most of the writing to agents.
我认为，假设那些适合人类世界的底层服务仍然适合这个新议程，是愚蠢的。
I think it would be foolish to assume that the underlying services that were a good fit for the human world are still a good fit for this new agenda.
是的，当然。
Yeah, for sure.
对吧？
Right?
这种情况几乎肯定不成立，对吧？
That's almost certainly not the case, right?
在我们的情况下，我们可以做得更好。
We can do better in our cases.
我觉得你说得完全对。
I think you're completely right.
对吧？
Right?
对于源代码仓库，我们需要一种更实时的解决方案。
For for source code repositories, we want something that's much more real time.
老实说，我的意思是，让我们把这个推到极限。
Honestly, I mean, imagine let's take this to the limit.
对吧？
Right?
假设我现在个人正在并行运行100个代理，它们都试图在我的代码库中实现功能。
Let's assume I have now I'm just me personally running 100 agents in parallel that all try to implement features in my code base.
是的。
Yeah.
你可能需要某种机制来协调它们之间的行动。
You probably need some kind of coordination mechanism between them.
它们都不是在试图编辑同一个文件。
They're all all they're all not trying to edit the same file.
当然了。
Oh, for sure.
你知道，rebase 只能帮你到这个程度。
Know, the rebase only carries you so far.
对吧？
Right?
没错。
Yeah.
你会遇到太多冲突。
You you just get too many collisions.
它们都需要共享仓库的内存，因为它们不想每次重新安装依赖项。
All need shared memory on the repo they're working on because they don't want to reinstall the dependencies every time.
没错。
That's right.
是的。
Yeah.
正是如此。
Exactly.
所以，你需要一个更灵活、更实时的系统。
And and so, you know, you probably need something that's much, much more flexible and and and more real time.
而且，你知道，我们还在摸索那到底是什么。
And, you know, I think and we were still figuring out what that is.
Realize 在做这件事真是太棒了。
What Realize is doing this is is amazing.
我认为这不仅适用于 GitHub，GitHub 只是我们使用的大型平台之一。
And I think it's not just true for GitHub, and GitHub is one of the big platforms we use.
但你知道，比如在使用 Confluence 或 Jira 这样的工具进行规范编写时，你可以用到这些。
But, you know, take the specification writing with, you know, say, a Confluence or Jira, for example, what you could use there.
如果你从底层开始设计这些系统，并以 AI 为核心，它们可能会变得非常不同。
If you would develop these systems bottoms up with AI in mind, they would probably look very, very different.
我的意思是，我的任务追踪器是不是应该具备一个功能，能查看代码并相应地更新任务？
Mean, it's like, should my story tracker have a function that looks at code and updates stories accordingly?
我的意思是，没错，这会非常自然。
Mean, yeah, that would be very natural.
所以我认为你可以从这个角度来思考。
So I think you can look at it.
我的意思是，我们在文档方面已经看到过这种情况，对吧？
I mean, think we've seen this for documentation, right?
我的意思是，像Mintify这样的工具在解决文档问题时，与前几代产品截然不同。
I mean, something like Mintify looks very, very different at the at the documentation problem than than previous generations.
我们在测试方面也看到了这种趋势。
Think we're seeing it for testing.
我们在PR审查中也看到了这种变化。
We're seeing it for PR reviews.
我们正在重新思考整个技术栈，这令人兴奋。
We're rethinking this entire stack, that's exciting.
对吧？
Right?
那就是
That's
真的。
true.
我们还观察到另一种行为变化，这非常有趣，因为人类——尤其是开发者——都很懒。
Another behavior change we have seen, which is really interesting because humans like, developers who are very lazy.
没错。
Yeah.
如果我们不需要阅读，就不会去读。
So if we don't have to read it, we do not read it.
我们只阅读文档中相关的一部分。
We only read the relevant parts in documentation.
我们只会粗略浏览内容。
We only skim through things.
因此，我们经常看到的全新行为是，新用户在像Mintify这样的平台上直接提问。
So the net new behavior we see all the time with, you know, documentation, like, hosted on Millify is that users who are net new just go in and ask questions.
没错。
Yeah.
而智能代理不再只是被动地吸收信息了。
And agents do not just ingest it anymore.
他们会直接针对这个上下文进行查询。
They will actually just do a query against this context.
是的。
Yeah.
因此，无论是对人类还是对代理而言，上下文工程都至关重要，因为我们的大脑就像大语言模型，需要上下文，而代理也同样需要上下文，这一点非常关键。
So context engineering for both humans, because we're our brains are like LLMs, so we need the context, and agents who need context, which is a very critical part.
从现在开始，这已成为开发过程中极其关键的一部分。
It's such a critical part of, like, development from here point on.
那么问题来了，你认为代理还需要哪些其他工具？
And then the question becomes, what are the other tools you think agents will need?
比如，我们之前从博客上看到过一张庞大的市场地图，但与以往市场地图所暗示的方向相反，这里展示的是开发者工具。
Like, we had this huge, you know, market map from the blog, and then there's the contrary to where, you know, all the mark previous market map suggests, which is like, here are the developer tools.
现在出现了专门针对代理的工具来提升效率。
Now there are agent tools to make it better.
是的。
Yeah.
在某些情况下，同一个工具同时服务于两者。
In in some cases, the same tool caters to both.
对吧？
Right?
我的意思是，是的。
I mean, Yeah.
这是为代理和人类提供的微型互联网文档。
That's a mini internet documentation for agents and for humans.
对吧？
Right?
所以你看。
So look.
虽然还处于早期阶段，但我认为我们正看到一些主要类别正在浮现。
Early days, but I think we're we're seeing a couple of big categories emerge.
对吧？
Right?
我的意思是，沙盒对于尝试代码片段或构建东西很有帮助。
I mean, sandboxes are helpful to try out, you know, code snippets or build things.
你怎么定义沙盒？
How do you define a sandbox?
我觉得我们整个节目都可以围绕这个话题来录。
I think we can record the whole episode on it,
但我们确实会，我觉得某天我们会的。
but We we and I think we will at some point.
但你看。
But but the look.
归根结底，你需要一个具有特定安全保证的环境，对吧？当大语言模型产生幻觉时，如果它们使用外部来源，可能会被恶意引导去做坏事，而你只是想限制任何坏事发生时的影响范围。
At the end of day, you need an an environment with certain safety guarantees, right, where where LLMs hallucinate, LLMs can be with clever you know, if they use external sources, they can potentially be maliciously prompted to do bad things, and you just wanna have something that basically limits how much the blast radius if anything bad happens.
我觉得我们正在看到一些有趣搜索工具和解析工具，比如 Source Graph 之类的。
I think we're seeing interesting search tools and parsing tools, like something like Source Graph or so.
对吧？
Right?
如果我只在几个文件里写代码，我们不需要这个。
If I'm writing my code in a couple of files, we don't need that.
但如果我们有一个非常大的代码库，突然间问题来了：我们试图替换或向一个被广泛使用的库函数添加一个参数。
But if we have a really large code base, and suddenly the question is, look, we're trying to replace, we're trying to add a parameter to a function in a library that's widely used.
这个库被用在哪些地方？
Where is this library used?
这是一个非常棘手的问题，我的意思是，如果你用的是 Python 之类的语言，你可以把某个东西导入为别的名字。
This is a really hard problem, I mean, it's like if you're in Python or so, you can import something as something else.
所以，简单的查找操作将无法找到这些内容，你可能需要语法解析才能定位它们。
So like, a a simple find operation will no longer find these things, you probably need syntactic parsing to find those.
因此，我认为我们现在正看到一些为智能体优化的文档工具，允许智能体查找这些信息。
So I think we're seeing documentation tools that are optimized for for agents and allow agents to look up these things.
我认为如果智能体能像网页搜索那样操作，那是很好的。
I think it's good for if an agent can do things like web search.
是的。
Yeah.
对吧？
Right?
所以，你知道，我们正在看到这个领域里的公司。
So, you know, we're seeing companies in in that space.
我在这里漏掉了什么？
What am I missing here?
还有更多呢。
There's so many more.
我认为我们还看到了更多专门化的模型。
I think there's the other part of more we're seeing more specialized models.
是的。
Yeah.
我的意思是，对于代码编辑、重新排序文件之类的事情，这显然正在形成一个市场。
I mean, the the for things like code editing or, you know, re ranking files and things like that, right, that's that's definitely shaping up as a market.
如果你退后一步看，如果我们假设这里会产生巨大的价值创造，那很可能就会催生大量初创公司。
If you take a big step back, if if we assume there's massive value creation here, that probably creates an opportunity to create a very large number of startups.
我的意思是，如果十八个月前你问我，或者你二十四个月前问我，我会说，看，开发者工具市场是最小的市场之一。
I mean, if you would have asked me eighteen months back, I would have actually, you had asked me twenty four months back, I would have said, look, DevTools, that's the smallest kind of market.
这个市场能有多大？
How big can this be?
对吧？
Right?
这没什么令人兴奋的。
That's not very exciting.
如果你今天问我，突然间看起来这个市场有可能达到数千亿美元的规模。
If you ask me today, it suddenly looks like this is a market that could go in the hundreds of billions of dollars.
对吧？
Right?
理论上，它有可能达到一万亿美元吗？
In theory, could it go to a trillion?
我不知道。
I don't know.
那么，在这个领域你能创建多少家公司？
So how many companies can you create in that space?
我不知道，但可能有数百家。
I have no idea, but probably hundreds.
随着时间推移，市场会整合，但我认为这将是一个生态系统，而不是一种商业模式。
And over time, it'll consolidate, but I expect this to be an ecosystem, not a business model.
我有个有趣的问题：展望未来，当 GitHub 刚推出时，他们有这个提交图表。
I have a fun question, which is going forward so when GitHub came out, they have this commit charts.
它曾出现在T恤上。
It's it it was on t shirts.
你知道，人们会比较自己的提交图表。
You know, like, people compare their commit charts.
人们甚至会特意提交特定的信息。
People, like, commit specific messages.
所以这些提交图表看起来就像不错的图形。
So the commit charts look like like has a good graphics.
因为提交与开发者带来的价值紧密相关。
What because be before commit commits are so tied to the value developers bring.
比如，你做了多少次提交？
Like, how many commits do you make?
你修改了多少行代码？
How many lines of code do you change?
我的意思是，我们都清楚这并不是衡量价值的最佳指标。
I mean, we all know it's not the best proxy for value.
是的。
Yes.
完全不是。
Not at all.
对。
Right.
那么，GitHub 上下一个提交图表会是什么？
So what would be the next commit chart on GitHub?
那会是什么样子？
What would that look like?
接下来是什么？
What's the next
太棒了。
That's great.
这是个绝佳的问题。
That's an amazing question.
也许可以看你消耗了多少令牌？
Maybe how many tokens you burn?
你来办公室时会不会说，看啊。
Do you come to the office and say, look.
这个周末我消耗了整整一千万个令牌。
Burned, like, 10,000,000 tokens over the weekend.
消耗令牌也可能是因为提示或上下文非常低效，没错。
Tokens burned could also be very ineffective prompting or context Yeah.
我只是把整个代码库
I just stuck my entire code base
放进了上下文
in the context
窗口里，也许吧。
window, maybe.
是你使用的代理数量吗？
Is it the number of agents you use?
是
Is it
这甚至更多
That's even more
游戏数量。
game number.
对。
Right.
但作为开发者，你所交付的价值最接近的单位是什么？
But what is the unit of value that's the closest approximation to what you've delivered as value as developer?
非现金的输入令牌？
Non non cashed input tokens?
不。
No.
这可能太复杂了。
It might be too complicated.
我不知道。
I don't know.
是的。
Yeah.
我已经把这个问题提升到一个更高的层次。
I've taken this to a high level.
我们评估软件开发的指标正在变化，对吧？因为现在大型复杂的重构可能没那么多了，因为我可以让大语言模型来做，这在结构上很容易。
The metrics how we evaluate software development are changing, right, where potentially a big complex refactoring isn't that much work anymore because I can let the LLM do this and it's structurally easy.
在某个非常冷门的领域进行特定优化，而LLM没有相关的训练数据，我可能必须手动完成，这会带来巨大的价值。
A specific optimization in a fairly obscure area where the LLM has no training data, I may have to do by hand and it's vastly more valuable.
所以，是的，这很复杂。
So, yeah, it's complicated.
也许是我的代码应用数量。
Maybe it's number of apps that I've coded.
我觉得还有别的，比如在市场地图的智能体工具箱中，有一个我想要双击查看的模块。
I think something else, which is there's on the market map agent toolboxes, there's actually a box I want to double click on.
那就是智能体编排。
There's the agent orchestration.
你现在不仅可以使用一个智能体，还可以使用多个智能体，甚至同一智能体的多个副本并行执行任务。
You can now use not just one agent but multiple agents, even different copies of the same agent for them to parallel do things.
嗯。
Mhmm.
是的。
Yeah.
这有什么影响？
What's the implication of this?
你能用多个代理协同工作做什么以前做不到的事情？
What can you do with multiple agents orchestrating them together that you couldn't do before?
我的意思是，我们都是注意力分散的开发者。
I mean, we're all very ADHD developers.
我的意思是，我觉得有几件事。
Mean, I think it's there's a couple of things.
当然，工作更快。
Work faster, obviously.
对吧？
Right?
但你也可以并行尝试多种方法，看看哪种效果最好。
But you can also try out multiple approaches in parallel and see which one works best.
我见过一些方法，比如人们想要优化某段代码。
I've seen approaches where people, for example, they want to optimize a certain code.
他们启动几个采用略有不同方法的代理，然后测量哪种方法效果最好。
They fire off a couple of agents with slightly different approaches and then just measure which one works best.
我明白了。
I see.
还有一些初创公司提出以更自动化的方式来做这件事，也就是说，你可以在无人干预的情况下完成这个过程。
And there's some startups proposing doing that in a more automated way even, right, where you would just do this, you know, without human intervention.
你只需说‘优化这段代码’，然后它就会在后台自动启动。
You just say optimize this, and then, you know, this gets kicked off in the background.
但最终这会消耗大量的令牌。
And this all takes a crazy amount of tokens at the end.
对吧？
Right?
顺便说一下，我认为这是一个非常有趣的趋势，三个月前，我根本不记得有人谈论过代码辅助的成本。
So, I mean, by the way, I think this is a really another really interesting trend where three months ago, I don't recall anybody talking about the cost of coding assistance.
对。
Right.
是的。
Yeah.
我的意思是，三个月前，真的什么都没有。
I mean, three months ago, honestly nothing.
你去 CurseSort 的 Reddit 论坛看看，那时候几乎没什么帖子。
You go to a Reddit forum on CurseSort, there was, you know, pretty much nothing posted there.
今天，这已经成为这些论坛里最热门的话题之一，也许是排名第一的话题，因为我觉得我们已经找到了方法：借助强大的推理模型和超大的上下文窗口，单个任务的成本突然变成了几美元。
Today, that's one of the number one topics in those forums, maybe the number one topic, right, because I think we figured out how with high powered reasoning models and very large context windows, we can have single tasks that suddenly cost dollars.
我不确定会不会到几十美元，但至少几美元是完全可行的。
I'm not sure about tens of dollars, but at least, you know, dollars is very, very doable.
这会累积起来，对吧？
And that adds up, right?
这要看情况。
It depends.
如果你是顶尖程序员，也许就不在乎了。
If you're a super high end programmer, maybe it doesn't matter.
如果你不是那种顶尖程序员，每小时几美元的开销也是一笔不小的支出。
If you're anybody else, a couple of dollars an hour, that's a substantial expense.
如果你身处低成本地区，这笔费用可能甚至超过你原本的收入。
If you're in a low cost location, it may end up costing more than what you were making.
过去，如果我在写软件，简单来说，主要的开销就是需要一台笔记本电脑和办公室里的网络连接。
It used to be that if I was writing software, oversimplifying slightly had one expense, which is Okay, they needed a laptop and some connectivity in an office.
但总体而言，真正重要的成本，尤其是在高成本地区，是员工的薪酬。
But in the grand scheme of things, the cost that really mattered, at least in the more high cost locations, was the compensation of the person.
但现在这种情况似乎已经改变了。
That seems to have changed now.
我们突然为软件工程师增加了基础设施成本。
We suddenly have infrastructure costs for a software engineer.
他们需要持续不断地使用LLM的token才能保持高效。
They need the constant feed of LLM tokens to keep them happy.
否则，他们就无法高效工作。
Otherwise, they're not productive.
它们可能会以某种方式改变这个行业，对吧？
They'll probably change the industry somehow, right?
除非我们理解其中的原因，否则很难说。
Think unless we understand how, right?
我们知道人们会构建更多的东西。
We know people will be building more.
这毫无疑问。
That's for sure.
没错。
That's right.
那么问题来了，在某种程度上，构建更多是否与消耗更多令牌相关呢？
And the question becomes, does building more correlate with more tokens burned, to some extent, Right?
我遇到过很多优秀的工程师，他们消耗的令牌量惊人，但效率却非常高。
And I I met so many great engineers who are burning you know, like, they're the top token burning engineer of the company, and they're just so effective.
是的。
Yeah.
他们会有两台笔记本电脑并排放着，用这种方式来编程代理。
They have, like, two laptops side by side and, you know, around coding agents that way.
这就像是从挖土转向操作挖掘机。
It's like the shift from digging versus driving the excavator.
对。
Right.
因为机器会完成挖土的工作。
Because it does the digging.
第一个搜索而不是做
The first search instead But of does
这改变了行业。
that changes the industry.
对吗？
Right?
我的意思是，这个人可能稍微开心一点了。
I mean, probably the person's slightly happier.
对吧？
Right?
我的意思是，那种情况下就是这样发生的。
I mean, that that's what happened in that case.
你需要的人更少了。
You need less of them.
人们会，但你也可以构建更多东西。
People will but but you can also build a lot more.
对吧？
Right?
所以我认为这将会改变这个行业。
So I think it'll it'll change the industry then.
我认为软件会有更多定制化，正如你提到的可以构建更多，因为每个企业总需要一个定制的工具。
I think there's more customization to software, to your point about building more, because there's always one bespoke tool for any business out there.
你知道的，有人力资源软件。
You know, there's HR software.
它涵盖了每个公司80%的需求。
It covers 80% of what every company needs.
剩下的20%，我很清楚，因为我以前是这些企业软件的产品经理。
The 20%, like, I know this really well because I used to be a PM on these enterprise softwares.
我们构建API，让内部团队自己开发他们的版本。
We build APIs, so internal teams build their version.
没错。
That's right.
是的。
Yeah.
现在我们简直是层层叠叠，无穷无尽。
And then now we we just have turtles all the way down.
比如，我们构建基础层，内部团队再建下一层，然后开发者发现：哦，还是不行。
Like, we build the base layer, the internal team builds next layer, and then developers are like, oh, still doesn't work.
那我再自己搞一个。
Let me build something else.
但有了实时编码，我认为定制现在变得比以往任何时候都更容易了。
But now with live coding, I actually think customization is just easier and easier than ever.
你可能根本不需要一个中央团队来使用商业解决方案的API构建这一层。
You may or may not even need a centralized team to build that layer using, you know, a commercial solutions APIs.
你可以像我一样自己直接编写代码。
You can just code it up yourself like what I did.
我一直在思考，下一个工作流程或自动化会是什么。
Something I've been thinking about is what's the next workflow or automation gonna be.
以前，我们有Zapier和其他优秀的RPA工具来实现这些功能。
Like, before, we have, you know, Zapier and other great RPA tools of the world to make it work.
现在有了管道编码，显然你仍需要一定程度的编程知识才能让它运行。
Now with pipe coding, obviously, you still need to know code to some extent to make it work.
这会如何改变呢？
How would that change?
我认为我们最终只会拥有更多在某个地方运行的工作流。
I think we'll just end up having more workflows running south somewhere.
问题是，我们如何才能让那些传统上非技术背景但现在正在编写代码来实现这些功能的新开发者释放潜力？
The question is, like, how can we unlock the net new like, new developers who are not traditionally technical but now are writing code to implement these?
也许他们并不需要图形界面。
Maybe they don't need a graphical interface.
或者如果他们确实需要图形界面，也可以用JSON来表示，这样对代理更友好。
Or if they do need a graphical interface, it can be represented by JSON, which is more agent friendly.
是的。
Yeah.
事实上，我们正开始看到几乎自我扩展的软件。
In in fact, we're starting to see almost self extending software.
对吧？
Right?
一种用户通过提示就能添加额外功能的软件。
Software where a user with a prompt can add additional functionality.
是的。
Yeah.
太对了。
That's so true.
是的。
Yeah.
是的。
Yeah.
这太疯狂了。
And which is crazy.
这是一种趋势吗？
Is that a trend?
我觉得是
Is is that I think it
这是一种趋势。
is a trend.
下一个版本的 Microsoft Word，或者不是下一个版本，而是再往后几个版本，会不会在帮助菜单里加一个‘添加功能’按钮？
Will the next version of Microsoft Word or not the next version, but maybe a couple of versions down the road have a have a, you know, add feature button in the the help menu?
所以我认为，软件的关键在于，由于能够集成大语言模型，软件现在具备了比以往更多的可用性。
So software, I think the takeaway point is software is having more affordance than before because of the ability to integrate LLM.
我的意思是，以前如果我是一家营销公司，我会推出一个功能，让用户能够查看六个图表。
And what I mean by that is before, if I'm a marketing company, I ship a feature so people can visualize six charts.
现在我会提供一个与大语言模型的聊天会话。
Now I ship a chat session with the LLM.
大语言模型可以访问我的数据，并生成代码，以呈现用户想要看到的任何图表。
LLM can reach back to my data, and the LLMs generate code to materialize whatever charts people want to see.
所以这不仅仅是六个图表。
So it's more than six.
而是成千上万种用户可能想看到的内容。
It's like thousands and hundreds and thousands of things that people will want to see.
因此，营销软件的最终用户与大语言模型之间的交互模式，变成了用户可以通过自己的语言（即提示）来实现全新的功能，这与过去软件团队逐个发布功能的方式截然不同。
So the interaction model between end user of the marketing software and LLM becomes it can materialize net new features using their own words, so prompt, which is very different from before software teams that are shipping feature by feature.
那么在这一切之后，你认为人们想要构建什么呢？
So now with all that, what do you think people want to build?
或者你认为开发者应该构建什么？
Or what do you think developers should be building?
你认为世界需要什么？
What do you think the world needs?
它
It
需要太多了。
needs so much.
我的意思是，我确定有两件事。
I mean, there's two things I'm sure about.
一是，可以说，在过去三四十年里，这是在开发领域创办公司的最佳时机。
One is this is, let's say, over the last three, four decades, probably the best moment in time to start a company in the development space.
如果有如此巨大的颠覆，这正是让初创公司能够真正成长、扩展，并与现有巨头竞争的原因。
If you have such a massive disruption, this is what allows a startup to really grow and scale and pick a battle with the incumbents.
我认为我们已经看到了GitHub Copilot的例子，微软率先推出，与排名第一的模型公司OpenAI建立了合作关系。
I think we've seen that with the GitHub Copilot for Microsoft, first in the market, relationship to the number one model company with OpenAI.
你知道，他们拥有最大的源代码仓库。
You know, they have the number one source code repo.
他们拥有最好的集成开发环境。
They have the number one IDE.
他们拥有最优秀的企业销售团队。
They have the best enterprise sales force.
但即便如此，我们仍然看到一大批竞争对手正在非常出色地挑战他们。
And still, we're seeing, you know, a swarm of competitors that are all doing very, very well against them.
这真的是最好的时机。
This is really the time.
我百分百确信的第二件事是，好的点子并非来自风险投资家，而是来自创业者。
The second thing that I'm 100% convinced of is that the good ideas are not coming from the VCs but from the entrepreneurs.
确实如此。
That's true.
没错。
Yeah.
所以，如果你现在发现了一个用AI做得更好的机会，你很可能就能创造价值。
So, you know, if you spot an opportunity to do something better with AI right now, you can probably add value.
对吧？
Right?
然后就是快速执行的问题。
And then it's about fast execution.
就是组建一个优秀的团队。
It's about building a great team.
你知道，关键是跑得非常非常快。
You know, it's it's about running very, very fast.
但我的预测是，我认为我们未来将在这一领域投资数十家公司。
But, you know, my prediction is I think we will we will fund dozens of companies in this space going forward.
是的。
Yeah.
我们非常期待投资下一轮初创公司。
We are excited to just fund the next wave of startup.
但如果你在寻找创意，这里有两个大致的方向。
But if you're looking for ideas, here are two general directions.
第一个是，哪些传统工作流程现在可以被重新设计？
The first one is what are the traditional workflows that you can now reinvent?
它可能不是一对一的。
It might not be one to one.
比如，更好的 Git 可能并不是完全意义上的 Git。
So, like, a better Git may not be Git exactly.
它可能是 Git 加上其他东西。
It might be Git and something else.
对吧？
Right?
然后，如果你像我们在博客文章中展示的那样，把价值链条梳理出来，就可以挑出其中一个环节，决定你要怎么做。
And then if you just map out the value chain like what we have on the blog post, you can pick a box and decide what you want to do with it.
我觉得这是对的。
I think that's right.
是的。
Yeah.
这是一种方法。
That's one way to do it.
另一种方法与以往非常不同。
The other way to do it is very differently from before.
作为产品人员，我们过去只面向人类和其他开发者进行开发。
Like, as product people, we used to only build for humans, other developers.
现在我们实际上为代理（agents）开发了很多东西。
Now we actually build a lot for the agents.
代理才是客户。
Agents are the customers.
代理需要更好的上下文吗？
Does the agent need a better context?
没错。
That's right.
你应该为这一点而设计。
You should build for that.
代理是否希望某些模型的延迟更低？
Does the agent want, you know, lower latency for certain models?
现在有一些公司正在推出代码应用模型，这些模型运行速度更快、准确率更高。
Well, there are companies shipping, you know, code apply models that, you know, operates way faster with higher accuracy.
这也是一个需求。
That's also a need.
当你观察代理尚未发挥作用的地方时，还有很多事情可以做，比如易于恢复的沙盒环境。
And when you look into where agents don't yet work, there are just plenty of things to work on, know, from just like easily resumable sandbox.
我知道已经有一些优秀公司正在构建这些功能。
I know there are great companies already building that.
或者如何让代理能够无缝整合拉取请求审查流程与开发流程？
Or from to like how do you enable the agent to kind of smash PR review process with the development process?
在重新定义代理的工作方式上，还有太多可以创新的空间。
There's just so much more there to reinvent how agents could work.
所以要把代理当作你的客户
So treat agents as your customer
是的。
Yes.
为他们构建。
And build for them.
传统的基础设施。
The classic infrastructure.
对吧？
Right?
是的。
Yeah.
是的。
Yes.
绝对如此。
Absolutely.
不。
No.
我认为现在是创办一家公司的绝佳时机，没错。
I think I think this is really an amazing time to start a company Yeah.
在这个领域。
In this space.
没错。
Yeah.
感谢您收听 this episode of the a16z 播客。
Thanks for listening to this episode of the a 16 z podcast.
如果您喜欢这一集，请务必点赞、评论、订阅、给我们打分或留下评价，并与您的朋友和家人分享。
If you like this episode, be sure to like, comment, subscribe, leave us a rating or a review, and share it with your friends and family.
如需收听更多集数，请前往 YouTube、Apple Podcasts 和 Spotify。
For more episodes, go to YouTube, Apple Podcasts, and Spotify.
在 X 上关注我们 @a16z，并在 a16z.substack.com 订阅我们的 Substack。
Follow us on x at a sixteen z, and subscribe to our Substack at a16z.substack.com.
再次感谢收听，我们下一期再见。
Thanks again for listening, and I'll see you in the next episode.
提醒一下，本内容仅作信息参考，不应被视为法律、商业、税务或投资建议，也不应用于评估任何投资或证券，且并非针对任何a16z基金的投资者或潜在投资者。
As a reminder, the content here is for informational purposes only, should not be taken as legal business, tax, or investment advice, or be used to evaluate any investment or security, and is not directed at any investors or potential investors in any a sixteen z fund.
请注意，a16z及其关联方可能也持有本播客中讨论的公司的投资。
Please note that a sixteen z and its affiliates may also maintain investments in the companies discussed in this podcast.
如需更多详情，包括我们的投资链接，请访问a16z.com/disclosures。
For more details, including a link to our investments, please see a 16z.com/disclosures.
关于 Bayt 播客
Bayt 提供中文+原文双语音频和字幕，帮助你打破语言障碍，轻松听懂全球优质播客。