模型这一侧的提速还在继续：新一代模型不仅生成更快，面对不同意见也更有自己的立场，会坚持论点而不是顺着用户改口。按理说，写代码这个环节被加速之后，软件应该更快做出来。
但一个流传很广的说法恰好相反：许多非技术岗位用上 AI 之后确实省下了时间，写代码的人反而更累了。累的原因不难推断——当单个任务的成本足够低，一个人会同时开更多的项目、尝试更多的想法，需要盯着的东西变多，出错的总量也在涨。提速发生在个人的产出侧，而软件真正到达用户，中间还隔着构建、测试、签名、审核、发布，以及让多个人的改动彼此兼容。这些环节大多不在模型的能力范围内，也基本没有跟着变快。
迭代速度是一种组织能力
从发现一个苗头，到把它做成能用的产品，这段路在不少组织里仍然漫长。一个直接的证据是：拥有最好的模型、最资深工程师的大团队，产品迭代速度却常常落在小团队后面。慢的原因不在模型侧，也不在人才供给——真正难以解释的，是同样的人员配置为什么产出完全不同的节奏。
有人把希望寄托在“用量”上：既然模型按 Token 计费，那就把用量拉满，让 AI 参与尽可能多的环节。但单纯堆高用量并没有换来相应的交付速度。讨论中把这称为 Token Maxxing，结论是它没用——各家公司都做了提效动作，真正的问题“组织到底怎么搞”仍然没有答案。用量衡量的是投入，交付衡量的是结果，两者之间缺的正是组织方式这一环。
协作架构是更难的部分
写代码可以由一个人完成，交付几乎总是需要一群人。人越多，协作就越难，这是一条长期成立的经验。
有两项值得注意的外部观察。其一，从外部看，OpenAI 的 Codex 团队规模不小，却维持着很快的迭代和较少的内部冲突，而另一些曾经很快的同类团队已经慢了下来。这种对比只能说明协作架构存在差异，其内部的具体做法并未公开到可以照搬的程度。其二，海外存在一类设计工程师：同时具备工程能力、设计能力和产品判断，AI 补齐了剩余环节之后，他们可以自己发版。这个角色说明的是闭环的价值——当一项工作从需求定义到最终发布由同一个人把握，交接成本就消失了。
需要强调的是，这两条都不是可以直接套用的组织处方。“每个人都应该成为全栈”不是本文的结论；它充其量指出一个方向：交付慢的组织，瓶颈往往不在个人能力，而在人与人的接缝处。接缝怎么重新设计，目前没有通用答案。
个人侧恰好提供了一个对照。一次使用 Codex 定时任务的体验里，任务好几天没有出结果，让 Agent 自查之后才发现，它在这几天里顺手修掉了几个展示 Bug。单个用户与单个 Agent 之间，闭环可以小到不需要任何组织。组织交付的难处在于，同样的闭环要跨越很多人，而每一个交接点都是一次可能的速度损耗。
判断交付，别只看用量
如果用 Token 消耗量、生成代码行数、调用次数来衡量 AI 带来的进步，衡量的都只是个人产出侧的速度。组织交付能力要看的是另一组指标：从想法到上线的周期有多长，发布环节是否顺畅，多人改动合并时冲突多不多，出了问题多久能修好。
这些指标目前很少被公开讨论，也更难被“用量”叙事掩盖。对正在把 AI 引入研发流程的团队来说，值得先回答的问题也许不是“还能给模型加多少任务”，而是“一个想法从提出到上线，现在要经过几道手”。这道坎不在模型的下一步更新里，而在组织自己的设计里。