简单说就是通过对话让 LLM 编写代码，而你只需要沉浸在解决问题的「氛围」中，同时忽略生成的代码细节。
用 Karpathy 大神的话说就是，「我只是看到东西，说出东西，运行东西，复制粘贴东西，而且大部分情况都奏效。」
在 YC 最近的一起播客中，YC 管理合伙人 Jared Friedman 透露，在 2025 年冬季（W25）这一批 YC 创业公司中，有四分之一的初创团队表示其 95% 的代码都是 AI 生成的。
这期播客还聊到了 Vibe Coding 的一些局限，以及对程序员的一些长远影响，Founder Park 对播客内容进行了编译，有部分删减。
Key Message：
-
这是一种完全不同的系统构建方式，不再是逐步搭建基础，而是彻底从头开始。 -
四分之一的创始人表示，其代码库中超过 95% 的代码由 AI 生成。要知道，我们投资的这些创始人技术都很精湛，完全有能力从零构建产品。 -
如今的招聘标准发生巨大转变，从「青睐传统计算机科学训练出身、能在白板解算法题的人」，变成「看重工作效率高、能快速编写代码的人」。 -
如今我们都是产品人」，意味着需要有出色品味、清楚该构建什么；二是当下真正有价值的，是成为系统思考者与架构师，能把握大局。 -
Vibe Coding 适用于产品从 0 到 1 阶段，能帮创始人快速推出功能。但 PMF 之后，要迈向从 1 到 N，就得靠扎实系统工程，需聘请不同类型人才 -
与其让候选人实际编写代码，不如把代码审查作为面试方式 -
如今的编码工具让投入时间变容易，因为产出很快，很容易达到「足够好」水平。但想成为最优秀的人或创始人，就得刻意练习，钻研细节、剖析系统，仍然需要一定传统训练。
-
高浓度的主流模型（如 DeepSeek 等）开发交流；
-
资源对接，与 API、云厂商、模型厂商直接交流反馈的机会；
-
好用、有趣的产品/案例，Founder Park 会主动做宣传。
01
YC 新的创业者们
都开始Vibe Coding 了
Garry：今天我们要讨论的是「Vibe Coding」，这个概念源自 Andre karpathy 最近一篇走红的帖子。有一种新的编码方式，我称之为「Vibe Coding」，在这种方式中，你完全沉浸在 Vibe 中，拥抱指数级的发展，甚至可以忘记代码的存在。
Harj：是的，所以我们调查了当前 Y Combinator 批次的创始人，了解他们对「Vibe oding」的看法。我们也问了他们一些问题，比如他们正在使用什么工具？工作流程有怎样的变化？以及他们认为未来软件工程的发展方向是什么？还有随着我们进入「Vibe coding」的世界，软件工程师的角色会如何改变？我们得到了一些非常有趣的回复。
Diana：我可以逐字念出其中一句：我认为软件工程师的角色将转变为产品工程师。如今，人类的品味比以往任何时候都更加重要，因为强大的工具让每个人都能成为 10 倍效率的工程师。这是 Outlet 的创始人说的。
Jared：阿斯特拉公司的艾比说：「我不怎么写代码了，我只是思考和审查。」这可是一位非常懂技术的创始人，他之前的公司也是一家开发工具公司，他的编码能力极强。所以看到像他这样的人有这样的看法，真的很有意思。
Harj：还有 Copycat 公司的另一位创始人说：「我现在对自己的代码没那么执着了。所以我在决定是否废弃或重构代码时没那么主观了，因为我编码的速度能快三倍，所以如果有需要，很容易就会废弃并重写代码。」
Garry：我想，关于这种「Vibe coding」最酷的一点是它的并行性很好。比如 K60 公司的约夫说：「我用 Cursor 写所有东西。有时候我甚至会同时打开两个 Cursor 窗口，针对两个不同的功能进行提示，这很有道理。为什么不打开三个呢？」确实，很多人都这么做。
Diana：我觉得另一句很棒的话来自 Train Loop 公司的创始人，他提到：「编码在过去 6 个月到 1 个月间发生了怎样的变化，一个月前速度提升了 10 倍，而现在又提升了 100 倍，实现了指数级的加速。我不再是一名工程师，我成了一个产品人。」
Garry：这很有趣，可能是广泛存在的现象。最终会出现两种角色，对应如今工程师的自我定位：前端工程师和后端工程师。后端工程师侧重基础设施工作，前端工程师类似 PM 与人类学家，深入 GDP 中被忽视、服务不足的领域，挖掘需求并转化为代码，在这个过程中，评估是最重要的部分。
02
不是逐步修改，
而是每次都彻底重构
Harj：运营 TripleByte 时我便注意到，对工程师做技术评估很重要，但我们还得明确谁适合特定公司，这存在技术能力门槛。但除此之外，还有一个问题——工程师是否愿意与用户交流？有些工程师热衷于知晓用户是谁，能与用户互动、获取实时反馈并据此迭代，这其实就是产品工程师的工作模式。而另一些工程师则不愿做这些，觉得麻烦，只想专注攻克复杂技术难题。
Garry：这不就是后端工程师嘛。
Harj：对，我们就是这么称呼他们的。调查回复也反映出一个主题：LLM 可能影响人们的选择，因为代码编写或许不再那么重要。关键在于，你是注重产品问题、富有品味的产品型人才，还是专注解决系统问题的架构师。
Garry：有趣的是，调查显示这些工具在调试方面表现很糟糕。所以还是得靠人类，人类要弄清楚代码的实际运行情况，找出错误所在，排查代码路径问题或逻辑错误，这些只是靠工具无法直接完成。你之前说过，使用工具时必须像给新手软件工程师下指令那样，指令要非常明确。
Jared：现在你真的得像喂婴儿一样给出详细的指令，才能让它去调试东西。或者你也可以像Andre karpathy 那样，拥抱「Vide」，抛开错误，让它重来。当实际编写代码的成本降低到千分之一时，你的编码风格会发生巨大的变化，这真的很不可思议。人类不会因一个错就舍弃自己花了很长时间编写的内容，但 LLM 能在 6 秒重写 1000 行代码，那为什么不（重写）呢？
Garry：这有点像人们在使用 Midjourney 或 Playground 生成图像时的做法。如果生成的图像有瑕疵或者自己不喜欢的地方，有时候甚至都不修改提示词，直接点击重新生成，多试几次，有时候就成功了，就会觉得这个能用了。
Diana：这是一种完全不同的系统构建方式，不再是逐步搭建基础，而是彻底从头开始。毕竟当下这些工具都源自代码生成领域，代码隐匿于潜在空间。得从头摸索不同梯度，才能避免陷入困境，还需要加入随机性让它重新生成。或许到未来 0.5 版本左右，有可能达到能够在已有基础上进行构建的程度。但目前多数时候只能重新生成、重写，无法在已有基础上构建。当下还没有编码工具能达成我们预期的效果。
Jared：GPT-4 比 GPT-3.5 在调试方面要好得多。所以感觉我们正朝着一个方向发展，也许 6 个月后我们再做这一期节目时情况就不一样了。
03
YC 1/4 的项目中
95% 的代码由 AI 生成
Jared：Diana，你想谈谈人们正在使用的模型，以及人们使用的 IDE 吗？这里面有一些非常有趣的趋势。
Diana：就像前几期节目提到的，2024 年夏天这种变化已初现端倪。当时很多人都在使用 Cursor，如今它无疑是领先者。但这个领域变化非常快，Windsurf 是一个紧随其后的有力竞争者，它正在成为一个非常优秀的产品，与 Cursor 形成竞争。Jared，你有亲身体验，为什么 Windsurf 比 Cursor 更好呢？
Jared：我认为人们选择 Windsurf 的首要原因是，当前 Cursor 在处理大代码库时，很大程度上需用户告知它应该查看哪些文件及具体查找位置，而 Windsurf 会对整个代码库索引，能自行精准定位该查看的文件。当然二者还有其他区别，但我认为这一点最关键。
Diana：值得一提的是，虽然现在有 Devin（首个 AI 程序员），但它没有被重点运用是因为它不太能理解代码库，只适用于小功能，实用性有限，其他工具更是少有人提。人们仍然用 ChatGPT 做推理，因为 Cursor 和 Windsurf 还处于旧阶段（指推理模型出现前、计算能力有限时期）。部分创始人会自行托管模型，以保护关键敏感的知识产权。
在模型方面，半年前 Claude Sonnet 大热，3.5 版本至今仍是有力竞争者，多数人还在使用。如今，推理模型崛起，几乎与 Claude Sonic 3.5 版本齐头并进。DeepSeek R1 倒是热门，似乎是有力竞争者，Gemini 则是很少被用到。
Jared：我听过一些创始人提到 Gemini，因为它有很长的上下文窗口，他们会将整个代码库放入其中，让它修复错误。虽然不总是成功，但有时候因为代码库全在窗口内，能一次性解决问题。
Diana：随着人们更多地采用新发布的推理模型，比如 Gemini 2.0 Flash Thingking，看看情况会如何发展会很有意思。人们还没有尝试过它，但长上下文窗口加上推理能力，可能会使它成为一个有力的竞争者。目前这批创始人中，由 LLM 生成的代码占比估计是多少呢？
Jared：这真的很惊人。我们特意问了这个问题：不包括导入库，你估计在代码库实际字符里，由人类手动输入与 LLM 生成字符的占比是多少？也就是估计代码库中 AI 生成代码的百分比。结果令人惊讶，四分之一的创始人表示，其代码库中超过 95% 的代码由 AI 生成。要知道，我们投资的这些创始人技术都很精湛，完全有能力从零构建产品。但一年前他们会从零开始，如今 95% 的代码却都是 AI 完成，这一统计数据十分惊人。
Garry：不过，也许有一两个例子是这样的，他们太年轻了，是在过去两年才开始学习编码的，所以他们实际上不知道没有 Cursor 的世界是什么样的。
Jared：是的，这一批中我负责的一家最好的公司就是这样。创始人都是极具技术头脑的人，但他们没有接受过传统的计算机科学和编程训练。他们的工作效率极高，能够产出大量非常出色的产品，而且几乎所有的代码都是由 AI 编写的。
04
Vibe Coding 适合从 0 到 1 的创业
Diana：这让我想到很多关于 Z 世代的讨论。作为首批互联网环境下的数字原住民，这一代在原生AI编码工具中成长，跳过传统软件工程师训练，只是凭借「Vibe」进行编码，可他们技术头脑其实都很强，不少人拥有数学和物理学位，所以他们具备那种原始的、我们可以称之为系统思维的能力，这仍然是需要的。也许我们应该谈谈哪些方面没有变，哪些方面发生了变化。
Jared：我觉得「Vibe coding」能让数学、物理等其他技术领域中有技术头脑的人，比以往更快成为高效程序员。以前编程训练营想把学物理的人培养成程序员，效果不佳，因为掌握语法、库等知识耗时太久。但现在是一个全新的世界。
Harj：编程训练营也非常专注于帮助学员在公司找到工作。记得 2015 年左右，公司也在重新考量招聘软件工程师的评估方式。招聘标准发生巨大转变，从「青睐传统计算机科学训练出身、能在白板解算法题的人」，变成「看重工作效率高、能快速编写代码的人」。
Jared：你觉得这些争论过时了，如果你现在回头看，会怎么想？
Harj：我认为像 Stripe 这类非常成功的公司，十分推崇「只要能熟练用工具、工作效率高的人」，并为了这个理念而改变招聘流程，只选拔实操能力强的人。招聘面试从考查思维方式，变为「给你三小时在笔记本电脑上，尽快构建一个待办事项应用程序」，这些公司大获成功。但公司发展壮大到一定阶段，瓶颈往往在于需要经传统系统思维训练的人，来拓展和优化技术工作。
Garry：如今人们招聘工程师的方式确在改变，只是可能速度还不够快。我们四个人对调查结果都感到很意外，外界或许更是如此。「Vibe Coding」在近六到九个月才进入我们的视野，工程领域的招聘似乎还没跟上这一变化。人们仍在进行白板上的传统测试，而非关注实际工作能力。如此看来，像 Stripe 这样的公司引领了时代潮流，当下所有公司或许都应该效仿他们招聘工程师的方式。
Harj：我在想，这种招聘方式或许也将成为过去式。从调查回复来看，有两个突出主题：一是「如今我们都是产品人」，意味着需要有出色品味、清楚该构建什么；二是当下真正有价值的，是成为系统思考者与架构师，能把握大局。这种情形下，高效编码能力（以往评判优秀工程师的维度之一，即能否快速编写代码）可能不再重要，但也不一定。毕竟 LLM 擅长快速编写代码，而且重新生成、从头编写代码及调试成本降低，所需要的技能或许已截然不同了。
Garry：问题是存在两个不同的阶段。从 0 到 1 阶段，速度至关重要。以 Rails 框架的 Active Record 为例，相关的争论曾陷入僵局，因为使用这个框架能助力快速从 0 到 1。但像 Twitter 出现了服务器过载时，说明当达到 1 之后，这类架构难以支撑公司实现十亿、百亿估值或拥有十亿用户，无法持续。
所以，快速从 0 到 1 与扩展至拥有十亿用户完全不同，现阶段，扩展所需要的人才无可替代。我在扩展大型 Rails 网站时就发现，能做到的人极少，从 0 到 1 本来就不容易。
你有没有遇到过这样的情况：为了快速从 0 到 1，大量使用开源代码，创业公司成立约一年半到两年后，却发现部分随机选用的开源组件无法再用，因为它们根本不是为我们这种规模的应用所设计？
Jared：是的，我们不能再用了，因为它们在我们的规模下无法正常工作。
Garry：所以我们不得不放弃或者自己跟进开发一些东西。
Diana：可以总结一下，「Vibe coding」适用于产品从 0 到 1 阶段，能帮创始人快速推出功能。但 PMF 之后，要迈向从 1 到 n，就得靠扎实系统工程，需聘请不同类型人才。Facebook 就是很好的典型，它最初凭 PHP 成功，可我觉得 PHP 这编程语言挺糟糕，可能会因此遭人诟病，但我确实这么认为。
Garry：我同意，我一直都不喜欢它。不好意思。
Diana：PHP 确实很糟糕，但用它能快速推出产品。但在 Facebook 发展中，它成了推出新功能的瓶颈。以至于 Facebook 不得不聘请专业系统工程师打造定制编译器 HipHop，以实现裸机快速运行，毕竟替换全部代码成本太高了。完成这个工作的是核心系统工程师，而非「Vibe coding」人员，可见当前工具在底层系统工程方面能力不足。
05
未来程序员不需要会写代码，
但要会审代码
Jared：如果今天你要重新创办 Triplebyte*，并且必须为工程师设计新的技术评估方案，你会让他们做些什么呢？
*用软件实现对软件工程师的自动化评估的一个网站。
Harj：从 Triplebyte 和技术筛选中我得到的最大收获是，每个人想要的东西都不同。所以要先明确评估的内容，再根据这个设计技术筛选方案。像 Stripe 等公司，清楚自身不在乎员工有无扎实计算机科学基础，只筛选与实际工作相关能力。我们产品更倾向于对多种公司可能考察的方面都进行筛选，评估个人最高的技能水平，向看重对应技能的公司推荐高水平人才。在当下，我认为设计筛选方案至少要考虑人们对工具的熟悉程度。虽然这与之前说法有矛盾，但快速编码和构建产品的能力，或许确实需重点考察，而且要把标准定得更高。
Jared：如果回顾 Triplebyte 最初的评估题目，很多直接复制到 ChatGPT 里就能得到完美答案，这样无法真实检验候选人能力。如果想规避这样，问题难度可能得提升 100 倍。
Harj：这这涉及一个关键问题，因为它取决于筛选条件，我觉得这很有意思。以「搭建类似 TikTok 的应用」这一经典问题为例，如果不监督，候选人借助 LLM 可能瞬间给出方案；但要是监督编码且禁止使用 LLM，情况就另当别论了。
Jared：这就产生一个问题：面对旧的编码问题，是禁止候选人使用 LLM，还是允许使用并重新设计问题？毕竟旧问题借助 LLM 变得太过简单。
Harj：我觉得这正是现在所有招聘软件工程师的人都应该思考和弄清楚的问题。是的，我不确定正确答案是什么。
Diana：我认为这可能会测试不同的方面，因为我们也参与过大量的工程招聘。我认为有项关键技能始终重要，那就是阅读与调试代码的能力。面对 LLM 输出内容，候选人得有足够的判断力和相关训练，才能辨别代码是好是坏。如果候选人能判断 LLM 给出的看似合理的方案实则不好，这就是个积极的信号。所以，要有效编码、区分代码好坏，仍是需要判断力和一定的知识，不一定是传统训练所得，但需有足够知识辨别，且要通过大量实践才能掌握，这一点不会改变。这是我的观点。
Harj：没错，这很有意思。与其让候选人实际编写代码，不如把代码审查作为面试方式。
Diana：对，可以设置某种形式的系统设计考察，测试候选人推出产品的能力，本质上也是在测试判断力，同时要测试调试能力和判断力。但对于「AI 编码原住民」这类未接受传统训练的年轻人，如何培养他们的判断力，是未来一个有趣的问题。
Garry：因为如果不培养相关能力，创业公司可能失败。假设创始人的 95% 的代码由 AI 编写，一两年后，产品如果拥有 1 亿用户，问题便会凸显。在推理模型初期，系统调试能力并不出色，所以需深入了解实际情况，否则就会陷入困境。这时创始人最好能请一位架构师来解决问题。
Diana：这将造就一代「足够好」的软件工程师，因为有了这些强大的工具，入门门槛变得如此之低。但要跻身顶尖 1%，还是需要刻意练习。Malcolm Gladwell 推广的「一万小时定律」，源于 K. Anders Ericsson 的研究，成为专家不仅靠投入时间，更要刻意练习，即有计划、有思考且艰苦地投入时间，这样能缩短成为专家的时长。
我认为如今的编码工具让投入时间变容易，因为产出很快，很容易达到「足够好」水平。但想成为最优秀的人或创始人，就得刻意练习，钻研细节、剖析系统，仍然需要一定传统训练。比如毕加索，作为世界上最伟大的画家之一，画逼真画作的功底极为深厚。
Jared：但这并不是他出名的原因。当然，当你想到毕加索，你想到的是与逼真画作相反的东西。
Diana：有一组著名的画作展示了他是如何从画逼真的画，经过多次迭代，最终创作出他广为人知的抽象画的。他能成为世界顶尖画家，是因为他实际上是一位非常优秀且接受过传统训练的画家。他的绘画技巧非常高超，但这并不是他出名的原因。所以我认为我们会看到两类工程师。仍然会有大量「足够好」的工程师，我们需要这类工程师。但世界上最优秀的人，那些出类拔萃的创始人，将需要进行刻意练习。
Garry：是也不是。我是说，我能想到很多非常出色的系统级和世界级工程师的例子，他们最终成为了世界上最大的上市公司的 CEO。比如 Max Levechen，还有 Shopify 的 Toby Luke。这些人真的非常优秀。但也有很多其他没那么优秀的人，同样成为了公司的 CEO 或联合创始人。这又回到了我们之前说的招聘问题上。
Harj：我一直在想你提到的 Twitter 的例子。我觉得这个例子很有意思。如果你比较一下 Facebook 和 Twitter，在这两个案例中，它们都是以一种不太正规、快速行动、打破常规的方式迅速从 0 发展到 1。Facebook 在解决扩展性技术挑战方面做得非常出色，我想大多数人都会认同这一点。
Garry：同意。Mark Zuckerberg 在技术方面远比其他人更深入。可能更深入地参与到技术细节中。
Jared：比如，我认为基于使用模式，Twitter 的可扩展性挑战实际上更难。Facebook 的使用情况是，一整天的使用量都比较平稳，人们随时都在使用。而 Twitter 的问题在于，它的使用量波动非常大。比如超级碗或者其他世界重大事件发生时，突然间使用量会增加 10 倍。而且它的消息推送机制，从根本上来说，是一个非常棘手的计算机科学问题。
Garry：有道理。不过我也觉得他们被工具严重束缚了。你还记得他们用的那个糟糕的队列系统 Starling 吗？我当然记得。我当时用它是因为我想，「Twitter 比我们大多了，他们那么聪明，不会用不好的东西。」结果，他们真的用了个烂东西。我用了之后根本没法正常工作，它会把任务弄丢，出现各种疯狂的漏洞。最后我想，「我再也不用这个了。」我得换成 Rabbit MQ 或者其他什么正确的东西。
Jared：对，而且 Ruby 是一种非常慢的编程语言，甚至比已经很慢的 PHP 还要慢 10 倍。
Garry：但我也不知道。只能说基本上能发展到一定规模就已经很幸运了。
Harj：对于技术型创始人来说，接受传统训练并成为深入了解系统的专家，会有优势吗？
Garry：嗯，像 Toby 或者 Max Levechen 这样的人是不会被轻易糊弄的。
Harj：比如 Stripe 的创始人。
Garry：没错。有个疯狂的故事：我曾在一家公司负责与人才相关工作，后来还设计了公司标志。在参加 Y Combinator 创业项目前，我在一家风投支持、后倒闭的信用卡软件公司当了六个月交互设计师，这段经历挺有趣，还让我有时间做自己的创业项目。记得当时设计租车的分面搜索功能，与开发经理和负责实现该功能的工程师开会时，他们说做不了，我提出调整索引的办法，他们非常惊讶我居然会懂这些，还查看了我的简历。
Jared：从交互设计师那里听到这种话，他们肯定很惊讶。
Garry：他们惊讶于我懂技术，我当时就觉得他们在糊弄我。重点是，创始人招聘时，往往以为员工不会撒谎、偷懒，都会为目标和使命努力，可事实并非如此。若创始人无法识别员工的谎言，员工就会欺骗。糟糕的是，有时得当面戳破。一些工作场所文化过于礼貌，人们选择背后议论，而这种情况下其实该开除撒谎员工。同样，AI agent 也会敷衍人，如果不谨慎，不指出它没有按照要求做出改变，它就会蒙混过关。
Jared：这又回到了你说的为什么接受传统训练仍然有帮助这个问题上。你必须能够指出为你工作的所有人的问题，不管他们是人类还是 AI。具备足够的技术能力来做到这一点是一种超能力。
Diana：总结一下，Train Loop 的创始人有句话说得好，所有这些工具给了最优秀的工程师超能力，却让水平差的工程师更差。编码在过去 6 个月到 1 个月间发生了怎样的变化，一个月前速度提升了 10 倍，而现在又提升了 100 倍，实现了指数级的加速。
（文：Founder Park）