上周五 Ars Technica 发了一篇，标题直白得像结论：AI coding agents generate more code, but not more software。
一句话讲清楚：写代码这一步被加快了，软件没有相应地多出来。
我挑这条，不是结论新。圈里谁不知道 agent 出活儿快。是这回给的是别人家后台的数字。不是问卷，不是开发者自评"我觉得效率提升了 30%"。
研究出自哈佛两个人，用的是 Jellyfish 的聚合数据。3 亿条工作事件，70 多万员工，700 多家软件公司，从 2021 年一路拉到今年三月。
方法里有一套 difference-in-differences，老实说我只懂一半，先放在这里，等我彻底搞清楚再补一句。但下面这些数够直白。
agent 上线后，代码行数涨了 30%，commit 涨 20%，PR 涨 23%
点评：这三条大概率会被各家拿去当宣传材料。往下多看一张。
但 Jira 里那些 issue 和 epic 的解决率，没有统计上显著的变化
点评：issue 的大小和复杂度分布也没变。写得多，关得不多。我更愿意说得土一点：活儿没多，只是从写的人手里挪到了看的人手里。
PR 从提交到合并的平均时间涨了 49%，被打回要求改的比例差不多翻倍，每条 PR 的评论多了 35%
这条是整份研究里我唯一读完想改自己工作流的。评审的人多了 14%，说明不是没人管，是人手也在加。加完还是慢。
到今年三月，80% 的公司用上了某种 AI 评审，但 AI 只写了 23.3% 的评审评论和 10.8% 的 PR
点评：工具在帮你看，判断还是你的。这个比例说明的不是 AI 不行，是"这段代码该不该合"本身就难。
就业：研究者没能在总活跃人数上找到显著变化，还对着 LinkedIn 交叉验证了一遍
点评：这条我不确定值不值得单独收。短期数据看不出替代，也看不出不替代。先放着。
补充一句，报道里还有个数说 95% 的公司已经上了 agent，和 80% 那个数我没能对上，先放在这里，不硬解释。
一句话搞懂：评审瓶颈
评审瓶颈，就是活干完了但卡在"看"这一环，交付跟不上。
- 生成变快，不会自动让评审变快。
- 评审慢不是因为懒，是因为要多判断一份没经过人手的代码。
- 加速的收益如果不落到评审这一环，就只在中间堆了一层库存。
记住第三条就够了。
评论区里被编辑挑出来的一条留言我印象更深。大意是：现在的工作方式是按 AI 的速度造一堆代码，然后一堆人得在发布前把它看一遍、清一遍，而 SLA 又让谁都不愿意当那个卡住流程的人。
这条比研究本身有用。49% 不是技术问题，是激励问题。你没法用更好的工具去修一个"没人愿意踩刹车"的局面。
所以这期我其实只讲了一件事。
写，从来不是瓶颈。看，才是。以前看不出来，因为写得慢，看的人时间够。现在写得快了，看的人时间不够，这块短板就露出来了。
有人会说，我又不在公司，没有 PR 流程，没有 code review，这套跟我没关系。
有关系。你自己就是自己的评审。让 agent 一口气甩出三百行，跑通了不等于你看懂了。这笔账只是延后，不是免了。
上个月我收过一条类似的，说 vibe coding 让人基础不牢。当时我觉得那个说法有点老气。现在改口一半：不牢的不是语法，是判断。你把生成这一步外包出去之后，"这代码能不能要"变成了你唯一要亲自做的事，而你恰恰最没练过这个。
所以我现在觉得，vibe coding 里最值钱的能力不是把 prompt 写得漂亮。是看完一段代码之后敢说"这段能要"或者"这段不能要"。前半句工具能帮你，后半句没人能替你。
门槛确实在降，这个判断我没变。但它降的是写那一段。写完之后还有一段，从来没被降过。AI 写得越快，那一段占的比例越大。
本周就这些。
上面有任何一条你试过、或者觉得我讲错了，欢迎告诉我。讲错的我补，没讲清的我改。
下周见。