生成式和智能体 AI 如何将关注点从技术债务转向认知债务

术语 技术负债 通常用于描述设计或实现选择的积累，这些选择使软件在以后更难和更昂贵地理解、修改或扩展。技术负债很好地捕捉到了“人类理解”的重要性，但“技术负债”这个词语却让人联想到负债是代码的属性，需要花费精力从代码中消除这种负债。

认知负债，一个近期获得关注的术语，传达了这样一个观念：快速开发带来的负债是存在于开发人员的大脑中，并影响了他们的体验和能力，使他们难以“快速”开发或修改代码。即使AI代理生成的代码易于理解，人类开发人员也可能已经失去了对程序的理解，无法知道程序应该做什么、如何实现他们的意图，或者如何修改它。

认知负债可能比技术负债更大，因为AI和代理的采用变得更加普遍。Peter Naur几十年前提醒我们，程序不仅仅是其源代码，而是一种存在于开发人员脑海中的理论，描述了程序的功能、开发人员的意图如何实现以及程序如何随时间变化。通常，这种理论不仅仅存在于一个开发人员的脑海中，而是分散在许多甚至成千上万的其他开发人员的脑海中。

我在最近的一门创业课程中亲眼目睹了这种动态。学生团队在整个学期内构建软件产品，快速发布功能并达到里程碑。但是在第7或8周，一个团队遇到了瓶颈。他们无法再做出甚至是简单的修改，而不会意外地破坏某些东西。当我与他们见面时，团队最初指责技术负债：混乱的代码、糟糕的架构、仓促的实现。但是，当我们深入探讨时，真正的问题出现了：团队中没有人能够解释为什么做出某些设计决策或系统的不同部分如何协同工作。代码可能很混乱，但更大的问题是系统的理论、他们的共享理解已经碎片化或完全消失。他们积累了认知负债，速度比技术负债快，这使他们陷入瘫痪。

这种动态回荡着弗雷德·布鲁克斯的《神话人月》中的经典教训：向项目添加更多代理可能会增加协调开销、不可见的决策和认知负担。当然，代理也可以用于管理认知负担，总结更改的内容和方式，但人类记忆和工作能力的核心约束将随着速度的推动而被拉伸。减慢速度并进行肯特·贝克所说的“使困难的修改变得容易”的工作，这将导致未来认知负债和负担。

在最近的软件工程未来研讨会（由马丁·福勒和Thoughtworks组织）的分组讨论中，我们讨论了开发人员需要减慢速度并使用成对编程、重构和测试驱动开发等实践来解决技术负债和认知负债。通过减慢速度并遵循这些实践，认知负债也可以减少，开发人员和团队之间的共享理解可以重建。

但是随着AI和代理变得更加普遍，团队可以采取什么具体措施？

首先，他们可能需要认识到没有理解的速度是不可持续的。团队应该建立认知负债缓解策略。例如，他们可能希望要求至少有一名人类团队成员完全理解每个AI生成的更改，然后再发布，记录不仅仅是什么更改了，还有为什么，并创建定期检查点，在那里团队通过代码审查、回顾或知识共享会议重建共享理解。

其次，我们需要更好的方法来检测认知负债，在它变得令人窒息之前。警告信号包括：

• 团队成员因为害怕意外后果而犹豫修改代码
• 对“部落知识”（仅由一两个人掌握）的依赖增加
• 系统变得像黑盒一样的感觉越来越强

这些可能是共享理论正在侵蚀的信号。

最后，这种现象需要严肃的研究关注。我们如何衡量认知负债？在AI增强的开发环境中，什么实践最能有效地防止或减少认知负债？认知负债如何在分布式团队或开源项目中扩展，在那里“理论”必须由新人重建？当生成和代理AI重塑软件的构建方式时，理解和管理认知负债可能是我们领域面临的最重要的挑战之一。

我将在ICSE 技术负债会议和小组讨论中进一步探讨这些问题。认知负债往往不会通过构建失败或部署后出现的微妙错误来宣布自己，而是通过共享理论的沉默丧失来表现。随着生成和代理AI加速开发，保护软件的共享理论——它的功能和如何修改——可能比任何单一的速度或输出指标更重要，才能保证软件的长期健康。