代码成本崩溃后的工程管理
代码成本崩溃后的工程管理
从生产到验证的转变
生产可信代码的成本已经崩溃，从根本上打破了许多传统工程管理实践所基于的假设。虽然生成“管道”——脚手架、样板代码和初始草稿——的速度已经加快，但软件交付的瓶颈已经从编写代码的行为转移到了验证其正确性并承担其部署风险的行为。
生产成本的崩溃
生产可信代码现在变得廉价且丰富。然而，这并不意味着工程组织会自动变得更快。收益在绿地工作和样板代码中最为明显，但在处理复杂现有系统的深度工作时，这些收益往往会减弱或逆转。
由于生产成本下降，传统指标如速度、拉取请求数量和关闭的工单数量变得具有误导性。当提升这些指标最便宜的方式是生成更多量，而量不再稀缺时，这些代理指标不再与业务价值相关联。持久的管理举措是衡量业务成果和系统健康状况，将代码量视为需要证明的成本，而不是值得称赞的产出。
重新定义正确性和验证
验证现在分为两个不同的类别：机械的和语义的。
机械验证
机械验证——检查类型、测试、合同和 lint 规则——正在变得更快，因为 AI 代理可以以人类无法匹配的速度运行测试循环并修复差异。这种效率只有在人类已经以机器可检查的格式定义了什么是“正确”时才可能。因此，投资于机器可检查的正确性（强规范和不变量）现在是组织可以进行的最高杠杆基础设施投资之一。
语义验证
语义验证——确保代码实现实际的业务政策并管理监管风险——仍然是以人为中心的任务。AI 检查器通常与 AI 生成器共享相同的训练数据和盲点，这意味着它们可能以相同的方式失败。
这导致了一个关键的悖论：虽然单个检查变得更便宜，但由于廉价生成邀请了更多的量，总的验证工作量实际上增加了。结果是事件特征的转变：组织可能会看到更少的“愚蠢”错误，但更多的系统性故障，因为大量可信的输出通过了大量可信的审查。
更新管理的“旧规则"
许多长期存在的管理准则基于已经不再成立的假设。为了保持有效性，这些规则必须重新校准：
- "主管不应编码"：这不再是关于交付功能，而是关于校准。主管需要足够直接接触 AI 工具，以区分一个真正更快的团队和一个仅仅以量产生“劣质产出”（自信但错误的输出）的团队。
- "保护团队免受业务干扰"：虽然保护工程师免受昂贵的上下文切换仍然有效，但剥夺他们业务上下文现在是危险的。在没有业务上下文的情况下提示 AI 的工程师会大规模地产出流畅但错误的工作。管理应从默认过滤上下文转变为有意选择特定上下文。
- "提交前需要共识"：共识用于不可逆的决策。由于可逆的技术选择现在更便宜地撤销，它们应由尽可能小的小组来做出，以保持速度。
- "我们需要更多人头"：人头请求必须根据工作是否需要人类判断或仅仅是生产来进行审查。协调成本和入职拖延无论语法成本如何都保持不变。
初级工程师管道危机
目前尚未有经过验证的方法在 AI 增强的环境中培训初级工程师。历史上，高级判断是通过执行 AI 现在吸收的任务来培养的：修复小错误和编写样板代码。如果编写的实践被移除，培养高级工程师的管道可能会中断，其影响可能只有在三到五年后才会显现。
管理角色的未来
管理正在分为两个功能：信息路由和判断。
- 信息路由：聚合状态并将更新转化为仪表盘。此功能正被 LLMs 商品化，其价值趋向于零。
- 判断和所有权：雇佣、晋升以及承担错误决策的后果。此功能无法自动化，因为它需要一个模型来理解组织的非书面信任关系和制度历史。
在“代理极限”中，组织结构图将停止记录谁生产，开始记录谁签署。人头将不再衡量容量，而是衡量组织能够承担多少责任和风险。
社区视角与反驳
虽然代码成本崩溃是主导叙事，但从业者讨论中出现了一些关键的反论点：
"假设是 LLMs 应该编写代码而人类工程师进行审查……我根本不同意这一点……理解代码仍然是瓶颈。但理解确实是在编写循环中获得的。"
一些人认为，AI 最有效的部署方式是让人类编写代码而让 LLMs 进行审查，从而保留深度系统理解所需的认知循环。其他人指出，“代码成本”实际上可能以技术债务的形式增加，因为 AI 允许代码债务的积累速度快于其清理速度。此外，一些人认为，软件组织的主要瓶颈从来不是编写代码的行为，而是团队组织、系统设计和工作优先级。