如果 AI 从一开始就存在：更便宜的代码并没有使决定什么要构建变得更容易

在软件历史的大部分时间里，昂贵的部分是构建它。团队花费数月时间将想法转化为可行的代码，这种稀缺性塑造了工作的组织方式。

路线图围绕可用的工程能力进行排序；架构师因为他们理解其他人不理解的系统而获得了席位；产品经理花费数周时间将模糊的商业需求转化为开发人员可以采取行动的东西。编写软件是瓶颈，自然地，编写它就是杠杆所在的地方。

但这不再是真的，而且这种转变发生得比大多数工程领导者有时间消化得更快。

AI 编码工具已经降低了实施的成本。因此，曾经需要一个工程团队数周的工作现在只需要一个代理几小时。显然的假设是，构建速度更快将直接转化为更快的价值交付。

然而，实际发生的情况更加复杂：团队现在可以生产出比他们知道如何处理更多的软件，而减慢他们速度的东西已经悄悄地转移到了其他地方。

“你不能将 AI 应用于一个破碎的过程，”intive 公司技术总监 Pablo Gamba 说。“这就像给一个工人一个更快的铲子。他会更快地工作，但只是在错误的方向上。”

更快的执行，相同的旧约束

每一次重大技术转变——互联网、云计算和离岸外包——都遵循相同的模式。曾经昂贵的东西几乎在一夜之间变得廉价，而公司为此建立的所有东西都必须被拆除和重建。

这次，变得廉价的东西是应用技术智能本身，这恰恰是服务公司和工程团队花费数十年收费的东西，Gamba 说。

更便宜的执行并没有使约束消失。它只是将其转移到了一个不太明显的地方。例如，编码瓶颈在向上迁移时，加速了实施，但现在障碍在代码审查中。自动化代码审查后，它出现在测试和部署中；自动化这些后，最后它落在了人类编写代理正在处理的规范上。

因为代理只能构建被描述得足够精确以便在不猜测的情况下采取行动的东西。

这是很多团队现在正在陷入的陷阱，往往没有注意到。如果你可以在以前需要数周手动编码的时间内的很小一部分时间内构建几乎任何东西，那么构建错误的东西的成本会增加，而不是减少，因为你会更快地发现你是错误的，并且已经交付了更多的东西。

一个假设曾经会在数周的手动编码中慢慢浮现，现在可能会在有人有时间质疑它之前变成承载结构的基础设施。优先级，而不是原始输出，决定了 AI 投资是否真正为自己买单。

在这种范式中，Gamba 认为公司应该跟踪的不是开发速度，而是从意图到生产的整个周期。“如果你提高了开发速度，但 QA 是你的瓶颈，你只是更快地到达了 QA。然后你解决了 QA，瓶颈转移到了需求，”他说。

数字也支持他的说法。使用 AI 辅助开发的财富 50 强企业比其同行提交代码快 3-4 倍，根据云安全联盟的研究，但引入了大约 10 倍的新安全发现。

没有明确目的的速度不仅浪费了精力，还会比大多数安全团队能够跟上的速度更快地积累风险。

将需求转化为 AI 可以利用的语言

如果定义是现在真正的约束，那么解决方案不是更多的文档，而是不同类型的文档，以代理可以在不填补空白的情况下执行的形式书写。

这意味着用结构化的验收标准、明确的域模型和合同测试取代为人类解释而写的需求文档，这些测试清楚地说明了一个功能应该做什么和不应该做什么。

代理以与初级工程师相同的方式填补模糊性，但不同的是，后者会带有犹豫，一个标志，一个可能有问题的迹象。

代理的猜测看起来完全不同。它以干净、流畅、完全成形的代码出现，没有任何犹豫，即使它是错误的。

编写能够在这种差距中幸存的规范开始感觉更像是一份合同，而不是一份产品简介。你必须命名每个角色，映射系统允许的每个状态转换，并考虑边缘情况，而不是悄悄地将它们留给快乐路径，就像大多数需求文档仍然做的那样。

将此类规范编写视为文档任务的团队会在实践中学习到，模糊的意图只会产生模糊的软件，以机器速度运行。

真正捕获到生产力收益的团队是那些将规范编写视为一门工程学科的人，具有与代码本身相同的版本控制、审查周期和测试严谨性。

用 Gamba 的话来说，AI 本地化不是跳过流程的许可，而是从头开始重新设计的要求。“许多组织试图将 AI 应用于旧流程。这不是转型。AI 本地化的组织从一个不同的问题开始：如果 AI 从第一天就存在，我们今天会如何设计这个流程？”

待办事项管理者，意图策展人

产品、架构和工程曾经作为三个独立的功能运行，具有干净的交接点：产品决定要构建什么，架构弄清楚如何构建，工程交付它。

一旦实施变得廉价和快速，这些交接点就变成了整个链条中最慢的部分。这里重要的是谁能同时掌握整个图景，将意图转化为代理可以执行的东西，并在变成交付的代码之前捕获糟糕的假设。

这种重新设计正在悄悄地塑造谁在定义什么以及这份工作现在是什么。

“想想软件工程师的角色正在发生什么变化。他们不再只是编写代码。他们正在监督代理的输出，定义规范，准备测试，验证结果。这是将三个独立的角色合并为一个，”Gamba 说。

换句话说，现在有价值的不是知道如何编写票或运行冲刺，而是知道在工作开始之前什么是“伟大”的，并且能够区分什么是智力上有趣的和客户真正需要的东西，并且有勇气在明显不符合标准时快速杀死一个想法。

这些判断曾经分散在产品经理、架构师和技术负责人之间，现在越来越多地落在了最初定义工作的人身上。

同时也要记住：这并没有使标题消失。但是它们之间的界限变得越来越难以辩护，而在这种模糊中茁壮成长的人是那些作为意图策展人的那些人。

没有防护栏的快速执行并不是胜利

一旦意图明确，AI 流水线真正高效运行，就很容易忽略一种风险：快速、明确定义的执行仍然可能引入以往较慢、更人性化的过程本来会捕捉到的故障。

数字并不接近。Veracode 的 2026 年春季测试发现，仅 55% 的代码生成任务在没有明确的安全指导的情况下产生了安全的输出，这个数字在过去两年中几乎没有变化，即使功能准确性已经大幅提高。

很明显，语法正确不再是难点。人类工程师在打字时本能地做出的判断，关于安全性、合规性以及哪些数据应该或不应该触及哪些系统，是很难被取代的部分。

这意味着定义要构建什么的严谨性必须扩展到定义什么是禁止的，例如合规性边界、数据处理规则和以与功能需求相同的细心编写的道德约束。

将这些隐含并希望代理正确推断出来是同一种错误，即将产品需求留得模糊，并希望构建结果良好。

领导力是什么样的

这并不是反对 AI 加速开发；构建从未如此快速或廉价，并且没有办法把它放回瓶子里。

但决定什么值得构建的精确度并没有变得更容易，甚至可以说变得更难了，并且描述它足够好以便机器能够忠实地执行，并在此过程中划出它不允许跨越的界限。

在企业级别，领先的团队并不是那些拥有最快的编码代理的团队，这一点很明显。它们是那些在竞争对手之前就已经弄清楚，定义一直是更难的问题——并且开始以这种方式对待它的团队。