当代码充裕时（31分钟阅读）

# 当代码变得丰富 来源：https://about.gitlab.com/blog/when-code-is-abundant/ 一月度假归来，我确信某些根本性的东西已经改变。 大语言模型已经发展到能够可靠且廉价地生成有用代码的程度，足以改变软件开发的经济学。各地的工程师似乎都在尝试同样的事情：不仅仅是向AI助手寻求建议，而是赋予智能体实际的工作，看看它们能走多远。 我开始思考，如果这种趋势持续下去会发生什么。当生产代码不再是构建软件的主要约束时，会发生什么变化？ 我在一月的一份董事会备忘录中记录了这些想法。五月，我在GitLab的第二幕（https://about.gitlab.com/blog/gitlab-act-2/）中发表了那篇论述的一部分：生产软件的成本和时间正在崩溃，机器将在人类指导下越来越多地构建软件，而软件开发的底层架构必须随之改变。 六月，在GitLab Transcend（https://about.gitlab.com/blog/gitlab-transcend-announcements/）上，我们展示了该架构的初始组件：为机器级并发重建的源代码管理、作为跨越软件生命周期的上下文图谱的GitLab Orbit，以及围绕智能体身份、策略、审批和审计的治理。 然后，在8月21日，Anthropic发布了*《AI原生开发生命周期手册》(https://claude.com/blog/the-ai-native-sdlc-playbook)*。它开头有一句简单的陈述： **“代码不再是瓶颈。”** 我同意。 Anthropic的手册务实地描述了当智能体能大幅加速实现时，开发生命周期如何改变：规划变得机器可读，交接变得自动化，验证进入循环，人类判断集中在关卡上。 让我感兴趣的是更深层的问题。如果代码不再是主要的制约因素，什么会变得稀缺？当人类、智能体和多个模型都以机器速度在整个软件开发生命周期中运作时，企业需要什么样的架构？当生成代码本身变得越来越丰富时，持久的价值会转向何方？ 在过去的八个月里，我观察到GitLab工程团队以及其他包括Stripe、Spotify和Amplitude在内的组织开始在生产环境中回答这些问题。他们的经验强化了我最初的信念。重要的变化不仅仅是AI能更快地生成代码。 **而是当实现变得极其廉价时，软件的经济学和架构也随之改变。** **制约因素从生产代码转向了信任代码。** 信任越来越依赖于模型周围的环境：上下文、验证、治理和证据。当组织同时运行多个模型和智能体时，这一层必须是持久的，并且独立于其中任何一个。而且，随着智能体编码了组织越来越多的工作流程、专业知识和运营知识，它们应该属于该组织，而不是提供底层模型或云服务的供应商。 ## 塑造一个行业的制约因素 六十年来，软件工程一直围绕一个事实组织起来： **代码是珍贵的。** 它之所以昂贵，是因为将业务意图转化为可靠的软件需要稀缺的人才，他们能在脑海中处理复杂的抽象。它很脆弱，因为小错误可能带来巨大后果。而且复杂性累积的速度远超任何个体所能吸收。我们构建软件的许多方式都源于这个制约因素。 我们保留旧系统，因为重建它们风险太大。我们在技术之间搭桥而不是完全替换。技术债务长期存在，因为偿还它会与客户本季度所需的东西竞争。 我们极其优化开发者的生产力，因为开发者生产的是稀缺资源。碎片化的工具、不一致的环境和笨拙的流程如果改变可能会减慢工程师速度，这些都会被容忍。 然后还有各种仪式：审查、批准、发布关卡、安全检查、变更流程和日益复杂的测试。其中大部分是为了保护创建成本高昂且出错代价也高昂的资产。而大部分价值根本从未被创造出来。对于每一个进入路线图的想法，还有更多因为稀缺的工程能力经济学而无法存活。 **我们花费巨大精力保护变更的成本，因为变更一直都很昂贵。** 这个制约因素开始瓦解。当如此根本性的制约因素发生转移时，系统其余部分最终也会随之移动。 ## 每一层抽象都揭示了下一个制约因素 这种情况以前发生过。 人类曾经直接用机器指令为计算机编程。汇编抽象了机器。高级语言再次移动了抽象层。每一层都让一个问题变得极其廉价，并暴露了隐藏其后的问题。 没人会哀悼手写的汇编代码。我们得到了更大的问题去解决。 大语言模型在技术意义上显然不是编译器。它们是概率系统，而非具有确定语义的确定性转换。但从经济学角度看，这个类比很有用：它们极大地减少了从意图到实现所需的人力。 关键区别在于： **代码生产正变得丰富。优秀的软件则不然。** 模型生成实现的速度远超人类。这并不意味着实现是正确的、安全的、高性能的、合规的、可维护的，甚至符合业务意图。这个差距才是重点。当代码稀缺时，难题是生产它。当代码变得丰富时，难题就变成了信任它。 **当代码珍贵时** | **当代码丰富时** ---|--- 保留遗留系统，因为重建成本高昂 | 当重建成本低于持续搭建桥梁时，选择重建 极度优化开发者产出 | 优化业务成果和学习速度 长期背负技术债务 | 当经济上合理时，偿还债务 只追求置信度最高的想法 | 低成本地测试更多想法 用流程来限制代价高昂的错误 | 用约束和验证来治理高容量的变更 **打字的成本掩盖了更困难的问题。AI正在暴露它们。** ## 廉价的迭代改变了策略 一个合理的反对意见是，打字写代码从来不是最难的部分。 更难的部分是决定构建什么。需求模糊不清。客户改变主意。团队彼此误解。重要的边缘情况只在软件遇到现实后才会出现。 这都是事实。 但这个论点假设犯错的成本保持不变。在六周后发现需求被误解代价高昂。这种代价产生了在最初阶段就做对的压力。需求文档、架构评审和精心规划是对昂贵迭代的理性回应。 **让迭代变得廉价，策略就会反转。** 你不再试图在实现前消除不确定性，而是开始尝试更快地学习。 另一个可能更重要的后果是：工程组织积累了大量知识，但这些知识从未成为软件本身的一部分。经验丰富的工程师知道哪个服务很脆弱。有人记得三年前某次部署为何失败。安全工程师记得导致上次事故的那类错误。今天，很多这样的学习存在于人脑中。当实现变得廉价时，更多知识可以变成可执行的。 生产故障变成了回归测试。安全事件变成了策略。性能需求变成了自动化约束。合规义务变成了持续验证。 **学习变成了代码。** 并非所有知识都是如此，可执行的约束也无法消除判断。策略可能错误。测试可能编码了昨天的假设。但组织知识可以越来越多地变得持久、可检查和可修订，而不是随着学习者的离开而消失。这是一种不同的制度记忆，也是代码丰富能提升质量而不仅仅是增加数量的一个原因。 Amplitude最近发布了一个引人注目的例子（https://amplitude.com/3x），展示了这种更广泛变革能产生什么成果。在六个月内，它将交付的拉取请求数量增加了两倍，而报告的每月漏洞从715个下降到319个。这并不能证明更多AI生成的代码创造了更好的软件。但它确实表明，更高的变更量并不必然意味着质量的同比例下降。 ## 每次被接受的变更的成本 我认为在这个转型期最重要的经济单位不是每行代码的成本。 而是**每次被接受的变更的成本**。 一个有用的软件变更包括生成、环境设置、上下文、验证、审查、修复和治理。AI正在压缩生成环节，这使得其他所有环节的比例更重要。一个组织如果让生成速度提高十倍，但CI、审查和验证保持不变，它不会变得快十倍。 **它只会转移队列。** 这正是约束理论（https://www.tocinstitute.org/theory-of-constraints.html）所预测的：移除一个瓶颈，系统就会暴露下一个。我们现在开始看到这种情况发生。 ## 当智能体投入生产后会发生什么 Stripe构建了名为小兵（minions）的内部编程智能体（https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents）。Stripe每周合并超过一千个拉取请求，完全由这些小兵生成。人类进行审查，但代码本身是由智能体生成的。 Amplitude记录了其开发流程为期六个月的改造（https://amplitude.com/3x）。拉取请求周期时间从5.2小时降至44分钟。前端CI从大约三十分钟降至三四分钟。 Spotify一直运行着一个名为Honk的后台编程智能体（https://engineering.atspotify.com/2025/11/spotifys-background-coding-agent-part-1），并已记录了超过1,500个AI生成的拉取请求合并到生产环境。 这些都是能力异常出色的工程组织，因此他们的经验不应被视为每个企业都即将以同样方式工作的证明。它们之所以有用，是因为它们已经走得足够远，暴露了下一个制约因素，而且其中几个制约因素反复出现。 Amplitude的开发环境积累了手动设置、缓慢的CI和不一致的工具。这得以延续多年是因为代码生产限制了变更进入系统的速度。智能体移除了这个节流阀，验证和审查就成了停滞点。 因此，Amplitude重建了基础设施：更快的环境设置、显著更快的CI，以及减少让人类和智能体都感到困惑的不一致模式。这些工作中很少是AI相关。它们是必要的基础设施工作，因为AI改变了系统的吞吐量。 目前，许多组织正专注于选择最佳的编程模型。 实际上，**一个三十分钟的CI流水线就能击败你指向它的任何模型。** 智能体不会消除现有的工程制约因素。它们只是更快地暴露它们。 ## 三种模式，而非一条成熟的曲线 大多数关于AI采用的描述都暗示了一个从传统开发到完全自主开发的单一旅程。我不认为企业转型会以这种方式发生。三种模式将在很长一段时间内共存。 （图示：AI辅助开发的三种模式） **模式1：人类控制的遗留系统** 具有未文档化的依赖关系和仍存在于人员操作知识中的系统。许多系统在退休或重写之前，将主要保持由人类控制。 **模式2：智能体加速的开发** 人类保持控制权，同时智能体协助实现、测试、迁移、审查、文档和安全分析。这是目前大多数企业开发所处的位置，也是我期望近期经济价值的主要来源。 它不仅仅是等待自主化的过渡阶段。智能体最有价值的用途之一可能是使现代化项目在之前无法证明其合理性的情况下变得经济可行。 **模式3：自主开发** 智能体运行实现循环，而人类提供意图、约束和监督。重要的分界线不是绿地项目还是棕地项目。而是执行是否保持人类控制，还是可以安全地作为闭环运行。 判断系统所处位置的一种实用方法是问三个问题：智能体能否利用可用的上下文进行有用的变更？无需人工阅读每一行代码，该变更能否被验证？如果出错了，是系统能捕捉到，还是必须由人工发现？这些答案越是依赖人，工作负载就越接近模式1，无论模型能力如何。 过早地试图将所有工作负载强制推入模式3，很可能是组织在这个转型期可能犯下的代价最高的错误之一。 ## 流水线运行内部循环 一旦Amplitude将前端CI降至五分钟以下，远程流水线就变得足够快，工程师可以并行启动多项工作，并在结果返回时进行审查。 Stripe从另一个角度达到了类似的架构，为小兵提供了隔离的、预热过的开发环境，这样多个作业可以并发运行而互不干扰。 目前大多数编程智能体的工作流仍从笔记本电脑开始。这是一个合理的起点。但它不太可能是最终的架构。 在智能体系统中，流水线成为运行内部开发循环的自然场所： **生成 → 构建 → 测试 → 验证 → 审查 → 修复 → 重复** 智能体持续工作，根据这些信号不断迭代，直到它能返回的不仅仅是看似合理的代码，而是满足组织定义约束的功能性、经过验证的软件。 更快的内部循环也增加了协调的需求。一千个各自有效的变更仍可能将系统拉向冲突的方向。随着AI压缩了开发生命周期各阶段之间的间隙，对意图的对齐必须成为持续性的，而非周期性的。 从架构角度看，这个循环之所以靠近代码仓库及其周边系统是有原因的。 流水线已经位于代码、构建系统、测试基础设施、安全控制、部署配置以及与变更相关的大部分历史记录旁边。智能体越接近这些系统，需要通过反复的远程调用和碎片化API重建的上下文就越少，它接收反馈的速度就越快。这很重要，因为机器速度的开发甚至会将少量的延迟和上下文丢失转化为系统级的瓶颈。 在那里运行循环也能保留工作的证据：发起变更的身份、适用的策略、运行的测试、执行验证的系统，以及做出最终决定的人或过程。当智能体处理变更时，这个证据链成为问责和持续改进的基础。它使审计变得容易，使回滚有据可依，并确保智能体的工作符合组织的策略，而不仅仅是模型的能力。 ## 信任是新的瓶颈 当我们回顾这段时期，代码生产本身可能不会被认为是根本性的转折点。 真正的转折点将是当组织意识到，他们面临的挑战不再是生成代码，而是信任它、治理它、验证它，并以机器的速度安全地部署它。 代码丰富时代的架构不会围绕着代码生成器构建。它将围绕着信任基础设施构建：一个独立于任何特定模型或供应商的层，它理解上下文、强制策略、验证结果，并为组织的整个软件生命周期提供证据。 构建这个基础设施的工作已经开始。GitLab正在构建它。其他组织也在构建它。最终，软件的价值将从代码本身转移到使其可靠和安全的系统上。 到那时，最稀缺的资源将不是编写代码的人，而是构建和维护这些信任系统的人。这是软件工程的下一个伟大挑战，它正好与代码变得丰富同时发生。 问题不是AI是否会改变软件开发。它已经在改变。问题是，当代码变得丰富时，我们是否会构建更好的软件，而不仅仅是更多的软件。