为什么优秀开发者对智能体开发如此警惕？
内容提要
Thoughtworks首席技术官Rachel Laycock指出，资深开发者对智能体开发持谨慎态度，并非担心失业或失去编码乐趣，而是深知“构建完成”不等于“生产可用”，担心智能体生成的代码缺乏正确性、可维护性和生产稳定性。实验显示智能体虽能快速产出代码，但构建频繁失败，给持续集成与交付带来新挑战。她主张领导者应区分合理担忧与抗拒变革，为实验创造空间；开发者应带着经验参与探索，共同规划未知领域。
延伸解读
“构建完成”不等于“生产可用”
文章指出，资深开发者对智能体开发的警惕，核心在于他们深知代码能快速生成，并不代表能在生产环境中稳定运行。他们关心的是行为是否正确、边界是否合理、系统能否演进、故障时如何应对。这些担忧源于对“把事做对”的长期坚持，而非对失业或失去编码乐趣的恐惧。
实验揭示的持续集成困境
Thoughtworks的实验让智能体完成全部编码，结果应用虽能运行，但构建频繁失败。作者强调，持续红构建会让人麻木，失去对检查的信任，而绿构建也不再令人安心。这恰恰是持续集成原本要消除的不确定性。DORA 2025研究也显示，AI采用率提升与交付吞吐量增加、交付稳定性下降相关。
经验判断在未知地形中的价值
作者用滑雪类比说明，资深开发者不是不敢尝试，而是像面对未标记地形的滑雪者，在问合理的问题。他们担心的是在缺乏护栏的情况下完全放手。文章主张，领导者应区分合理担忧与抗拒变革，为实验创造空间；开发者则应带着经验参与探索，共同绘制未知领域的地图。
Q&A
为什么优秀开发者对智能体开发持谨慎态度？
因为他们深知“构建完成”不等于“生产可用”。他们担心智能体生成的代码缺乏正确性、可维护性和生产稳定性，例如构建频繁失败、测试不可信等。这种谨慎源于对构建正确软件的重视，而非害怕失业或失去编码乐趣。
Thoughtworks的实验揭示了智能体开发中的哪些问题？
实验显示，智能体虽能快速产出代码，但构建频繁失败（红色构建），且出现“在我机器上能跑”的情况。团队花费大量时间在白板前设计领域边界和反馈机制，但持续集成面临挑战，如并行智能体冲突、系统模块化不足、变更速度超过检查速度等。
在智能体开发时代，持续集成和持续交付面临什么新挑战？
智能体开发导致构建频繁失败，使红色构建失去警示意义，绿色构建也不再令人安心。DORA 2025研究指出，AI采用提高了交付吞吐量但降低了交付稳定性。团队需要重新思考如何解决“最后一英里”挑战，持续交付/DevOps运动可能迎来复兴和重构。
领导者应如何应对开发者对智能体开发的谨慎？
领导者应仔细倾听，区分合理的担忧与对变革的抗拒，并为实验创造真实空间：给予时间、允许犯错，且不以智能体生成代码的数量衡量成功。同时，应让经验丰富的开发者参与探索和规划未知领域。
开发者应如何在智能体开发中发挥经验的价值？
开发者应带着经验参与实验，准备发现某些假设不再成立。他们需要质疑前提、识别模式、发现技术背后的组织问题，并帮助探索哪些实践仍然有效、哪些需要新方法。他们的判断力正是这种新工作方式所需要的。
为什么说“构建完成”不等于“生产可用”？
因为系统需要在生产环境中运行一段时间、经历多次变更，才能验证其可靠性。智能体生成的代码可能通过构建，但未必能应对生产中的故障和演化。正如Charity Majors所说，“ staging只是 glorified laptop，只有生产才是生产”。
