Waste Tokens, Save Time

频道: Naval
视频: https://www.youtube.com/watch?v=aiyf-5jmYf0
原文语言: en
统计: 共 22 轮 · Naval 4 · Guillermo Rauch 10 · Max Hodak 8

[0:00] Naval

Welcome. You're listening to the Naval Podcast, your authoritative source for new knowledge. We're trying something new today. Uh I have three frontier founders with us. Um three good-looking guys actually and a fourth good-looking guy, Naval. And let me just introduce everybody. Gumo the G Roush. He's building Versel into an AI cloud for the world of agents and whatever comes after that.

欢迎。你正在收听的是 Naval Podcast，你获取新知的权威来源。今天我们要尝试一些新东西。我请来了三位 frontier founders（前沿创业者）。嗯，三位长得都挺帅的家伙，再加上第四位帅哥 Naval。我来逐个介绍一下。Guillermo Rauch，他正在把 Vercel 打造成一个面向 agents 世界以及未来一切的 AI 云平台。

[0:25] Naval

Good to be here. Blake Shawl, he's building supersonic aircraft in his own factory and jet engines as well. Blake's company, Boom Supersonic. And then Max Hodak from science. He's building a biohybrid brain interface that grows living neurons on silicon to restore sensory functions like sight, but then eventually to explore new parts of the brain and new senses. All three of these guys are not composing their products with off-the-shelf parts. They're building their own factories. And you know, we don't care as much about what they're building exactly as we do about what they're learning about how they're building. What's the new knowledge they're generating? What's their alpha? What principles are they discovering that other founders can learn from? What are they trying to figure out right now? And also, what are the cutting edge or crazy ideas that they haven't even talked about yet and they're still forming in their brains? Naval, do you have any reactions to any of that before I jump into GMO? Yeah, let's just have fun.

很高兴来到这里。Blake Scholl，他在自己的工厂里造超音速飞机，连喷气发动机也自己造。Blake 的公司是 Boom Supersonic。然后是来自 Science 的 Max Hodak，他在做一种 biohybrid（生物混合）脑机接口，在硅片上培养活的神经元，用来恢复视觉之类的感官功能，最终还要去探索大脑的新区域、开发全新的感官。这三位都不是用现成零件来拼凑自己的产品的，他们都在建造自己的工厂。而且你知道，我们其实并不太关心他们具体在造什么，而更关心他们在「怎么造」这件事上学到了什么。他们正在产生哪些新知识？他们的 alpha（独到优势）是什么？他们发现了哪些其他创业者可以借鉴的原则？他们现在正在琢磨什么问题？还有，他们脑子里还有哪些前沿的、甚至疯狂的、还没对外讲过、还在成形阶段的想法？Naval，在我开始聊 Guillermo 之前，你对这些有什么想说的吗？嗯，咱们就放开了玩吧。

[1:26] Naval

Yeah, you guys should just jump in.

对，你们几个直接插话就行。

[1:28] Guillermo Rauch

Yeah. So, I can't remember my exact quote, by the way, but I've been really pilled uh with this idea of software factories and the job of the engineer being something that you just show up to work. You used to used to ship the output directly and everything inside the company was, you know, how good is person A at shipping output B. And now what's happening is the way that I'm judging you as an engineer is like are you producing the factory that will produce multiplicative outputs B to through Z, right? Um, and that's a that's a pretty significant change because basically like we used to believe and used it to be somewhat controversial that there's 10X engineers like now clearly there's 100x or a thousandx engineers and the world hasn't fully adjusted to this. I I used to get flamed on Twitter for saying they're 10x engineers cuz you know it flies in the face of so much like equality philosophy that everyone's equal. But the reality is when you're operating in idea domains, when you're operating intellectual domains and virtual digital domains, it's not even 10x, it's 100x or thousandx. It always has been.

对。顺便说一句，我记不清自己原话到底是怎么说的了，但我最近彻底被一个想法洗脑了，就是「软件工厂（software factories）」这个概念，以及工程师的工作正在变成另一种东西。以前你来上班，直接交付成果（output），公司内部衡量的就是「A 这个人产出 B 这个成果做得有多好」。而现在正在发生的是，我评判你这个工程师的方式变成了：你有没有在打造那个能产出 B 到 Z、能成倍放大产出的「工厂」？这是个相当重大的转变。基本上，我们以前相信、而且当时还算有点争议的，是世界上存在所谓的「10x 工程师」；而现在显然已经有 100x 甚至 1000x 的工程师了，世界还没完全适应这一点。我以前在 Twitter 上说有 10x 工程师，都会被人喷，因为这跟「人人平等」那套哲学太冲突了。但现实是，当你在「想法领域」、在智力领域、在虚拟数字领域里工作时，差距根本不止 10 倍，而是 100 倍、1000 倍。一直都是这样。

[2:29] Guillermo Rauch

Satoshi Notch, you know, the guy who invented JavaScript, the Brendan Iikes of the world, uh John Carmarmac, I mean, these are thousandx programmers. Not to even mention, if you choose the right thing to work on versus the wrong thing to work on, that's an infinity difference. And it could just be not even a better programmer, just one who had a better judgment on what to work on in the first place. And now obviously it's less controversial because of uh AI leverage.

Notch、发明 JavaScript 的那个人、Brendan Eich 这种级别的人物，还有 John Carmack，这些都是 1000x 的程序员。更别提，如果你选对了要做的事、而不是做错了方向，那差距简直是无穷大。而且做出这个差距的人甚至不一定是更厉害的程序员，可能只是一开始在「该做什么」上判断力更好的那个人。当然，现在因为有了 AI 这个杠杆，这个观点已经没那么有争议了。

[2:52] Naval

What's controversial is the the token leaderboards, right? Like people are still getting a little confused because now they think, well, I have a bunch of 100x engineers. Look at all these tokens that I'm paying for. I'm curious if you guys have seen the same like how do you measure ROI?

现在真正有争议的是那些「token 排行榜（token leaderboards）」，对吧？大家还是有点犯迷糊，因为现在他们会想：好吧，我手底下有一堆 100x 工程师，可你看我为这么多 token 付了多少钱。我挺好奇你们有没有遇到同样的情况，你们是怎么衡量 ROI 的？

[3:08] Max Hodak

It's like the old measuring lines of code. You know, token consumption lines of code feel like similarly not direct paradigms. I mean my observation has been that claude or cha GPT um or GPT is about is basically as good as you are in a domain and so uh if you're if you're a really capable developer then these things are really powerful and if you're a junior developer then you'll kind of find it to be like more of a junior developer like on the one hand these models are incredibly capable on the other hand the feedback that you give them sporadically seems to be incredibly important and these little updates seem to totally determine the types of uh performance you get out there's a new kind of support that I give which is you come to me and like you didn't get good output out of the model and I tell you what to prompt the model with. So like the idea of like the quality of the reprompting which I think you're alluding to is is extremely important.

这就像以前拿代码行数来衡量一样。你知道，token 消耗量和代码行数感觉都是同样不靠谱的衡量范式。我的观察是，Claude、ChatGPT 或者说 GPT，在某个领域里的水平，基本上跟你自己的水平差不多。所以如果你本身是个很厉害的开发者，这些工具就会非常强大；如果你是个 junior 开发者，那你会发现它们用起来也更像个 junior 开发者。一方面，这些模型的能力强得惊人；另一方面，你时不时给它们的反馈又显得极其重要，就这些小小的修正，似乎完全决定了你能从中得到什么样的表现。现在我们团队里出现了一种新的支援方式：你跑来找我说，你没从模型那儿得到好的输出，然后我告诉你应该怎么去 prompt 这个模型。所以「重新 prompt 的质量」——我想这也是你刚才在暗示的——是极其重要的。

[4:00] Guillermo Rauch

But I mean and to be clear I think that this will become less important over time like as the models get much much smarter then you'll be able to put in less and get more out. Um but at least at this stage it really seems to kind of reflect back the judgment that the user brings in in my experience. I've kind of resisted learning all the ticks and tricks and tips like you know there was uh oh use Ralph Wigum, use Open Claw, use Hermes, use this prompt engine, use this scaffolding, plug in this piece, you know uh always use plan mode. I just ignored all of that. I just assumed the model's just going to get better faster than I would figure out how to use it. It would figure out how to use me faster than I would figure out how to use it. And so I've just been completely hamfisted with them and I get frustrated at them and just sort of I I found myself typing less and less information and doing less and less work as time goes on with the models because I just assume I can brute force my way through it. And I'll throw Codex Claw and Gemini at the same problem over and over and just waste tokens to save time. And I think no matter how expensive these models might seem, they're still way cheaper than a human. So I would say just waste tokens, save time. Don't look at the tokens either as inputs or outputs. Just look at your time and look at the final output. And even if they're writing lowquality code, which I know in many cases they are. It's not necessarily production quality or scalable code. When the time comes and I want to ship it to production, I'll just throw more tokens at it. I'll say, "Okay, now go through look at it, rewrite it, and they're just going to get better every generation." Uh, so yeah, I don't I don't see where this necessarily stops. As long as we have verifiable domains and solve problems, they're going to resolve those problems. That's in the unsolved problems domain where maybe you're Terrence Tower you're at the cutting edge of creativity that you need to be you know working very collaboratively and carefully and closely with the model but I'm not in that I'm not at that level in software engineering and gear you're probably the most extreme software engineer in the team right like out of this set you're probably the one who most hardcore came up from a software background like how are you finding these models at the edge of their capability? Well, there's one thing that's happened recently that uh what you're saying resonates strongly with, which is it used to be that you would give a prompt to the model and it kind of does it like classic like next token prediction thing and it like runs away with your idea. And models now have been doing this like intuitive planning mode without to your point not even having to plan where it comes back to you and says look what you're asking me for there's these three routes we can take. there's this set of tradeoffs that we're going to go down. That's a moment where like you know people do the whole thing on X like oh now we have a PhD level engineer model like that's very clear that the models at some point graduated. They used to be junior engineers now they're principal engineers because they come back to you with a set of tradeoffs and obviously sometimes they which is hilarious. It tells you this one is going to take three weeks and this interest it make really bad predictions but clearly it's now this like I respect the models a lot more as a as a peer like that I'm going back and forth intellectually with but there there are a lot of gaps still so like if you're really really proficient engineer or architect you I think you're still extracting more juice so the question sort of that Max was positing of like if you're junior do you get junior back. Well, clearly not because a junior gets more advanced knowledge in code they they would have never been able to write by themselves, but doesn't an experienced architect get 10x whereas a junior engineer gets 2x? That's what I'm kind of trying to figure out still.

不过说清楚一点，我觉得随着时间推移，这件事会变得越来越不重要。等模型变得聪明得多以后，你就能输入更少、得到更多。但至少在现阶段，它真的很像是把用户带进来的判断力反射回来。我个人一直有点抗拒去学那些小窍门、小技巧、小贴士，你知道的，什么「用 Ralph Wiggum」、「用 Open Claw」、「用 Hermes」、「用这个 prompt 引擎」、「用这套脚手架」、「插上这个组件」、「永远开 plan mode」之类的。我把这些全都无视了。我就假设，模型自己变好的速度，会比我搞清楚怎么用它的速度更快；它搞清楚怎么用「我」的速度，会比我搞清楚怎么用「它」更快。所以我对它们一直特别简单粗暴，被它们搞烦了就直接发火。随着时间过去，我发现自己输入的信息越来越少、做的活儿越来越少，因为我就假设我可以靠蛮力（brute force）硬怼过去。我会把 Codex、Claw（Claude）和 Gemini 全都扔到同一个问题上，反复地试，纯粹是「浪费 token 来节省时间」。我觉得不管这些模型看起来多贵，它们还是比人便宜得多。所以我的建议就是：浪费 token，节省时间。别去盯着 token，不管是输入还是输出，只看你自己的时间，只看最终的成果。哪怕它们写出来的是低质量代码——我知道很多时候确实是，不一定是生产级的、可扩展的代码——等到我真要上生产的时候，我就再砸更多 token 进去，我会说「好，现在从头过一遍、重写它」，而且它们每一代都在变好。所以，是的，我看不出这件事必然会在哪儿停下来。只要我们处在可验证（verifiable）的领域、能解出来的问题上，它们就能把这些问题解掉。真正还得你深度参与的，是那些尚未解决的问题领域——也许你是 Terence Tao（陶哲轩），站在创造力的最前沿，那你确实需要跟模型非常协作、非常小心、非常紧密地一起干。但我不在那个层级，至少在软件工程上我没到那个程度。Guillermo，你大概是我们这群人里最硬核的软件工程师，对吧？这一拨人里，你应该是最纯正从软件背景出身的，那你觉得这些模型在能力边界上表现如何？嗯，最近发生了一件事，跟你刚才说的特别有共鸣。以前你给模型一个 prompt，它就「啪」地干起来，典型的下一个 token 预测（next token prediction），然后顺着你的想法一路狂奔。而现在的模型开始进入一种「直觉式的规划模式」，正如你所说，它甚至不用专门去 plan，就会回过头来跟你说：看，你让我做的这个事，有这么三条路可以走，每条路有这样一组取舍（tradeoffs）。这种时刻，就是大家在 X 上鬼哭狼嚎「我们现在有 PhD 级别的工程师模型了」那种感觉——很明显，模型在某个节点上「毕业」了。它们以前是 junior 工程师，现在是 principal（资深首席）工程师了，因为它们会带着一组取舍回来找你。当然有时候它们……这就很搞笑了，它会告诉你「这条要花三周」，做出一些非常离谱的预测。但很清楚，现在我对模型尊重多了，把它当成一个可以来回切磋的同行（peer）。不过还是有很多缺口，所以如果你是个非常非常熟练的工程师或架构师，我觉得你还是能从中榨出更多东西。所以 Max 抛出的那个问题——如果你是 junior，是不是只能得到 junior 级的回报？显然不是，因为 junior 能拿到他自己根本写不出来的更高级的代码知识。但反过来说，一个经验丰富的架构师是不是能拿到 10x，而 junior 工程师只能拿到 2x？这是我现在还在琢磨的问题。

[7:35] Max Hodak

Yeah. Yeah. But I mean I think there's there's architectural decisions. So when you think about the development, I'm seeing this now with some of our the junior software engineers on the team of like what is the next step in their career progression, it's going from like writing implementation for a feature to picking technologies like choosing between Postgress versus some other database or picking between ZMQ versus some other message Q or like some other queuing system

对，对。不过我觉得这里头有架构层面的决策。我现在在团队里一些 junior 软件工程师身上看到这一点：他们职业进阶的下一步是什么？是从「为某个功能写实现」，进阶到「选技术」——比如在 Postgres 和别的数据库之间做选择，在 ZMQ 和别的消息队列、或者别的排队系统之间做选择。

[7:57] Max Hodak

and those I mean the models can suggest them but that's the thing where you'll see it and you'll be like no no I want to use this other thing. That's the type of little feedback that I'm saying really matters in the types of output that you seem to get at this point. Taste and judgment, right? Taste and judgment. That said, you can ask them which one should I use and why and they know everything. They'll give you really good trade-offs.

而这些决策，模型当然可以给出建议，但关键就在这儿：你一看就会说「不不不，我要用另外那个东西」。这就是我说的那种「小反馈」，它在现阶段真的会显著影响你得到什么样的输出。这就是品味和判断力（taste and judgment），对吧？品味和判断力。话虽如此，你也可以问它们「我该用哪个、为什么」，它们什么都知道，会给你非常好的取舍分析。

[8:15] Guillermo Rauch

That's the change I was saying has happened recently where you would say, hey, go and um put this super high cardality telemetry data into Postgress and it's like bro like we don't put that kind of data into Postgress like you should consider click or Athena or whatever. Like that's happened to me a lot which is really impressive. Um, but I the the thing I'm still like kind of struggling with is clearly the human is still completing the model. Like at one point is it the other way about like the the human is the one sort of getting the instructions back on like go get me this API key because it's something that only you can do. Uh or get me this amount of capital for my next set of investments that I need to make. Uh you just watch like that. Clearly we're still not there yet. That's a temporary aberration. Pretty soon, every good SAS company or hosting provider will have a CLI and API interface that the models can be made directly. They don't even necessarily need an API like as long as it's like textbased, Unix based, the agent can hack its own API. And then the money part, you insert crypto tokens, you know, put in Bitcoin, put in whatever, and the model goes and just pays for whatever it needs. And I think like

这就是我说的最近发生的那个变化。比如你说「去把这份基数超高（super high cardinality）的遥测数据塞进 Postgres」，它会说「哥们儿，这种数据我们不往 Postgres 里塞的，你应该考虑 ClickHouse 或者 Athena 之类的」。这种事我遇到过很多次，真的挺让人惊艳。但我现在还有点纠结的一点是：很明显，现在还是「人在补全模型」。到哪个时间点会反过来，变成「人」才是那个收到指令的一方——比如「去帮我搞到这个 API key，因为这事只有你能干」，或者「去帮我筹到这笔钱，我下一轮投资要用」？你就看着吧。显然我们现在还没到那一步，这只是个暂时的反常现象。很快，每一家像样的 SaaS 公司或托管服务商都会提供 CLI 和 API 接口，让模型可以直接对接。它们甚至不一定需要 API——只要是基于文本、基于 Unix 的，agent 就能自己把 API「黑」出来。至于钱的部分，你插入加密 token，放点 Bitcoin、放点什么都行，模型就自己去为它需要的东西付钱。我觉得就像……

[9:28] Guillermo Rauch

you know there people working on this

你知道，已经有人在做这个了。

[9:30] Guillermo Rauch

but the thing I am now thinking through is is pure software dead

但我现在在思考的问题是：纯软件是不是已经死了？

[9:35] Guillermo Rauch

like is pure software engineering like an obsolete thing it's like saying speaking English right the models now speak English we had to learn code to communicate with the models now the models speak English and they speak fuzzy sloppy English like a human and they understand things so where's the moat like for a founder hardware it's a boon you know like now you had to build hardware. It was hard to build a software company alongside. Like Patrick Cullison says, software is art and it's hard to hire artists. So now as a hardware founder, great, you can have really good software develop fairly quickly. Um, if you're creating models, maybe that's the new software engineering, training models and tweaking models and post-raining and fine-tuning models. But classic software engineering, is that dead? Is pure software investable? Is pure software something you organize a company, a team around and try to get some leverage? Did you guys see the uh there was an article on X by Mitchell Hashimoto called the block economy or the building block economy something like that like his argument is that the most useful thing for agents to have now is really powerful reusable building blocks because to Max's example you wouldn't expect your clanker to reinvent a Q infrastructure system every time it needs to send an email it needs to bring in the right building block that's right size for the task ask that you're asking for and you say well okay for this one it's B MQ I challenge the notion that I would want the agent to reinvent the entire universal first principles in a way that's incompatible with the rest of society and civilization like it's almost like reinventing highways laws policies etc just for you even if there's a potential for extra optimization extra juice that you can get out of it there's a still a um sort of like cooperation at large scale value of saying we're both depending on Postgress 13.2 too. And so that's still really really really valuable. I would say like the category of infrastructure software and building blocks that these agents are going to use obviously in bias is this what we're building. It seems extremely valuable and I I don't see the agent anytime soon. And by the way, you could even another metaphor I've been using is like a already been created that the models can reuse. It's like a token cache because you you don't want to churn through a trillion tokens to reproduce what's already existing. Uh and so there's always starting points that the model can fork off from, but it's going to change things quite profoundly.

纯软件工程是不是已经成了一件过时的事？这就好比说「讲英语」，对吧——模型现在会讲英语了。我们当初得学写代码才能跟模型沟通，而现在模型会讲英语，而且它们讲的是那种模糊、随意、跟人一样的英语，还能听懂意思。那护城河（moat）在哪儿呢？对一个创业者来说，做硬件反倒成了利好。你知道，以前你得造硬件，同时再去搭一个软件公司就特别难。Patrick Collison 说过，软件是一门艺术，而招艺术家很难。所以现在作为一个硬件创业者，太好了，你可以相当快地把很好的软件开发出来。如果你是在训练模型，那也许「训练模型、调模型、做 post-training、做 fine-tuning」就是新的软件工程。但传统的软件工程，是不是死了？纯软件还值得投吗？纯软件还值不值得你围绕它去组织一家公司、一个团队，去争取某种杠杆？你们看到 Mitchell Hashimoto 在 X 上那篇文章了吗，叫《the block economy》还是《building block economy》之类的，他的论点是：现在对 agents 最有用的东西，是真正强大、可复用的「构建块（building blocks）」。因为拿 Max 那个例子来说，你不会指望你的 clanker（指 agent/机器人）每次需要发封邮件时，都从头重新发明一套队列基础设施。它需要的是把那个对你要做的任务来说「大小正合适」的构建块拿进来，然后你说「好，这个场景用 RabbitMQ」。我不认同那种「我希望 agent 用一种跟整个社会、整个文明都不兼容的方式，从头重新发明全部第一性原理」的想法。那几乎就像专门为你一个人重新发明高速公路、法律、政策等等。哪怕这样确实有可能榨出额外的优化、额外的好处，但「我们俩都同样依赖 Postgres 13.2」这种大规模协作的价值仍然在，而且非常非常有价值。所以我会说，这些 agents 将要用到的「基础设施软件」和「构建块」这个品类——当然我有偏见，因为这正是我们在做的事——它看起来极其有价值，我也看不出 agent 在短期内……顺便说，我一直在用的另一个比喻是，这些东西就像一个「token 缓存（token cache）」——因为你不会想为了重新造出已经存在的东西，去烧掉一万亿个 token。所以总有一些现成的起点，模型可以从那儿 fork 出去往下做，但这会非常深刻地改变很多东西。

[11:57] Max Hodak

So these are like libraries and dependencies, but for models.

所以这些东西就像是库（libraries）和依赖（dependencies），只不过是给模型用的。

[12:00] Guillermo Rauch

Yes. For agents specifically.

对，具体说是给 agents 用的。

[12:03] Max Hodak

To Naval's question though, I mean I learned a program when I was really little. And I like that was the thing that through all of like being a teenager and in my 20s like I get like sucked into it and just like code for like 20 hours and it was super fun and I knew all this stuff about programming languages. I haven't written a single line of code in quite a while now. And I mean, partly that's because my job is different, but also since December, I've built a huge amount of software that I now use every day. There's all these projects that I've kind of fantasized about for years that now I'm like using um that I've actually built and I didn't write any of that. And I just can't imagine going back to like actually writing code by hand anytime. Like I mean I'm unlikely to do that anyway, but just like in general, I see that I have a hard time seeing that as part of the future.

不过回到 Naval 的问题，我是很小的时候就学了编程。在我整个青少年时期、二十多岁那会儿，编程一直是那种能把我整个吸进去的事，我能一口气写 20 个小时代码，超级好玩，关于编程语言我什么都懂。但现在我已经有相当长一段时间没写过哪怕一行代码了。当然，部分原因是我的工作变了，但另外，从去年 12 月以来，我自己搭出了海量的软件，现在每天都在用。有一堆我幻想了好多年的项目，现在我居然真的在用了，是我亲手「建」出来的，可那些代码我一行都没写。我实在没法想象自己以后还会回去手写代码。我是说，反正我本来也不太可能去写了，但总体上，我很难把「手写代码」看成是未来的一部分。

[12:46] Guillermo Rauch

Yeah. There's something really cool is that you understand how the pieces click together. Like I feel like anyone that understands what an API is and how data flows, inputs and outputs, performance because you kind of you have to orient the model around like this is certain level of expectation that I have out of this operation like that's that's always been infinitely more useful than um than writing code. Like I feel like a really good a proficient engineering leader has been quote unquote like vibe coding through people on Slack or one-on- ones because you're transmitting your will, your intent, your experience, and you're letting others run with it. Uh it's just that now we do the same but with agents. Uh and so I think that's why you've been successful with it. But I don't know that everyone sees the same level of success. I mean, I went from not having written code in 20 years to I'm coding all the time now, but through agents and I'm building tons of software and it turns out that just understanding the basic principles of software engineering and algorithms actually gets you a long ways because the reason I stopped coding was because I didn't have time to figure out the latest language, latest architecture, infrastructure pieces to plug into. and overcell makes it a lot easier, but even then just getting started was a bear. Like just plugging pieces together, assembling infrastructure was just so annoying.

对。有件事特别酷，就是你理解这些零件是怎么拼到一起的。我觉得任何一个懂「API 是什么」、懂数据怎么流动、懂输入输出、懂性能的人——因为你得给模型定个方向，告诉它「我对这个操作有这样一个层次的预期」——这种能力，一直都比单纯会写代码有用无穷倍。我觉得一个真正出色、熟练的工程负责人，其实早就一直在通过 Slack、通过一对一沟通对着「人」做 vibe coding 了，因为你是在传递你的意志、你的意图、你的经验，然后让别人拿着去跑。只不过现在我们对 agents 做的是同一件事。所以我觉得这就是你为什么用得这么成功。但我不确定每个人都能取得同样程度的成功。我自己也是，从 20 年没写过代码，到现在天天在写——但都是通过 agents——而且我在搭海量的软件。结果发现，只要理解软件工程和算法的那些基本原理，其实就能让你走得很远。我当初不写代码了，就是因为我没时间去搞清楚最新的语言、最新的架构、最新的、要插进来的基础设施组件。Vercel 让这件事简单多了，但即便如此，光是「起步」就够呛。光是把各种零件拼起来、把基础设施组装起来，就烦死人了。

[14:06] Max Hodak

The thing that really changed is I mean it used to be that you could build a lot like you like there's a lot that was straightforward, but then you would hit some random thing and then you could spend

真正变了的一点是……我是说，以前你能搭出来很多东西，有很多部分都挺直接顺畅的，但接着你会撞上某个莫名其妙的问题，然后你可能就得花……

[14:16] Max Hodak

kind of some indefinite period of time debugging some narrow thing. And now with the agents, what happens is you just don't get stuck anymore, which is pretty amazing.

……花上一段不知道多久的时间，去调试某个很窄的小问题。而现在有了 agents，结果就是你再也不会卡住了，这相当神奇。

[14:24] Guillermo Rauch

Or they get stuck.

或者是它们卡住了。

[14:24] Max Hodak

It's removed. Well, no. I mean, like relatively quickly they can find like the right way to do things. And it used to be that like I remember when their friends learned a program be like, "Nope, it's just like intrinsically frustrating like if like that's part of the deal, that's how you learn." And that just isn't true anymore.

这种卡顿被消除了。嗯，不对。我是说，它们能相对快地找到正确的做法。以前是这样的——我记得我那些朋友刚学编程时会说「没办法，这本来就是内在让人抓狂的事，这就是这门活儿的一部分，你就是这么学会的」。可这话现在已经不成立了。