忘记“人在环中”，利用工程化驾驭让“人在环上”
内容提要
Thoughtworks工程师Kief Morris强调，AI生成代码时需重视“人在环上”的监督，而非完全放手。他建议通过CI/CD管道和工程最佳实践确保代码质量，避免认知债务，并用“harness engineering”定义“好代码”，让AI在安全框架内构建，同时保持对系统的控制，防止失去追踪能力。
延伸解读
从“人在环中”到“人在环上”
Kief Morris提出，随着AI生成代码的普及，开发者不应再逐行审查代码，而应转向“人在环上”的监督模式。这意味着通过CI/CD管道和工程实践来定义“好代码”，让AI在安全框架内自主构建，同时保持对系统的控制。这种转变要求团队重新思考如何确保代码质量，而不是依赖人工审查。
CI/CD管道作为AI的“缰绳”
Morris强调，CI/CD管道不仅是部署工具，更是约束AI行为的“缰绳”。当AI生成的代码出现问题时，不应直接修正，而应像处理生产环境缺陷一样，从源头修复并改进管道，防止同类问题再次发生。这种工程化方法能帮助团队在AI加速开发的同时，保持代码的可维护性和质量。
认知债务与“认知投降”风险
文章提到，过度依赖AI可能导致“认知债务”，即开发者对代码的理解逐渐减弱，最终可能“认知投降”——失去对系统的掌控。Morris建议通过“harness engineering”来构建引导AI的框架，包括架构决策记录和可操作性指标，从而在减少人工干预的同时，保持对代码的追踪和理解。
Q&A
Kief Morris认为在AI生成代码时，应该采用什么样的监督方式？
Kief Morris强调应该采用“人在环上”的监督方式，而不是完全放手或仅仅“人在环中”。这意味着通过CI/CD管道和工程最佳实践来确保代码质量，让AI在安全框架内构建，同时保持对系统的控制。
什么是“认知债务”？如何避免它？
认知债务是指由于过度依赖AI生成代码，导致开发者对代码细节失去理解，从而难以维护和修改。避免认知债务的方法是使用CI/CD管道和工程最佳实践，通过自动化测试和监控来确保代码质量，同时保持对系统的控制，防止失去追踪能力。
Kief Morris提到的“harness engineering”是什么？
Harness engineering是持续交付的下一层，指的是围绕代码构建一个“护栏”或“框架”，让AI在这个框架内构建软件。它允许你提示一个想法，AI构建，然后你围绕过程进行迭代。团队创建指南（如架构决策记录）来告诉代理如何构建，并通过可操作性指标确保代码库始终处于生产就绪状态。
在AI辅助开发中，如何定义“好代码”？
根据Kief Morris，定义“好代码”必须回到用户关心的事情上。LLMs不关心构建软件以持久，它们只想构建下一个功能，所以我们需要通过工程实践和用户反馈来定义“好”，确保代码不仅满足当前需求，而且可维护、可扩展。
为什么说CI/CD管道在AI开发中很重要？
CI/CD管道在AI开发中很重要，因为它提供了自动化的测试、集成和部署流程，确保AI生成的代码质量。当代理产生不符合预期的代码时，可以通过管道中的测试和检查来发现问题，并追溯到源头进行修复，防止类似错误再次发生。
Kief Morris建议如何避免AI代理失控？
Kief Morris建议通过建立“harness”来避免AI代理失控。这包括使用CI/CD管道作为操作护栏，设置领先指标（如测试覆盖率、代码质量）来监控代理的行为，并确保代理有清晰的“好”的标准。这样即使不直接查看代码，也能理解系统状态，防止代理跑在人类前面。
在AI生成代码时，为什么不能完全依赖LLM？
因为LLMs不关心构建软件以持久，它们只关注构建下一个功能，可能忽略长期维护、安全性和质量。因此，需要人类通过工程实践和护栏来确保代码符合用户需求，并具备生产就绪的质量。
