AI 编程的收益为何不只取决于代码生成速度

Martin Harrysson、Prakhar Dixit 和同事 Shilpa 分享他们在为大型组织提供 AI 软件开发咨询时观察到的模式，重点是人员和运营方式如何改变。

Harrysson 说，最初的预期超过了实际结果：尽管广泛使用 AI，许多大公司报告的改进仍然有限。他说，在后来对数百家客户和大型企业的调查中，表现最好的 20% 至 25% 开始看到更大的端到端收益，约为两倍。

讲者将观察归为四个方面：重新设计开发流程、改变团队结构和角色、建立合适的技术与上下文层，以及管理组织变革。

Dixit 介绍，部分客户正从两周冲刺转向一至两天的工作循环：智能体处理任务，人验证结果，然后重复。团队决定人工审核应放在哪些环节，并随着信心增加调整边界。

工作流可以从构建和测试扩展到产品工作与发布。Dixit 说，当大型组织以多种方式存储背景信息时，标准化需求文档和规格等工作产物有助于智能体保持一致。

在人员配置上，Dixit 说，部分客户转向两至四人的小组。他表示，小团队不一定意味着减少总人数；组织也可能创建更多团队，同时扩大每个人的职责。

他描述产品相关角色向“定义者”汇合，开发和质量角色向“构建者”汇合。他说，行业尚未就这些角色的名称达成一致。

Dixit 认为，挑战在于围绕组织自身背景组合工具。长期任职的领域专家掌握的知识需要被记录下来，让智能体能够使用，而不是反复依赖同一些人。

他还强调信任：智能体落地必须配合治理、安全和稳定性。要从成功试点扩展到全组织，需要在运营模式、人员、技术和成本方面做好准备，包括 AI 财务运营。

演讲中被称为 Shilpa 的同事说，越来越难的不是找到技能，而是从大量可用技能中筛选适合组织工作的少数技能，具体选择取决于业务背景。

她提醒，代码生成加快可能与质量下降同时发生。她说，他们查看的报告显示，即使按每位开发者或每个拉取请求计算，错误和事故也在增加，因此审核能力应得到同等重视。

团队建议精选高质量的期望成果示例，而不是只向智能体提供现有代码库中的平均案例。政策、标准和质量检查应贯穿整个开发过程。

检查示例包括代码是否易于维护、是否足够简洁，以及能否与其他分支兼容。提前应用这些要求可以在最终质量门禁之前发现问题。

随着构建和测试加快，瓶颈可能向上游转移到需求和设计，向下游转移到发布，也可能横向转移到风险、法务、合规和设计团队。

对于上游环节，讲者建议让智能体获得相关企业背景，包括客户信息和日志，并将这些背景与需要构建的内容关联。发布要求也需要提前梳理。

Shilpa 描述了一个银行应用案例：颜色和无障碍规则需要与其他团队协调。如果这些并行要求没有被识别并提供给工作流，就可能成为瓶颈。

Harrysson 说，衡量影响仍是未完成的工作。组织在工具、词元和培训上投入资金，却往往不确定自己是否衡量了正确的结果。

他说，部分客户正探索用 AI 辅助评估工作价值并分配资源。他认为这个想法有前景但实施困难；既有工程指标仍有作用。

他介绍了一种近期管理方法：将原有团队拆成更小的小组、增加团队数量，可能提高并行能力。他说，随着时间推移，管理者仍需要更成熟的衡量方式。

讲者最后认为，成果依赖许多协调一致的变化，而不是引入单一工具。Harrysson 说，他看到部分客户获得了显著提升，并对发展方向保持乐观。