一个人并行跑六个 agent：AI coding 改了什么，没改什么

关于 vibe coding 的争议一直没停。一边把它当许愿池，什么活都扔进去；另一边直接贴"垃圾代码工厂"的标签。两种我都不能接受，工具不是信仰问题。

与其站队，不如讲讲它到底改变了哪些维度，又没改变哪些维度。

两个方向相反的信号

先看最近两件事。

一个是 Karpathy 本人。2025 年 2 月他在 X 上抛出 vibe coding 这个说法——"完全交给 vibes、拥抱指数、甚至忘掉代码本身的存在"——当年就被 Collins 英语词典选成了年度词。然后 2026 年 2 月，他自己跳出来说这个词已经过时了，现在他用的说法是 agentic engineering：99% 的时间你不是在敲代码，是在编排 agent 并做 oversight；engineering 是为了强调这事有门槛、有手艺。

另一个是 Amazon。2026 年 3 月 5 日他们主站宕机 6 小时，追因发现又是 AI 辅助代码引发的连锁故障。上一次是 2025 年 12 月，自研的 AI 编程工具 Kiro 把一个 AWS Cost Explorer 环境删了重建，在中国区触发了 13 小时故障。内部会之后 Amazon 下了一条新规：初级和中级工程师写的 AI 辅助代码，必须由一位 senior 工程师签字才能进生产。

看上去方向相反，其实是同一件事。Karpathy 把词从"体验"（vibe）换到了"你得负责"（oversight + engineering），Amazon 直接把"你得负责"写进了章程。一个是观念层面的转身，一个是制度层面的落地。

真正值得想的不是谁对谁错，是它改变了什么、没改变什么。四件事讲清楚，大多数争议都会自动安静下来。

宽度：一个人的工作面被拉开了

以前一个人一天能做的事很有限。你的领域、技能、手头能同时推的项目数，都被"你是一个人"这件事实压着。

现在 coding agent 能接长程任务，工作面就被拉开了。

举个我最近几周的日常。主线是一个叫 Aima 的 AI 硬件产品，agent 写新功能、占机器跑 UAT，我 review 测试结果再给下一轮意见。这是条标准的串行链，但每个节点之间我都有大量等待。空档里就可以启动第二条线：Aima 背后的云服务最近有不少稳定性问题，另一个 agent 去查根因、补架构洞、再进 UAT 循环。第三条是研究分支，边端硬件里还没被榨出来的推理性能，算子要做 AB 测试、编译、跑准确率，成果不保证，但 token 够用就让它一直跑。第四条是 agent 框架本身的效率研究，打包成独立运行时扔机器上跑，另起一个 agent 做数据分析。加上个人主页的小改动，以及周末花一天多给儿子做的认字小游戏——他最近在学校因为不认字拿不到小红花——一共六条线同时在跑。

听起来像吹牛。但实际体感不是因为我有多能扛，是因为每条线里"等 agent"的时间本来就很长。这套模式在 2026 年已经有了通用名字：parallel agent coding，git worktree 做隔离是主流基础设施，大多数人的物理上限在 5 到 7 条同时跑，再多会被 review 和合并成本吃掉。

这事有一个不太被讨论的副作用：它在悄悄改变一个人的"职能身份"。我过去一直觉得自己是产品经理兼半个开发，现在这个身份在往外长，同时包含产品、运维、研究甚至家庭教育。不是我变成了超人，是工具把单人能覆盖的宽度抬起来了。

速度：天花板被挪开了，但"快"本身不再是优势

过去做一个东西有物理上限。你打字再快一天也就那么多行，脑子再快也只有两只手。

AI 把这个上限挪开了。最能感到的场景是拿 demo：以前黑客马拉松 48 小时能拿出一个能看的东西就算好成绩，现在同类事情以"天"为单位拿出草稿级 demo 是常态。不是说它打磨好了，是它能被看到、能被玩、能被用来讨论下一步。

但有个挺别扭的副作用：当所有人都能"快"的时候，快本身就不再是优势了。

过去动作快是加分项，慢的会被讨论。现在动作快是入场券，慢的直接出局，而快也不会再被单独表扬。这在组织里是个结构性变化，很多以"速度"为核心激励的团队会卡住：奖励发不下去，绩效评估全是满分，焦虑感反而在上升。

更麻烦的问题藏在下一层：快了之后，质量怎么办。

质量：从工作问题变成预算问题

质量和速度的矛盾从来不是 AI 特有的问题，项目管理课本第一章就是它。但 AI 确实把这件事的形态换了。以前质量是"你招多少人、流程多严、review 多细"的工作问题，现在它更像一个预算问题：你愿意给它多少 token，它就能做到什么级别。

极速：写完合入上线，3 小时搞定。

稍微严肃：让 agent 做一轮代码 review，再做一轮设计层面的 review，有问题改完再来。

做得像样：合入前过单元、集成、UAT。UAT 这一关我用得越多越觉得绕不过去，很多问题是链条级的，不真正模拟使用流程就看不见。好处是 agent 现在能自动化跑 UAT，能操作、复现、给 trace，你只要核验结果。

再严一点：接 CI/CD，加 smoke test，推 staging，在 staging 上再做一次 UAT，全绿了再上生产。

每加一层，时间多一倍，token 多几倍。功能本身 3 小时能完成的，走完全链路 12 小时打底，token 30 倍起。

30 倍看起来像浪费，其实不是。CodeRabbit 2025 年底对 470 个 GitHub 开源 PR 做过对比分析，AI 共同生成的代码里 bug 数量比人类代码多约 1.7 倍，在最容易引发下游事故的那类逻辑和正确性问题上高出 75%。

换句话说，agent 第一轮输出的统计平均，就是比人差。你不往质量上多烧 token，差距就原样带进生产。但反过来，只要你真的肯跑几轮 review、做一次像样的 UAT，我的体感是它能追平、有时候还更稳——不是因为 agent 变聪明了，是它有近乎无限的耐心做重复核对，而这恰好是人类最容易走神的环节。

所以在我这里，质量不是"要不要用 AI"的问题，是"给它留多少预算"的问题。

责任：最有争议，也最没得商量

前面三条都在讲怎么用好工具。第四条是用完之后账算在谁头上。

最常见的误用是把责任甩给 AI。功能挂了说"AI 写的"，决定做坏了说"模型建议的"。这个框架一开始就是歪的。

AI 不是责任主体。你赢了它拿不走工资奖金，输了它也赔不了，承担不了法律后果，也没有"补救"这个概念。签字盖章的永远是人。

2026 年那两件事其实都在说同一件事：Amazon 的新规不是"禁用 AI"，是"AI 参与可以，但有一位人类 senior 必须背书"；与此同时很多开源社区也在更新贡献指南，明确 AI 不被视为 co-author，提交者对每一行代码负全责。两边逻辑一模一样——AI 能参与，签字的是人。

这个共识一旦讲清楚，很多关于 AI 的焦虑就会自动降温。

组织层面为什么对 vibe coding 反应这么激烈？因为它冲的是三个传统管理假设：职能分工按"单点深挖"切，速度默认越快越好，质量靠人力 review 把关。agent 一上这三条都动摇了——一个人横跨好几个领域，速度远超原有审核节奏，review 通道瞬间被淹。组织的慌很合理，但解法不是禁用，是把"责任主体是人"讲透，然后围绕这一条重新设计分工、速度门槛和质量关。

Karpathy 把 vibe coding 换成 agentic engineering 这个动作我是认的。它把重心从"体验好不好"挪回了"你是那个负责的工程师"。你不是在享受 vibes，你在 orchestrate，在 oversight。

写到这里

AI coding 不是一件需要站队的事。

说它万能，或者说它有毒，都跳过了太多细节。这个工具真正做的事，是把四件本来紧紧耦合的东西拆开了：宽度变成杠杆，速度变成入场券，质量变成预算，责任没动。

前三条决定你用得好不好。第四条决定别人敢不敢跟你合作。