软件编写速度的大幅提升已不再是开发团队面临的唯一挑战。随着Cursor等工具从开发环境中的代码建议，转向根据规格说明和工单执行完整任务，问题可能转变为：企业能否确定哪些内容值得构建、测试并安全部署，然后对其进行运行和维护。
这正是Hannah Foxwell题为《重新发明开发团队》的演讲主题。演讲更关注代理式编程对人员和流程的影响，而不是代理本身的能力。Foxwell围绕三个支柱展开论述，并认为无论工具加速到何种程度，这些支柱仍然重要。
从速度不足到能力过剩
Foxwell描述了一条发展路径：团队最初每年发布两次软件，随后经过敏捷开发、云计算、DevOps和持续交付，发展到每天多次部署。她认为，过去被描述为遥远目标的高速开发，已经开始成为现实，而企业尚未学会如何利用这种现实。
在代理式编程模式下，代理可以拆解规格说明，编写代码和测试，然后协助部署与监控。但这种能力可能对产品管理形成反向压力：开发团队执行工作的速度，可能超过企业提供清晰且合格需求的能力。因此，Foxwell并不认为解决方案是接受每一个想法或请求，因为那可能导致产品臃肿且缺乏重点。
第一项支柱：构建值得构建的产品
Foxwell强调，代码不是目的，而是解决用户真实问题的手段。随着验证想法的成本降低，最好先创建原型并与用户进行测试，再将其转化为产品内部的长期承诺。
文章提出的模式包括“编写原型的产品经理”，以缩短想法与测试之间的距离；当想法超出快速原型制作能力时，则让产品经理与开发人员配对。文章还提到现场工程师的角色，即在客户身边工作并获授权解决客户问题的工程师；以及“产品工程师”，他们因为是产品用户或接近产品用户而参与产品塑造。
Foxwell介绍了重新思考团队规模和人员比例的实践。有些企业不再采用由六到八名开发人员和一名产品经理组成的团队模式，而是测试规模更小的团队；Andrew Ng则提出了相反的模式，即由两名产品经理配备一名能够协调一组代理的开发人员。这些模式并非固定规则，而是反映瓶颈点正在从开发能力转向需求清晰度和决策速度的实验。
另一方面，文章警告不要采用这样的做法：发布功能后立即转向另一项任务，却不检查其使用情况；接受客户提出的每一个请求；或把薪酬最高的负责人意见当作优先级标准。在软件编写变得更快的环境中，用户研究、用户体验以及验证价值的能力，可能比执行速度本身更重要。
第二项支柱：速度需要安全性
变更规模的增加需要能够跟上变更的生产流程。Foxwell警告，测试覆盖率不足和手动步骤可能使部署流程变成瓶颈，导致变更在到达用户之前不断积累。
因此，文章将速度与自动化测试联系起来，并提到一些使用代理创建持续测试、帮助团队处理技术债务、从旧平台迁移以及重构代码库的例子。关键并不是在缓慢流程之上添加人工智能，而是重新设计通往生产环境的路径，使其能够承受新的变更速率。
Foxwell强调，可靠性和安全性不能作为换取速度的可接受代价。她建议采用指标、服务目标水平和错误预算，并制定书面政策，明确企业在超过可接受失败水平时将采取的措施，例如放慢发布速度，或将资源转向可靠性和韧性。
她还认为，渐进式部署、功能标志、A/B测试和蓝绿部署有助于管理大量变更，而不必一次性让所有用户接触这些变更。她重新审视了站点可靠性工程团队和内部平台团队的角色，将其视为提供咨询和赋能的职能，为开发团队提供安全且顺畅的路径。
实际会发生什么变化？
从这场演讲得出的编辑性结论是，代理本身并不能证明开发团队一定会变小，或岗位一定会消失。可以确定的是，瓶颈点将会移动：从代码生产转向问题选择、价值验证、扩大测试、控制可靠性以及快速决策。
悬而未决的问题是，企业会利用新能力构建更好的产品并测试想法，还是会以堆叠更多功能来回应这种能力。开发人员、产品经理、平台团队和可靠性团队之间的新比例仍处于实验阶段，并非已经得到证实的结果。因此，采用代理式编程需要衡量其对产品质量、事故和用户体验的影响，而不能只关注代码行数或发布速度。