AI 在加速代码库。组织其余部分仍需要理解发生了什么变化。
当我们写软件开发生命周期（SDLC）演进时，焦点放在 harness、sandbox、编排与可观测性——那些能让企业真正用好 AI 生成代码的能力。
整个周期都重要，而不仅是代码生成，因为即便配置充分的系统 + 出色的 prompt，也在制造一个相当明显的问题：堆积如山的待合并 PR。合乎逻辑的下一步是闭合这个环：用更好的方式审查 diff，并为 agent 优先的工作流改造 CI/CD。
与此同时，我们关于 agent 组织架构图的文章看向一个相关问题。企业的近景演进，大概不是 agent 横跨无数角色与权限，而是 agent 在自己的组织架构下，被审慎地配置去做特定工作。
在这两个想法之间，有些我们花的时间还不够的东西。工程可以产出并交付显著更多的代码。但其他每个职能仍需要理解：那些代码改变了什么、它触及什么、接下来会发生什么。
代码库动得越快，这件事就越难。
让 QA 保持新鲜
这一切听起来很假想。让我们拿 QA 当组织里的一个例子。软件还装在 CD 里的年代，容错空间不大，但避免错误的方式也相当基本：一个 QA 人员使用软件，点来点去，记录卡顿与无响应功能。
世界变了。软件不再一年部署两次，持续改进的节奏挑战了「打包 > 测试 > 发布」的瀑布。我们看到从维护 E2E 测试转向单元测试，以及一堆为保持理智而生的 hack。无头软件出现，让最初那种测试方式有效性大降。移动端与其他形态出现后，要测的模式宇宙爆炸。QA 仍然非常重要，但需要更可扩展；随着新玩家出现，它变得可脚本化，并折叠进交付流水线。QA 工程师现在负责写测试，并在所有相关操作系统上执行这些测试。你仍需要并行化这些测试，某些情况下还要租用硬件或算力来测。
但过去十年，DevOps 兴起，使功能开关与渐进式发布更常见，降低了漏测 bug 的冲击。接着可观测性层出现，让人更容易看见并诊断失败模式。于是 QA 工程师角色再次演进：分配给测试的预算下降，分配给可靠性的预算上升。
现在，软件周期再次演进——我们正看着 agentic SDLC 的黎明。在这个时代，有几件事让更传统的 QA 方法重新变得相关。其一，代码生成的速度难以跟上。31% 的 PR 在零审查下合并，每个 PR 的事故数在翻 3 倍，等等。
规模不再是假想：OpenClaw 的最新发布——其历史上最大的一次——由 933 位贡献者的 16,000+ 个 pull request 组成，且项目自己承认「工作量与节奏的增加，既超出了 OpenClaw 的基础，也超出了我们用来发版的流程。」一次从安装清理开始的发布，变成触及消息、记忆、插件与安全的全系统重写。于是漏掉一个错误的成本再次上升——因为你很可能漏掉很多，且足以让软件失稳到超出 SRE 救火所能修复的范围。
另一个问题是：agent 优化的是代码能编译。仍有大量失败可能发生——目录中损坏的记录、失败的业务逻辑、跨租户数据暴露等等。所以你在寻找大量静默失败；若你希望客户信任你，真的不能依赖全部在生产中发现并修复。于是，agentic 周期正把注意力拉回预防性测试。这当然也催生了新一代工具——上次清点约 50 个——试图通过自身也被 agent 驱动，来跟上 agentic 开发。决定跑哪些测试、以及测试脚本本身，降低了手工负担，并让人能覆盖更多地面。
这代新工具与代码库的连接程度各异。许多完全没有——它们爬一个 URL 并建议通用测试。有些能看见 PR，有些能看见 diff，少数会对照 PRD 收窄目标测试范围，有些能看见生产运行与 trace。我们会论证：这正是 QA 必须去的地方——代码库以这种速度演进，需要有历史意识与智能，能跟上爆炸半径并据此优先测试。即便如此，它们大体仍会错过业务逻辑失败、未导致明显输出失败或崩溃的遗漏工具调用等。
追赶
我们正看着工程职能演进，并好好追问这对产品、销售、CS 等意味着什么。但我们仍过于狭隘地聚焦一个基本动态：代码发得更快 > 每个组织适配工作流。与其问产品能否写出匹配「Claude 加持的工程师推 PR」速度的 PRD，更好的问题是：产品是否对发布、待办、发布问题等有足够可见性，以推动正确的 PRD——尤其在体量已超越手工工作之时。
不只是对发布、待办与发布问题的可见性。而是对这些代码变更对你环境之影响的可见性，亦即成功仿真生产环境。
这对 QA 同样适用。随机抽样单元测试只能带你走这么远；当 AI 可观测性层能给你远更好的洞见——什么可能坏、该去哪里找真正伤人的静默失败——时更是如此。而 CS 呢，他们比推送超前多少？他们能否在大客户感知到变化之前警告他们，或在没有工程的情况下回绝不合理的功能请求？
更一般地：我们如何给组织其余部分足够的智能，去理解这个活着的、演进中的代码库，以便反应、准备，并大体跟上节奏？企业已在对 agent 平台本身问类似问题。在对 OpenClaw 大修的报道中，Gartner 的 Jaishiv Prakash 指出：组织试图理解 agent 的权威起止于何处、agent 如何与用户及其他 agent 隔离、以及重大行动能否被拦截、归因与撤销。这些是远超工程职能的可见性与控制问题。
中心无法维系
这就是我们选这个标题的原因。软件组织的中心从来不是代码库。它是对代码库的共享理解。产品、QA、CS 与销售都通过非常人性的机制与它同步：sprint review、发布说明、路线图会议、午餐时问工程师改了什么。那套机制假定代码以人的速度变化。如今已不再如此。
当代码库变成活物——自己发布、迭代、调试——那种共享理解就更难维持。QA 被迫变成代码库感知型，因为它崩得最早、最响。产品崩得更安静：PRD 写在一个可能已经变了的代码库上。CS 崩得更慢：客户在客户成功团队之前发现变化。但他们都在处理同一个底层问题。
我们不认为答案是把代码放慢。组织其余部分需要可观测性曾给 SRE 的东西：对系统实际状态的实时、可查询图景。OpenClaw 发布以微缩形式说明了这一点。运行时、记忆与集成共享身份、上下文与权威，因此一层的弱点可以影响整个 agent 工作流。没有任何职能只看一块碎片就能得到特别有用的图景。
称之为代码库智能：一层为依赖它的每个职能，翻译活代码库的状态与轨迹。为 QA 提供爆炸半径感知的测试优先级；为产品提供「已发布 vs 路线图」的真相；为 CS 在大客户感知变化之前提供预警。最终，每个团队上的 agent 可以像工程师订阅频道一样订阅代码库——这又把我们带回组织架构图。
工程职能得到了它的新一代工具。下一代属于合并之后下游的所有人。如果你正在构建它，我们很乐意聊聊。
本文由 RecodeX 编译自 The Center Cannot Hold（作者：Jump Capital），首发于 SandHill.io #301 推荐阅读。译文仅供学习交流，观点不代表本站立场，版权归原作者所有。