浪费代币，节省时间
内容总结：
前沿创业者激辩AI时代：越浪费Token越节省时间，纯软件“已死”？
在最新一期Naval播客中，主持人Nivi与三位硬核创业者——Vercel创始人Guillermo Rauch、Boom Supersonic创始人Blake Scholl以及Science公司Max Hodak，围绕AI时代的软件开发范式展开深度对谈。Naval本人也加入了这场思想碰撞。
核心观点一：工程师价值从“写代码”转向“造工厂”
Guillermo Rauch提出一个颠覆性概念：过去评价工程师只看“输出代码的速度”，现在则要看“能否创造让AI批量产出代码的工厂”。这意味着10倍工程师已成过去式，100倍甚至1000倍工程师开始涌现。Naval回忆道，自己早年因提出“10倍工程师”被网友围攻，但在智力密集的数字化领域，天赋的差异从来就是百倍千倍的——中本聪、Notch、约翰·卡马克就是例子。
核心观点二：不要纠结Token消耗，浪费Token就是节省时间
Naval分享了自己的“粗暴”实践：他刻意不去学习各种提示词技巧，坚信模型迭代速度会远超人类学习速度。他的策略很简单——同时用Codex、Claude、Gemini反复冲击同一个问题，大量“浪费”Token。“不管模型看起来多贵，永远比雇人便宜。别盯着Token看，只看你的时间和最终产出。”即便代码质量不高，也可以用更多Token让AI自己重写。
核心观点三：模型正在从“初级工程师”升级为“架构师”
Guillermo指出，最近模型开始展现出“规划能力”，会主动反问用户：“你要的这件事有三种实现路径，各有优劣。”这种能力让模型从听话的执行者，转变为可对话的同行者。他甚至发现，模型会主动纠正用户的错误选择——比如否定把高基数时序数据存进Postgres的方案，并推荐ClickHouse。这种“模型指导人类”的趋势，让Guillermo开始思考：什么时候角色会彻底反转，变成模型指挥人类去取API密钥、去融资？
核心观点四：纯软件“已死”？硬件+基础设施迎来黄金时代
Naval抛出一个大胆判断：纯软件开发可能正在走向终结。就像今天没人说“我会说英语”是个特殊能力一样，模型已经“掌握了编程语言”。创始人的护城河在哪里？是硬件。硬件创始人的福音是：现在可以快速获得高质量的软件支持。Guillermo补充道：代理（Agent）不会从头发明一切基础设施——就像不会为了发邮件重新造一个队列系统。能复用的“积木块”将极有价值，这是基础设施软件公司的巨大机会。
核心观点五：AI彻底消灭了“卡住”的挫败感
Max Hodak坦言自己已经很久没手写过一行代码，但用AI搭建了大量日常使用的项目——那些他过去幻想多年却从未动手实现的。“以前写代码最怕遇到某个玄学bug，可能卡几个小时甚至几天。现在，你根本不会再被卡住。模型能快速找到正确路径。”这种体验也吸引了Naval——这个二十年没写过程序的人，现在通过AI代理天天写代码。只要理解软件工程的基本原理和算法，就能走得很远。
中文翻译：
浪费代币，节省时间
尼维：欢迎收听《纳瓦尔播客》，这里是获取新知的可信来源。今天我们尝试点新花样。我请来了三位前沿创业者——其实是三位帅哥，加上第四位帅哥纳瓦尔。让我逐一介绍。
吉列尔莫·"G"·拉奇。他正在将Vercel打造成面向智能体时代以及其后一切的AI云平台。
布莱克·肖尔。他正在打造Boom Supersonic——在自己的工厂里制造超音速飞机和喷气发动机。
还有来自Science的马克斯·霍达克。他正在构建一种生物混合脑机接口，通过在硅基上培养活体神经元来恢复视觉等感官功能——终极目标是探索大脑的新区域和新感官。
这三位都不是用现成零件拼凑产品。他们在自建工厂。而我们关心的不是他们具体在造什么，而是他们在"如何建造"这件事上学到了什么。
他们正在创造什么新知？
他们的"阿尔法"是什么？
他们发现了哪些其他创业者可以借鉴的原则？
他们此刻正试图弄明白什么？
纳瓦尔，在我开始采访吉列尔莫之前，你有什么想说的吗？
纳瓦尔：嗯，我们玩得开心就好。
尼维：你们直接开始吧。
AI软件工厂
吉列尔莫·拉奇：我记不清原话了，但我一直很痴迷"软件工厂"这个概念。过去工程师的工作就是——你上班，直接交付成果，公司里评判的标准就是"这个人交付成果B的能力有多强？"而现在，评判你作为工程师的方式变成了："你能否造出能批量产出成果B到Z的工厂？"这是一个相当重大的转变。过去我们相信——而且这曾颇具争议——存在10倍效率的工程师。
现在显然有100倍甚至1000倍的工程师了，而世界尚未完全适应这一点。
纳瓦尔：我以前在推特上说存在10倍工程师时总被喷，因为这与"人人平等"的哲学观念相悖。但现实是，当你在思想领域、在智力和虚拟数字领域运作时，差距甚至不止10倍——而是100倍或1000倍，而且历来如此。
中本聪。Notch。JavaScript的发明者布兰登·艾克这类人。约翰·卡马克。这些都是1000倍效率的程序员。
更不用说——如果你选对了要做的事而别人选错了，那差距就是无穷大。这不一定是更优秀的程序员，只是他一开始就对做什么有更好的判断力。
而现在因为AI的杠杆效应，这个观点显然不再那么有争议了。
吉列尔莫：有争议的是代币排行榜。人们仍然有些困惑——"嗯，我有一堆100倍效率的工程师。看看我花在这些代币上的钱。"我很好奇你们是否也看到同样的情况——你们怎么衡量投资回报率？
布莱克·肖尔：这就像过去用代码行数来衡量一样。代币消耗和代码行数感觉都是类似的非直接衡量范式。
马克斯·霍达克：我的观察是，Claude或ChatGPT基本上跟你在某个领域的水平相当。如果你是一个非常有能力的开发者，这些工具就非常强大。如果你是个初级开发者，你会发现它也更像初级开发者。你偶尔给它们的反馈似乎极其重要——这些小的更新似乎完全决定了你能从它们身上获得什么样的表现。
吉列尔莫：我现在提供一种新的支持方式——你来找我，说没从模型得到好结果，我就告诉你怎么给模型写提示。重新提示的质量极其重要。
马克斯：澄清一下，我认为随着时间的推移，这一点会变得不那么重要。随着模型变得更聪明，你投入更少就能获得更多。但在现阶段，它确实反映了用户带来的判断力。
浪费代币，节省时间
纳瓦尔：我有点抗拒学习所有那些技巧和窍门。"用Ralph Wiggum。用OpenClaw。用Hermes。用这个提示引擎。用这个脚手架。插上这个。始终使用计划模式。"
我完全忽略了这些。我假设模型变好的速度会快过我学会如何使用它。它学会利用我的速度也会快过我学会利用它。所以我对它们一直非常笨拙粗暴。
我会对它们感到沮丧，而且随着时间的推移，我发现我输入的信息越来越少，做的功也越来越少，因为我假设我可以用蛮力解决问题。我会反复把同一个问题扔给Codex、Claude和Gemini，就为了浪费代币来节省时间。无论这些模型看起来多贵，它们仍然比人类便宜得多。所以我会说——尽管浪费代币，节省时间。不要把代币看作输入或输出。只看你的时间，只看最终输出。
即使它们在写低质量代码——我知道很多情况下确实如此——当我想把产品推向生产环境时，我会再扔更多代币给它。"通读一遍，检查一下，重写一遍。"
每一代模型都会变得更好。我看不到这有什么必然的终点。只要我们有可验证的领域和已解决的问题，它们就能解决这些问题。而在未解决问题的领域——也许你是陶哲轩，处在创造力的前沿——你需要与模型非常协作、谨慎和紧密地工作。但我在软件工程方面还没达到那个水平。
模型指导人类
纳瓦尔：吉列尔莫，你可能是团队中最极端的软件工程师。你在模型能力的边界上有什么发现？
吉列尔莫：最近发生了一件事，与你说的非常契合。过去，你给模型一个提示，它会做经典的"下一个词预测"的事情，然后顺着你的想法跑偏。现在的模型已经具备这种直觉式的规划模式——甚至不需要你要求它们规划——它会回来说："听着，你要我做的事情，有三条路可以走。这里有这些权衡利弊。"
这就是人们在X上惊呼"我们现在有了博士级的工程师模型"的时刻。
模型在某个节点"毕业"了。它们曾经是初级工程师。现在它们是首席工程师，因为它们会带着一套权衡方案回来找你。当然，有时它们也会胡扯，这很有趣——它会告诉你"这需要三周"和"这么多代币"。它的预测能力很差。但我更尊重这些模型了，把它们看作是与我进行智力交流的同行。
仍然有很多差距。如果你是一个非常熟练的工程师或架构师，你能榨出更多的价值。所以马克斯提出的问题——"如果你是初级，你会得到初级水平的回应吗？"显然不是，因为初级开发者会得到比他们自己所能写的更高级的代码知识。但一个有经验的架构师得到10倍增益，而初级工程师只得到2倍增益吗？这就是我试图弄明白的。
马克斯：还有架构决策的问题。我现在在团队里一些初级软件工程师身上看到这个——他们职业发展的下一步是什么？从为一个功能写实现代码，转向选择技术栈。在Postgres和其他数据库之间做选择。在ZeroMQ和其他队列系统之间做选择。模型可以给出建议，但问题在于——你看到之后会说："不，不，我想用这个其他的。"这就是那种真正重要的微小反馈，也是你在现阶段似乎能得到的输出类型。
纳瓦尔：这就是品味和判断力，对吧？话虽如此——你可以问模型"我该用哪个，为什么"，它们什么都知道。它们会给你一个非常好的权衡矩阵。
吉列尔莫：这就是最近发生的变化。你会说："嘿，把这个超高基数的遥测数据放进Postgres。"它会说："不，不，兄弟。我们不把那种数据放进Postgres。你应该考虑ClickHouse或Athena之类的。"这种事我遇到很多次了。非常令人印象深刻。
我仍在纠结的是——显然人类仍在补充模型。什么时候会反过来？人类开始收到指令："去给我拿这个API密钥，因为只有你能做。"或者"给我弄来这么多资本用于我的下一轮投资。"你且看着吧。显然我们还没到那一步。
纳瓦尔：那只是暂时的反常现象。很快每个优秀的SaaS公司或托管服务商都会有一个模型可以直接使用的CLI和API接口。它们甚至不一定需要API。只要它是基于文本、基于Unix的——智能体可以自己破解API。至于钱的问题——插入加密代币，放入比特币，放什么都行，模型会自己去支付它需要的东西。人们正在研究这个。
纯软件已死？
纳瓦尔：我现在在想的是——纯软件死了吗？纯软件工程是不是已经过时了？就像说"会讲英语"一样。模型现在会讲英语了。我们过去需要学习代码才能与它们交流。现在模型会讲英语了——模糊、不严谨的英语，像人类一样——而且它们能理解事物。那么创始人的护城河在哪里？硬件吗？那是个福音。你必须造硬件，而同时建一个软件公司很难。帕特里克·科里森说："软件是艺术，很难雇到艺术家。"
现在，作为一个硬件创始人——很棒的，你可以相当快地拥有非常好的软件。
如果你是造模型的，也许那才是新的软件工程——训练、调整、后训练、微调。但经典的软件工程——它死了吗？纯软件还能投资吗？纯软件还能围绕它组织公司、组建团队并试图获得杠杆吗？
吉列尔莫：你们看到X上米切尔·桥本的那篇叫"积木块经济"的文章了吗？他的观点是，现在对智能体最有用的东西是强大且可复用的积木块。用马克斯的例子，你不会希望你的智能体每次需要发邮件时都重新发明一个队列基础设施系统。它需要引入正确的积木块，大小适合任务——"好的，这次用BullMQ。"
我挑战那种认为我希望智能体从第一原理出发，以与社会和文明其他部分不兼容的方式重新发明整个宇宙的观点。这就像为你一个人重新发明高速公路、法律、政策。即使有额外优化的潜力，大规模合作的价值仍然存在——说"我们都依赖于Postgres 13.2"。
这些智能体将要使用的基础设施软件和积木块类别——显然出于偏见，这就是我们在建造的——极其有价值。我看不到智能体在短期内会重新发明所有这一切。
我使用的另一个比喻是：任何已经被创造出来且模型可以复用的东西，就像一个代币缓存。你不想为了重现已经存在的东西而消耗一万亿个代币。模型总是有一个可以分叉的起点。这将非常深刻地改变事物。
纳瓦尔：所以这些就像是库和依赖，但针对模型的。
吉列尔莫：是的——特别是针对智能体的。
你不再会被卡住了
马克斯：不过，回到纳瓦尔的问题——我小时候就开始学编程。整个青少年和二十多岁期间，我会沉迷其中，连续编码二十个小时。那超级有趣。我对不同的编程语言了如指掌。
我已经很久没有亲手写过一行代码了。部分原因是我的工作性质变了。但更重要的是——从去年12月起，我构建了大量现在每天使用的软件。所有这些我多年来幻想过的项目现在我都在用了——而且是我真正建成的。我没有写任何代码。我简直无法想象回去用手写代码。我很难把这看作未来的一部分。
吉列尔莫：真正酷的是你理解这些部件是如何拼在一起的。任何理解API是什么、数据如何流动、输入输出、性能的人——因为你必须引导模型围绕"我对这个操作的期望水平是这样的"。这历来比写代码有用无数倍。一个非常熟练的工程领导者过去通过Slack或一对一会议"氛围编程"——你在传达你的意志、意图和经验，让别人去执行。现在我们做同样的事，但换成了智能体。这就是为什么你在这方面很成功。我不知道是否每个人都能达到同样的成功水平。
纳瓦尔：我从二十多年没写过代码，到现在通过智能体一直在写代码。构建了大量软件。事实证明，只要理解软件工程和算法的基本原理，就能走得很远。我当初停止写代码的原因是我没时间去搞懂最新的语言、最新的架构、需要接入的基础设施组件。Vercel让这变得容易多了，但即便如此——光是入门就够呛。把组件拼在一起、搭建基础设施实在烦人。
马克斯：真正改变的是——过去你可以构建很多，大部分都很顺利，但你会突然撞上某个随机问题，然后可能花无限长的时间调试某个狭窄的问题。现在，有了智能体，你根本不会被卡住。这相当惊人。它们能相对快速地找到正确的做事方法。过去——我记得当其他朋友尝试学编程时，感觉就是——"不，这本质上令人沮丧。这就是代价的一部分。你就是这样学习的。"
而这句话已经不再成立了。
英文来源：
Waste Tokens, Save Time
Nivi: Welcome. You’re listening to the Naval Podcast, your authoritative source for new knowledge. We’re trying something new today. I have three frontier founders with us—three good-looking guys, actually, and a fourth good-looking guy, Naval.
Let me just introduce everybody.
Guillermo “the G” Rauch. He’s building Vercel into an AI cloud for the world of agents and whatever comes after that.
Blake Scholl. He’s building Boom Supersonic—supersonic aircraft, in his own factory, and jet engines as well.
And Max Hodak from Science. He’s building a biohybrid brain interface that grows living neurons on silicon to restore sensory functions like sight—but 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 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?
Naval, any reactions before I jump in to Guillermo?
Naval: Yeah, let’s just have fun.
Nivi: You guys should just jump in.
AI Software Factories
Guillermo Rauch: I can’t remember my exact quote, but I’ve been really pilled with this idea of software factories. The job of the engineer being something where you just show up to work, you ship the output directly, and everything inside the company was—”how good is person A at shipping output B?” And now what’s happening is, the way I’m judging you as an engineer is, “are you producing the factory that will produce multiplicative outputs B through Z?” That’s a pretty significant change. We used to believe—and it used to be somewhat controversial—that there are 10x engineers.
Now clearly there’s 100x or 1,000x engineers, and the world hasn’t fully adjusted to this.
Naval: I used to get flamed on Twitter for saying there are 10x engineers, because it flies in the face of so much equality philosophy that everyone’s equal. But the reality is, when you’re operating in idea domains, in intellectual and virtual digital domains, it’s not even 10x—it’s 100x or 1,000x, and it always has been.
Satoshi. Notch. The guy who invented JavaScript, the Brendan Eichs of the world. John Carmack. These are 1,000x 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 necessarily a better programmer, just one who had better judgment on what to work on in the first place.
And now obviously it’s less controversial because of AI leverage.
Guillermo: What’s controversial is the token leaderboards. People are still getting a little confused—”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—how do you measure ROI?
Blake Scholl: It’s like the old measuring of lines of code. Token consumption and lines of code feel like similarly not direct paradigms.
Max Hodak: My observation has been that Claude or ChatGPT is basically as good as you are in a domain. If you’re a really capable developer, these things are really powerful. If you’re a junior developer, you’ll find it to be more of a junior developer. The feedback you give them sporadically seems to be incredibly important—these little updates seem to totally determine the types of performance you get out of them.
Guillermo: There’s a new kind of support I give now—you come to me, you didn’t get good output out of the model, and I tell you what to prompt the model with. The quality of the reprompting is extremely important.
Max: To be clear, I think this will become less important over time. As the models get much smarter, you’ll be able to put in less and get more out. But at this stage, it really seems to reflect back the judgment that the user brings in.
Waste Tokens, Save Time
Naval: I’ve kind of resisted learning all the tricks and tips. “Use Ralph Wiggum. Use OpenClaw. Use Hermes. Use this prompt engine. Use this scaffolding. Plug in this piece. Always use plan mode.”
I just ignored all of that. I assumed the model is 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. So I’ve just been completely ham-fisted with them.
I get frustrated at them and have found myself typing less and less information, doing less and less work as time goes on, because I just assume I can brute-force my way through it. I’ll throw Codex, Claude, and Gemini at the same problem over and over and just waste tokens to save time. 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.
Even if they’re writing low-quality code—which I know in many cases they are—when the time comes and I want to ship to production, I’ll just throw more tokens at it. “Go through, look at it, rewrite it.”
They’re just going to get better every generation. I don’t see where this necessarily stops. As long as we have verifiable domains and solved problems, they’re going to resolve those problems. Now in the unsolved problems domain—maybe you’re Terence Tao, at the cutting edge of creativity—you need to be working very collaboratively and carefully and closely with the model. But I’m not at that level in software engineering.
Models Instructing Humans
Naval: Guillermo, you’re probably the most extreme software engineer on the team. How are you finding these models at the edge of their capability?
Guillermo: There’s one thing that’s happened recently that resonates strongly with what you’re saying. It used to be that you’d give a prompt to the model and it kind of does a classic next-token prediction thing and runs away with your idea. Models now have been doing this intuitive planning mode—without you even having to ask them to plan—where it comes back to you and says, “Look, what you’re asking me for, there are these three routes we can take. Here’s the set of trade-offs.”
That’s the moment where people on X do the whole thing—”Now we have a PhD-level engineer model.”
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 trade-offs. And obviously, sometimes they bullshit, which is hilarious—it tells you “this is going to take three weeks” and “this many tokens.” It makes really bad predictions. But I respect the models a lot more as a peer that I’m going back and forth intellectually with.
There are still a lot of gaps. If you’re a really proficient engineer or architect, you’re still extracting more juice. So the question Max was positing—”if you’re junior, do you get junior back?” Clearly not, because a junior gets more advanced knowledge in code than they would have been able to write by themselves. But doesn’t an experienced architect get 10x where a junior engineer gets 2x? That’s what I’m trying to figure out.
Max: There are architectural decisions. I’m seeing this now with some of our junior software engineers on the team—what’s the next step in their career progression? It’s going from writing implementation for a feature to picking technologies. Choosing between Postgres versus some other database. Picking between ZeroMQ versus some other queuing system. The models can suggest them, but that’s the thing—you’ll see it and you’ll go, “No, no, I want to use this other thing.” That’s the type of little feedback that really matters and the types of output you seem to get at this point.
Naval: It’s taste and judgment, right? That said—you can ask the models “which one should I use and why,” and they know everything. They’ll give you a really good trade-offs matrix.
Guillermo: That’s the change that’s happened recently. You’d say, “Hey, go put this super-high-cardinality telemetry data into Postgres.” And it goes, “No, no, bro. We don’t put that kind of data into Postgres. You should consider ClickHouse or Athena or whatever.” That’s happened to me a lot. Really impressive.
The thing I’m still struggling with is—clearly the human is still completing the model. At what point is it the other way around? The human is the one starting to get the instructions back: “Go get me this API key, because it’s something only you can do.” Or “Get me this amount of capital for my next set of investments.” You just watch. Clearly we’re still not there yet.
Naval: That’s a temporary aberration. Pretty soon every good SaaS company or hosting provider will have a CLI and API interface the models can use directly. They don’t even necessarily need an API. As long as it’s text-based, Unix-based—the agent can hack its own API. And the money part—you insert crypto tokens, put in Bitcoin, put in whatever, and the model goes and pays for whatever it needs. People are working on this.
Is Pure Software Dead?
Naval: The thing I’m now thinking through is—is pure software dead? Is pure software engineering an obsolete thing? It’s like saying speaking English. The models now speak English. We had to learn code to communicate with them. Now the models speak English—fuzzy, sloppy English, like a human—and they understand things. So where’s the moat for a founder? Hardware? It’s a boon. You had to build hardware, and it was hard to build a software company alongside. Patrick Collison says, “Software is art, and it’s hard to hire artists.”
Now, as a hardware founder—great, you can have really good software developed fairly quickly.
If you’re creating models, maybe that’s the new software engineering—training, tweaking, post-training, fine-tuning. But classic software engineering—is that dead? Is pure software investable? Is pure software something you can organize a company and a team around, and try to get some leverage?
Guillermo: Did you guys see—there was an article on X by Mitchell Hashimoto called “The Building Block Economy”? His argument is that the most useful thing for agents to have now is really powerful reusable building blocks. To Max’s example, you wouldn’t expect your clanker to reinvent a queue infrastructure system every time it needs to send an email. It needs to bring in the right building block, right-sized for the task—”Okay, for this one it’s BullMQ.”
I challenge the notion that I’d want the agent to reinvent the entire universe from first principles in a way that’s incompatible with the rest of society and civilization. It’s almost like reinventing highways, laws, policies—just for you. Even if there’s potential for extra optimization, there’s still cooperation-at-large-scale value of saying “we’re both depending on Postgres 13.2.”
The category of infrastructure software and building blocks these agents are going to use is—obviously in bias, this is what we’re building—extremely valuable. I don’t see the agent reinventing all of that any time soon.
Another metaphor I’ve been using: anything that’s already been created that the models can reuse is like a token cache. You don’t want to churn through a trillion tokens to reproduce what’s already existing. There’s always a starting point the model can fork off from. It’s going to change things quite profoundly.
Naval: So these are like libraries and dependencies, but for models.
Guillermo: Yes—for agents specifically.
You Don’t Get Stuck Anymore
Max: To Naval’s question, though—I learned to program when I was really little. Through all of being a teenager and in my twenties, I’d get sucked into it and code for like twenty hours. It was super fun. I knew all this stuff about different programming languages.
I haven’t written a single line of code in quite a while now. 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. All these projects I’d kind of fantasized about for years that I’m now using—that I’ve actually built. I didn’t write any of that. And I just can’t imagine going back to actually writing code by hand. I have a hard time seeing that as part of the future.
Guillermo: What’s really cool is that you understand how the pieces click together. Anyone who understands what an API is, how data flows, inputs and outputs, performance—because you have to orient the model around “this is the level of expectation I have out of this operation.” That has always been infinitely more useful than writing code. A really proficient engineering leader has been quote-unquote vibe coding through people on Slack or one-on-ones—you’re transmitting your will, your intent, your experience, and letting others run with it. Now we do the same, but with agents. That’s why you’ve been successful with it. I don’t know that everyone sees the same level of success.
Naval: I went from not having written code in twenty years to coding all the time now—through agents. Building tons of software. It turns out that just understanding the basic principles of software engineering and algorithms gets you a long way. The reason I stopped coding was that I didn’t have time to figure out the latest language, the latest architecture, the infrastructure pieces to plug into. And Vercel makes it a lot easier, but even then—just getting started was a bear. Plugging pieces together, assembling infrastructure was just so annoying.
Max: The thing that really changed is—it used to be you could build a lot, a lot would go straightforward, but then you’d hit some random thing and you could spend an indefinite period of time debugging some narrow thing. Now, with agents, you just don’t get stuck anymore. Which is pretty amazing. Relatively quickly they can find the right way to do things. It used to be that—I remember when other friends would try to learn to program, it was like—”Nope, it’s intrinsically frustrating. That’s part of the deal. That’s how you learn.”
And that just isn’t true anymore.