引擎换了，刹车没换
这两年，很多工程团队的画面都差不多。
代码出来得更快了。PR 变大了。提交更密了。文档、脚本、测试骨架一批批往前推。乍一看，开发像是终于甩掉了最重的那块石头。
可另一组画面也越来越常见。review backlog 堆着，CI 队列排着，回归测试卡着，线上报警一响，所有人还得回头翻半天：这次到底改了什么，谁看过，为什么会放过去。
速度确实上来了。轻松没有一起上来。
问题不难找。AI 先解决的是生成，团队真正吃紧的地方一直是反馈回路。东西做出来只是开始，后面还有判断、验证、回收、复用。哪一段接不上，前面的加速就会很快变成后面的拥堵。
一、写得快这件事，本身没有那么值钱
工程组织过去有个默认前提：产出是稀缺的。
代码要人写，测试要人补，文档要人整理，所以很多流程天然围着”怎么把东西做出来”来转。需求先粗一点，验收先松一点，PR 大一点也能忍，反正整体节奏不快，问题总有机会在后面慢慢消化。
AI 把这个前提掀掉了。
现在最不稀缺的，恰恰是第一版。样板代码可以先铺出来，接口文档可以先起草，SQL 和脚本也能很快凑齐。很多团队第一次感受到一种很奇怪的反差：以前最费劲的那一步，忽然成了最便宜的一步。
这会直接改写一件事。开发流程里最贵的，不再是”写”，而是”确认这玩意是不是对的”。
这句话说起来很平，落到现场其实很硬。一个人十分钟多写三百行，不代表另一个人能十分钟多看三百行。一个需求描述被补得更完整，不代表边界就更清楚。一个测试文件自动生成了，不代表关键风险已经被碰到。
写得快的价值，只有在后面的判断也跟得上时才成立。跟不上，快就只是把半成品更早送进队列。
二、卡住团队的，往往不是代码生成，而是判断没有出口
AI 做的是局部动作。判断是一整条链路上的动作。
让模型先起草一段代码，补几个测试，整理一页说明，这些都很适合交给它。可一个变更该不该合，风险算不算收住，接口会不会把下游一起拖乱，灰度要不要继续放量，这些问题没有一个发生在”生成”那一刻。
它们发生在后面。发生在 review 里，发生在验收里，发生在上线之后，发生在问题已经露头的时候。
很多团队现在的别扭感就出在这里。前面越来越顺，后面越来越堵。前面像开了快车道，后面像收费站只开了两个窗口。于是整个系统看起来很忙，吞吐却没有想象中那么高。
更麻烦的是，判断这件事很难补票。代码一旦先进了主干，判断成本就会上涨。等到 UAT 才发现边界没想清楚，返工会比早一点在 PR 里拦下来贵得多。等到线上报警才知道这个字段改动影响了别的团队，那已经不是 review 问题，而是协作问题了。
所以 AI 不是把管理变轻了，它只是把以前那些不太显眼的判断动作一下子照亮了。任务怎么切，PR 多大算合适，谁有资格拍板，什么算完成，什么必须回滚，这些动作以前也重要，只是没有今天这么贵。
三、真正先顶上去的，是工程基础设施
很多人一说反馈回路，脑子里先想到的是人，尤其是 reviewer。
其实第一道压力经常不在人身上，而在工程基础设施上。
代码从提交到上线，中间本来就要经过几轮筛子。CI 编译检查，自动化测试，UAT 回归，灰度发布，线上监控，日志和链路追踪。平时看着像背景设施，AI 把产出速度往前一推，它们马上从背景板变成了承重墙。
因为这些东西干的，本来就是把零散的人类判断固化成系统判断。代码能不能跑，老功能有没有被带坏，关键流程有没有断，部署后有没有冒出新的异常，用户行为是不是开始偏，这些问题总不能每次都靠几个人围着屏幕猜。
短板也会在这里一下子露出来。
CI 本来就慢，AI 只会让队列更快堆长。自动化测试覆盖不够，生成再快，也只是更快地把没验过的东西送进主干。UAT 还靠人肉回归，前面提速的好处很快就会被后面吞掉。线上可观测性薄，问题不会在提交阶段出现，只会直接从用户侧炸出来，到那时候所有人都觉得”怎么又是这个系统”。
以前这些基础设施更像保险。出事的时候才想起它的重要。现在不一样了。现在它更像刹车系统。刹车本来就不负责把车开快，但车一旦变快，先问的就该是刹车够不够。
四、Dashboard 可以越来越满，信号却可能越来越少
组织一旦觉得局面开始失控，第一反应通常是加指标。
提交量、PR 数量、review 时长、覆盖率、缺陷率、模型调用次数、自动化比例、文档产出、脚本使用频率。指标越堆越多，Dashboard 越做越满，会议里的截图也越来越热闹。
可热闹不等于有用。
AI 特别容易制造这种错觉。因为它太擅长把局部动作做得很像”在前进”。代码更多了，文档更完整了，提交更密了，很多流程看上去也更现代了。但真往下问，团队到底学到了什么，经常答不上来。
哪些任务切法值得保留。哪些 review comment 应该上升成规则。哪些失败是一次性的，哪些失败会反复回来。哪些经验换个人就带不走。很多真正重要的信号，并不长得像漂亮指标，它们更像一些很笨的东西：一个 PR 有没有小到能认真看完，一次回归是不是打到了关键路径，一个事故有没有留下新的 checklist。
指标不是越多越好。回路也不是看起来越密越好。信号太多，组织常常不是更会学习，而是更会淹没学习。
五、工具普及得很快，组织学得没那么快
最容易被低估的，往往就是这一层。
个人提效和组织能力，中间隔着一次翻译。
一个工程师把脚本写快了，一个测试把用例骨架先搭起来了，一个分析师更快整理出了一版方案，这些都是真的进步。但这些进步不会自动沉到组织里。没有翻译，这些就只是个人技巧，不是团队能力。
翻译靠什么。靠把局部经验变成默认做法。
哪些任务适合先让 AI 起草，哪些任务必须先把验收写清楚，哪类改动必须先压小 PR，哪些 review comment 以后不用再重复写，什么样的失败应该进模板，什么样的成功值得写进 onboarding。没有这些动作，组织里就会出现一种很熟悉的局面：谁会用谁提效，换个人就掉回去；每个人都在摸索，团队却没有明显变聪明。
AI 普及和组织学习不是一回事。前者靠工具铺开就行，后者得靠反馈回路把经验接住。工具可以买，回路得自己长。
六、接下来拉开差距的，多半不是写代码的速度
把这些线索放在一起，能看到的方向已经很清楚。
AI 时代最先拉开团队差距的，大概率不是谁先把代码写得更快，而是谁先把反馈回路接顺。谁的任务切分更利于判断，谁的 review 真能拦住坏变更，谁的 CI、测试、UAT、可观测性能承住更高频的提交，谁更早把局部经验翻成团队默认动作，差距会从这些地方慢慢拉开。
很多组织还会继续盯着前面的速度，因为那一段最容易看见，也最容易展示。真正难的，是承认后面的慢动作才是主战场。那些动作不炫，也不好截图，甚至听起来有点老派：小一点的 PR，清楚一点的验收，硬一点的回归，少一点的噪音指标，勤一点的复盘。
可最后决定系统有没有学会的，往往就是这些慢动作。
当然，反馈回路也不是越紧越好。判断点越来越多，组织会更稳，也可能更保守。每一步都要求可 review、可追溯、可解释，会不会把一些本来值得冒的险也一起拦掉，这个问题没有现成答案。
但有一件事已经摆在眼前：AI 把生成提速这件事做得差不多了，组织能不能跟上，接下来看的就是反馈回路。
参考：Evan Phoenix《Agile in the age of AI》；Discord 指标压缩案例；Kevin Goldsmith《Becoming a business leader, not just a technical one》