100%的代码由AI生成。
这不是科幻小说，也不是某个技术博主的噱头。Braintrust的CEO Ankur Goyal在a16z的采访中随口提到，他正在用Cursor让AI重写一个技术问题，笔记本电脑半开着扔在椅子上，自己跑去工作。
如果你还在逐行敲代码，你可能正在用打字机时代的方式工作。
但这不是重点。
Ankur是那种典型的「系统工程师转AI创业者」。十年前，他做过基于计算机视觉的文档提取（那时语言模型还很弱），被Figma收购后带领AI团队，之后创办Braintrust——一个帮企业测试和评估AI系统的平台。他的简历里有个细节很有意思：在MemSQL工作时，他经常飞到纽约见银行客户，那些对SQL理解相对基础的金融分析师，用他们的产品写出超长的SQL查询完成复杂分析；而回到硅谷，他会见科技公司，那里有50个工程师在写MapReduce任务，做着更笨的事情，还挣扎得要死。
「你知道吗？工作流和数据库是两回事。很多Hadoop的用例其实是MapReduce——处理一堆文档——根本不是你需要SQL的场景。」
问题出在下一步。
当你花10亿美元「造上帝」
现在的AI行业处于一个奇怪的状态：frontier labs（前沿模型实验室）可以融到10亿美元，然后把钱直接砸向训练。 不是招更多工程师，不是优化系统架构——就是买更多GPU，喂更多数据。
Martin Casado（a16z合伙人）问了一个很尖锐的问题：
「想象一下，有个团队花5年时间、10亿美元造了个操作系统，然后他们直接把成品扔给你。你会觉得这东西能用吗？」
Ankur停顿了一下：
「我们正在造上帝。只要经济上可行，就继续砸钱让上帝聪明1%。」
但这句话有个转折——
「当你无法让上帝再聪明1%的时候，让上帝更高效就是一个疯狂的机会。」
这是个资本流动问题。只要这些公司能继续融资，「做蠢事」就是正确的策略。因为工程师无法规模化，但GPU可以。你没法让1000个工程师像10个工程师一样高效协作，但你可以把计算集群扩大100倍。
两个字：不够。
不够的不是模型能力，是下游企业根本消化不了这些能力。
Sonnet 4.5已经考满分了，然后呢？
Ankur提到一个细节：他们写了个Bash vs SQL的Agent基准测试（后面会讲这个测试有多精彩）。Claude Sonnet 4.5在这个测试上拿了100分——当然有限制条件，比如成本、错误率、延迟——但它就是「足够聪明」了。
「我们无法区分AGI和AGI++。」
对。当模型已经能完美回答99%的问题时，再让它聪明一点，对用户来说没意义了。 限制因素转移到了别的地方——比如企业政治系统能以多快的速度消化新事物，比如开发者能不能把这些能力真正整合进生产环境。
Ankur观察到一个有趣的分布：Braintrust的客户中，使用中国开源模型的「logo数量」很少，但「token数量」很高，而「美元权重」又很低。
这意味着什么？有一小撮非常精明的客户，找到了高频、稳定的使用场景（比如客服），然后死死咬住某个模型不放——甚至还在用Llama 3.1（在AI领域这已经是「古代新闻」）。他们不追新模型，因为团队已经深刻理解了这个模型的怪癖，知道如何榨取性能。
性能不是指模型多聪明，而是指延迟、准确率、成本的综合优化。
「想象一下，一个高频消费场景的客服系统。为什么要换模型？你可以让这个东西越来越优化。」
这些团队像在使用一个外星人留下的部件——不知道它怎么运作的，但知道如何驾驭它。
Eval不是测试，是产品定义
「Eval是什么？」Martin问。
「把科学方法应用到非确定性系统上。」
你提出一个假设：我换个新模型、调整Prompt、或者让Agent从API抓更多上下文——我觉得这会提升质量。然后你在一组输入上模拟运行系统，观察输出，定量测量差异。
但关键是下一步：用眼睛看。
数字说变好了，但真的好了吗？你要定性检查，用直觉校验，同时也给自己机会改进下一轮Eval。
「产品经理应该只做Eval。」
他的逻辑是这样的：过去产品经理写PRD（产品需求文档），描述产品应该做什么。但PRD是文字，模糊、主观、难以验证。Eval是可执行的——它是对「产品应该是什么」的声明式表达。 你创建一个好的Eval，就等于用代码定义了产品的边界。
在Braintrust内部，Ankur有个习惯：他会在办公室里踱步，手里拿个弹力球，抛来抛去，思考类型系统（type specs）。他手写类型定义，然后一堆测试会挂掉——这时候Agent开始跑，自动修代码。
当有人提PR时，他只看类型定义。
「如果我和提交PR的人在类型定义上达成一致，那剩下的代码大概率是对的。」
这是典型的数据库工程师思维：状态也是类型。 把一致性要求声明式地表达在类型系统里，而不是散落在代码逻辑中。
Bash是低质量工程思维
最近AI圈有个流行观点：「让AI用Bash，它什么都能干。」
具体做法是这样的：给AI一个Unix环境，给它curl、文件系统、互联网访问。有些人甚至搞了FUSE（用户空间文件系统），把每个客服工单映射成一个虚拟文件。还有人做了各种编程语言的虚拟环境，叫「Python Bash」之类的东西。
逻辑是：模型擅长Bash，那就让所有问题都变成Bash问题。
Ankur听到这个思路时，内心是拒绝的。
「这是低质量的工程思维。」
他做了个实验。Braintrust内部有个Agent叫Loop，他们拿它跑了Bash vs SQL的基准测试。任务是一样的，一个用Bash解决，一个用SQL解决。
结果「大到可笑」：SQL更准确、更高效、token消耗更少、速度更快。就连差一些的模型，在SQL任务上的表现也比Bash好。
为什么？
因为如果你要处理客服工单，SQL查询可以直接在元数据层面筛选，然后只看需要的那几条。而Bash要么curl下载所有文件，要么遍历虚拟文件系统——这是O(n)和O(log n)的区别。
「模型很擅长写代码，而写代码比写SQL难。所以它们完全有能力用SQL表达能用Bash表达的东西。」
真正的问题是：你如何组织数据，让模型能在SQL环境里访问它？
如果你在处理代码本身，那Bash确实是最细粒度的抽象——因为代码就是文件。但如果你在处理结构化数据，强行用文件系统映射它，就是在走弯路。
这里有个更深层的对立：
一类人说「给它一台电脑，让它自己搞」（brute force）。
另一类人说「给它计算机科学基础工具」（referential transparency、强类型、声明式约束）。
Ankur站在后者。「你低估了模型的智能，如果你逼它做蛮力的事情。」
为什么要随时准备扔掉Agent代码？
Replit的CEO Amjad跟Ankur说过一句话：
「每次新模型出来，我们都想扔掉整个代码库。」
Cursor有个工程师说过类似的话：
「想象一下，每次CPU指令集更新，你就得重写操作系统。」
这就是现在AI应用开发的现状。
Ankur的观点很明确：如果你在构建Agent，用预训练模型做的那部分——怎么提供上下文、怎么组织Prompt、怎么调用工具——这些都不应该被「工程化」。
「这应该是Bitter Lesson（苦涩教训）的一部分。你应该随时准备把它扔掉。」
什么是Bitter Lesson？Richard Sutton写的那篇著名文章：不要做工程，just scale it（扔计算进去）。
但Ankur接着说：
「真正区分好产品和烂产品的，是周围的工程——让你能建立从生产到测试的反馈循环。」
他提到一个客户（不能说名字，因为还没发布），已经在测试中国新出的模型了。新模型发布当天，这个客户就能精确知道它在哪些场景下好用、哪些不好用。
这个测试框架（harness）是高度工程化的。而框架里面跑的Agent逻辑，完全不工程化——这是故意的。
Cursor能用，是因为周围的工具链、反馈循环、测试体系是精心设计的。模型本身只是个可替换的部件。
阳光还能烧多久？
Martin问了个宏观问题：
「Anthropic这次融资的钱，可能比整个依赖它的生态系统加起来能融到的钱还多。这种情况下，工程什么时候才有机会？」
Ankur想了想：「要么钱理性化，要么模型训练遇到根本性的规模极限。」
但还有第三种可能：需求端饱和。
「Sonnet 4.5在我们的基准测试上拿了100分。你很难想出它真正会卡住的问题。但把这种能力整合进企业环境，还是非常非常难的。」
这是个有意思的重新框架：不是供给侧（模型能力）的极限，而是需求侧（企业消化能力）的极限。
企业有自己的政治系统，它消化新事物的速度有天然上限。即使每个人都在用ChatGPT和Gemini，企业内部部署AI系统仍然非常早期。
Martin说：「所以问题变成了：ChatGPT或Gemini会成为『万能应用』吗？」
Ankur笑了：「ChatGPT可以开始帮你洗衣服、做饭。我不知道这些公司在憋什么大招。」
但讽刺的是，如果你看解决方案空间，按美元权重算，真正需要自动化的那些场景（比如物理世界的操作），效果远不如「文本预测」类任务。
状态空间不一样。当你把问题映射到受约束的流形上——比如代码、语言——模型表现很好。一旦是开放式的，就不行了。
理论升华：上帝会变便宜
想象一下电钻和洞的故事。
你去超市买电钻，但你真正要买的不是电钻——你要的是墙上的那个洞。电钻只是达成目的的工具。
现在AI模型是电钻。企业要的是洞——客服问题解决了、代码写完了、分析报告出来了。
当前的局面是：电钻制造商（frontier labs）可以无限融资，造出越来越好的电钻。但打洞的人（开发者、企业）消化不了这么好的电钻，因为他们的墙（业务场景）没那么硬。
这时候会发生什么？
电钻开始分层。最好的电钻还是很贵，但「足够好的电钻」会变得非常便宜——中国开源模型、经过3个月蒸馏的小模型、专门优化过的fine-tuned版本。
Ankur观察到一个周期：新模型发布 → 所有人忘记开源模型 → 新模型停滞 → 开源模型追上 → 人们开始质疑闭源模型的意义 → 下一个新模型发布。
这个周期大概是3-6个月。
唯一的例外是：如果闭源模型停滞的时间够长，开源模型就有机会真正颠覆企业心智份额。
「问题是，闭源模型的发布频率足够规律，所以开源模型还没来得及真正搞破坏。」
但如果有一天，规律被打破呢？
局限性：这套逻辑在哪里失效？
Ankur的框架有个前提：模型能力增长会遇到天花板，或者资本会理性化。
但如果两个都不发生呢？
如果Anthropic能一直融到100亿、1000亿，模型一直能再聪明1%，那就不是工程问题了——那就是AGI。
另一个前提是：企业需求是有上限的。但如果ChatGPT真的变成「万能应用」，每天处理你生活的方方面面呢？那需求就不是线性增长，而是指数增长。
Ankur的观点更适用于B2B场景——那里确实存在政治系统的消化速度上限。但C端可能是另一个故事。
还有一个隐含假设：模型是「黑箱」，你只能通过测试来理解它。但如果未来mechanistic interpretability（机制可解释性）取得突破，我们能真正理解权重里发生了什么，那工程的定义可能会彻底改变。
两个问题，带着离开
第一个问题：你现在用的AI工具，是电钻，还是洞？
如果你在追最新模型，不断重构代码去适配它，那你在追电钻。如果你固定在某个「足够好」的模型上，把精力放在测试、反馈循环、数据清洗上，那你在挖洞。
第二个问题：你愿意用Llama 3.1吗？
那些还在用它的团队，不是因为保守，而是因为他们已经深刻理解了它的脾气。他们知道怎么让它在特定场景下跑得又快又准。
也许工程的机会，从来不在追逐上帝，而在驯服上帝。