拥有和维护大型代码库为什么这么难
AI coding agents 生成代码效率提升,但现实中程序员仍需维护数十年的大型遗留代码库,这种矛盾使得代码库理解和所有权成为软件工程中最具挑战性的工作。
AI coding agents 生成代码效率提升,但现实中程序员仍需维护数十年的大型遗留代码库,这种矛盾使得代码库理解和所有权成为软件工程中最具挑战性的工作。
AI coding Agent 产出的代码比以往任何时候都多,但这个世界依然运行在庞大且已有数十年历史的 codebase 之上。为什么拥有并理解这些 codebase,可能是软件行业最困难的工作?
如今,如果还把 codebase 看作 prompt 产生的一个临时产物之外的东西,似乎显得有些不合时宜。
而如果你对代码本身的重视程度不亚于产品,那就更显得一点也不酷。
但为了在未来 5 年的软件行业中生存下去,这恰恰是我们大多数人都需要重新学会的工作。软件行业 72% 的就业岗位来自员工人数超过 500 人的公司。我们的同行中,很少有人供职于初创公司,独立创业的 X 网红就更少了。
支撑这个世界运转的软件并不漂亮、不新颖,也不整洁;它可能正像一条用了 30 年、到处都是坑洞的高速公路一样逐渐老化。但我们的世界就是靠它运转的。当你的账户达到限额时,银行正是靠它实时拒绝交易;保险公司正是靠它计算一位拥有两份或三份保险的投保人应获得的赔付金额;仓库扫描器中的芯片正是靠它,让 Amazon 能告诉你新买的袜子什么时候送达。Uber 靠它估算抵达时间,飞机靠它使用 RADAR 调整航线,你的工资靠它每月发放两次,办公室空调靠它自动启停,你喜欢的品牌靠它设计并印刷新 Logo,你床架边缘的斜面靠它完成精密切割,你家附近的杂货店靠它保持货架充足——这样的例子数不胜数。
我们每个人都彻彻底底地依赖着那些历经数十年构建、庞大而复杂的 codebase。
在一个 AI 工具可以从零开始、以快到让我们应接不暇的速度生成全新产品的世界里,这些 codebase 依然屹立不倒,维持着整个世界的运转。我们不能任由它们被时代抛在身后。
“我们已经不知道该如何追踪代码质量了。Vibe coding 会在系统里留下大量累赘,并让代码迅速过时。我们需要严谨的方法,确保自己不会把整个业务搞垮。”
——某全球前十大银行技术负责人
让我们向拥有这些 codebase 的人致敬。他们正是我每周都会交流的 Engineering 负责人,而他们承受的压力已经逼近沸点。那些帮助团队比过去更快写出更多、更好代码的 coding Agent,也在制造一场新代码的海啸,将 codebase owner 彻底淹没。
我们每个人都经历过 AI 编写的代码如洪水般涌来、等待审查,也都因工作内容发生的变化而感到筋疲力尽。正是这种痛苦,催生了新一波 AI code review Agent!对于需要用更大的沙袋抵挡洪水的开发者来说,它们价值非凡。我猜,code writer Agent 与 code reviewer Agent 之间的界限最终会消失;coding Agent 会变得越来越好、越来越聪明;整个开发工具市场也会继续解决眼前的下一个路障。随着 LLM 不断重塑我们脚下的地面,市场会从一个局部最优点跃向下一个局部最优点。
但与此同时,那个庞大的 codebase——拥有数亿行代码、数万个 repository,累积了数十年的 commit;在当前 LLM 架构下,它大到远远无法装进 context window,甚至无法在合理时间内 clone 到一台 VM 上——将持续腐化。海量新功能与 patch 正以创纪录的速度加入;不同 Agent 在不同部分采用不同的编码标准和规则;重复代码不断扩散;跨服务依赖变得愈发脆弱;代码与 UX 标准中的细微偏差,则制造出越来越隐蔽、越来越危险的漏洞。
“我想给团队提供最好的工具。但后来,我无意间听到一名开发者说:‘我不知道这段代码是干什么的,是 AI 写的。’”
——某全球前十大汽车制造商技术负责人
问题就在于代码的体量。Agent 正在以前所未见的速度制造一场新代码的海啸。电话竟然是从屋子里打来的!那些让我们加速的工具,正在亲手创造导致这些 codebase 崩溃的条件。
理解一个庞大的 codebase 是个艰难的问题。这不是在每位工程师的笔记本电脑上就能完成的工作。它既是 harness 问题,也同样是基础设施问题。
如果没有 grep,你的 coding Agent 根本做不了多少事情。事实上,Agent 所做的大部分工作就是 grep。LLM 简直太喜欢搜索了;就像一名刚入职、正在熟悉业务的新员工一样,没有什么方法比搜索更适合用来建立上下文和世界模型。经过整个行业一年的实验,事实已经相当清楚:写在 README 和 AGENTS.md 中的 repository 架构概览其实并没有产生多大影响,你的 Agent 最终还是会一路 grep,直到形成自己的理解。
但与 Agent 世界里的大多数问题一样,理解本质上也是一个上下文问题。想要理解那些规模庞大、支撑世界运转的 codebase,并不是 grep 就能解决的问题。看不见的东西,你就无法 grep。能够让你看见并理解一个拥有 5 万多个 repository 的 codebase 所需的基础设施,OpenAI、Anthropic 和 Cursor 根本没有在构建或销售。它们的 Agent 在解决小规模问题时表现得过于出色,以至于人们根本没有意识到,一个问题正在自己周围逐渐成形。
于是,那些由一群架构师花费 10 年、20 年乃至 30 年精心构建的庞大 codebase,开始逐渐退化。
一个季度接着一个季度,Agent 构建者不断刷新纪录,token 消耗量也持续飙升,因为在构建和采用这些工具这件事上,我们仍处于早期阶段。当你的增长速度超过历史上的任何一家公司时,为什么还要去构建一层基础设施,让人们能够查看、搜索、深入理解完整的 codebase 和全局图景呢?
“当然,Claude Code 可以完成这项改动。但我有 9 万个 repository 都要改。”
——某美国前十大银行技术负责人
世界上规模最大的那些 codebase,它们的 owner 理应得到更好的支持!这个世界需要能够让他们的工作变得更轻松的工具。
我并不幻想产品构建方式没有被永久改变。AI 赋予了开发者超能力,缩短了产品上线时间,也彻底改变了软件采购负责人在自研还是购买之间的权衡公式。但这一切并不意味着,我们已经不再需要确定性的业务逻辑。
最近,我与全球最大健康保险公司之一的一位软件高管交谈。他描述了一棵用于理赔赔付的决策树:拥有超过 160 个阶段,数十年前使用 COBOL 一丝不苟地构建而成,依赖极高的数据保真度,以及数千张数据库表和 data loader 系统;负责维护它的是一支内部团队,但他们一直无法维持足够的人手。这样的工作流无法直接交给 Claude;即便 AGI 到来,我们依然需要确定性。
但 coding Agent 可以编写代码,对这些系统进行现代化改造,并赋能维护这些软件的开发者和业务负责人。它们确实可以做到——前提是能够获得适当层级的上下文基础设施,具备深入理解 codebase 及其底层业务逻辑的能力。
这些 codebase 会发生变化,我们构建和维护它们的方式也已经改变。但未来只会出现更多代码,以及规模更大、复杂度更高、需要由我们的 Agent 来拥有的 codebase。
在这个世界里,那些承担起拥有并持续演进 codebase 这一挑战的人,都是值得赞颂的英雄。我们应当像赞颂守护公共社会的英雄一样赞颂他们——正是这些人让桥梁不会坍塌,让发电厂持续运转,让政府正常履职,并维系着更多社会基础设施。
我为 Sourcegraph 所构建的产品以及我们所服务的人群感到自豪。如果你正在经历这些痛苦,请联系我们,我们愿意提供帮助。
如果你想参与解决这项挑战,让世界上规模最大、最复杂的 codebase 更容易理解、监管和演进,请与我们联系。
破除组织中的阻碍。更快交付。
使用 Sourcegraph——面向企业的代码理解平台。