本文翻译自 Cognitive Debt: When Velocity Exceeds Comprehension，原载于 Hacker News。
工程师在一个冲刺中交付了七个功能。DORA 指标看起来完美无缺。晋升材料几乎自己就写好了。
六个月后，一次架构变更需要修改这些功能。团队里没有人能解释为什么某些组件存在，或者它们是如何交互的。构建这些功能的工程师看着自己写的代码，却像看着陌生人的作品一样。
代码的生产成本已经低于理解成本。
理解的滞后
当工程师手动编写代码时，两个并行的过程同时发生。第一个是生产：字符出现在文件中，测试被编写，系统发生变化。第二个是吸收：心智模型形成，边界情况变得直观，架构关系固化为理解。这两个过程是耦合的。打字的行为强制参与。实现的摩擦为推理创造了空间。
AI 辅助开发解耦了这两个过程。一个提示词在几秒钟内生成数百行代码。工程师审查、调整、迭代。产出加速了。但吸收无法按比例加速。真正理解构建了什么、为什么那样构建、以及它与其他一切如何关联的认知工作，仍然受到人类处理速度的限制。
这种产出速度与理解速度之间的差距，就是认知债务。
与技术债务不同——技术债务通过系统故障或维护成本显现——认知债务对速度指标是不可见的。代码工作正常。测试通过。功能交付。缺陷只存在于构建系统的工程师的脑海中，表现为对自己工作的不确定。
这种债务并非真正不可见。它最终会出现在可靠性指标中：平均恢复时间（MTTR）变得更长，变更失败率逐渐上升。但这些都是滞后指标，与驱动季度决策的速度指标相隔数月。当 MTTR 发出问题信号时，理解赤字已经复利增长了。
组织实际测量的是什么
工程绩效系统演变用来测量可观察的产出。完成的 Story points。交付的功能。合并的提交。审查周转时间。这些指标诞生于一个产出和理解紧密耦合的时代，那时交付某些东西意味着理解某些东西。
这些指标从未直接测量理解，因为理解是被假定的。一个交付功能的工程师被认定理解那个功能。这个假设成立是因为生产过程本身强制理解。
那个假设不再成立。 工程师现在可以在只对其实现保持表面熟悉的情况下交付功能。功能工作正常。指标登记成功。传统上与这些功能一起积累的组织知识根本没有以同样的速度形成。
绩效校准委员会看到速度提升。他们看不到理解赤字。他们无法看到，因为组织测量系统的任何产物都不捕获那个维度。
审查者的困境
关于认知债务的讨论通常集中在生成代码的工程师身上。更尖锐的问题在于审查代码的工程师。
代码审查演变为一个质量关卡。高级工程师检查初级工程师的工作，发现错误，建议改进，传递知识。限制因素始终是初级工程师的产出速度。高级工程师的审查速度可以比初级工程师的生产速度快。
AI 辅助开发反转了这个关系。初级工程师现在生成代码的速度可以快于高级工程师深度审查的速度。 生成的代码量超过了可用于深度审查的带宽。必须有取舍，通常是审查深度。
审查者面临一个不可能的选择。保持以前的审查标准，成为否定 AI 提供速度增益的瓶颈。或者以代码到达的速度批准它，并希望测试能捕获审查遗漏的问题。大多数人选择后者，通常是无意识的，因为组织压力偏向吞吐量。
这是认知债务复利增长最快的地方。作者的认知赤字可能通过对代码的后续参与来恢复。审查者的认知赤字会传播：他们批准了他们不完全理解的代码，这些代码现在带有隐含的认可。审查过的代码就是被理解的代码这个组织假设不再成立。
职业倦怠模式
大量使用 AI 工具的工程师报告了一种不同于传统职业倦怠的特定疲惫形式。传统倦怠源于持续的认知负荷，源于在解决复杂问题时需要同时考虑太多事情。新模式源于某种更接近认知断连的东西。
工作快速进行。进度可见。但工程师体验到一种持续的、不能完全掌握自己产出的感觉。他们可以执行，但解释需要重建。他们可以修改，但预测变得不可靠。他们构建的系统即使功能正确，也感觉有点陌生。
这创造了一种独特的心理状态：高产出伴随低信心。工程师生产更多，但对他们生产的东西感觉更不确定。在基于可见产出进行排名的组织中，这造成了继续生成 despite 日益增长的不确定性的压力。
停下来深入理解自己构建内容的工程师在速度指标上落后。优先考虑吞吐量而非理解的工程师达到他们的季度目标。激励结构选择了加速认知债务积累的行为。
当组织记忆失效时
工程组织中的知识以两种形式存在。第一种是显性的：文档、设计文档、记录的决策。第二种是隐性的：在构建和维护系统的人们的脑海中持有的理解。隐性知识无法完全外化，因为它的大部分以直觉、模式识别和情境判断的形式存在，这些是通过直接参与工作形成的。
当构建系统的人离开或轮换到新项目时，隐性知识随之离开。传统上，组织通过正常的工程工作过程补充这些知识。在现有系统上构建的新工程师通过实现的摩擦发展出自己的隐性理解。
AI 辅助开发可能使这种补充机制短路。如果新工程师可以在不发展深度理解的情况下生成可工作的修改，他们就永远不会形成传统上会积累的隐性知识。组织不仅通过人员流失失去知识，还通过知识形成不足而失去。
这创造了一种延迟的失效模式。系统继续运行。新功能继续交付。但真正理解系统的人员储备逐渐枯竭。当情况最终需要这种理解时，当某些东西以意想不到的方式崩溃，或者需求以需要架构推理的方式变化时，组织发现赤字。
债务如何复利
随着认知债务积累，三种失效模式出现。
第一种涉及一个通常可靠的经验法则的反转。工程师通常信任已经在生产环境中运行多年的代码。如果它存活了那么久，它可能是有效的。代码存在时间越长而不引起问题，它赢得的信心就越多。AI 生成的代码反转了这个模式。它保持不变的时间越长，就越危险，因为周围人类的上下文窗口已经完全关闭。在编写时几乎不被理解的代码，在编写它的人离开后变得完全不透明。
他们正在调试一个由黑盒编写的黑盒。
第二种失效模式在事故期间浮出水面。凌晨 3 点警报响起。值班工程师打开一个他们没有构建的系统，由他们没有监督的工具生成，以假定他们不具备的熟悉程度进行文档记录。他们正在调试一个由黑盒编写的黑盒。 当有人理解系统时，本该是十分钟的修复变成了没有人理解时的四小时取证调查。在足够多的事故中乘以这种情况，总成本超过了 AI 辅助开发提供的任何速度增益。
组织实际上正在用其未来的 Staff 工程师管道换取本季度的功能交付。
第三种失效模式在更长的时间尺度上运作。主要依赖 AI 辅助开发的初级工程师永远不会发展出手动实现所带来的直觉。他们交付功能，但没有形成指导架构判断的经验积累。组织实际上正在用其未来的 Staff 工程师管道换取本季度的功能交付。成本不会出现在当前的人头模型中，因为五年后本应成为高级架构师的人还没有缺席。他们只是从未形成。
总监的视角
从工程领导层的角度来看，AI 辅助开发呈现为生产力提升。团队交付更快。路线图压缩。人头讨论变得更有利。这些是通过组织报告结构向上传播的可观察信号。
在这些团队中积累的认知债务不会呈现为信号。没有”不用重新阅读就能解释自己代码的工程师”的指标。没有”组织理解深度”的仪表板。这个概念不适合季度业务审查格式或人头论证叙事。
总监基于可观察的信号做出决策。当这些信号一致表明成功时，加倍投入产生这些信号的方法在领导层可获得的信息环境中是理性的。给定数据，决策不是错误的。数据是不完整的。
这个模型的局限
认知债务框架并不均匀地适用于所有工程工作。有些任务确实是机械的。有些代码库确实受益于没有深度架构理解的快速迭代。有些功能确实不需要传统上通过手动实现形成的理解程度。
该模型还假设理解以前以足够的速度形成。这个假设可能过于宽厚。工程师对自己工作的理解深度一直有差异。分布可能只是在转移，而不是一种新现象的出现。
此外，工具和文档实践可能会演变，部分弥合理解差距。如果组织开发出捕获和传递 AI 辅助开发无法有机形成的理解的方法，债务可能是可管理的而非积累性的。
测量问题
系统正在正确地优化它测量的东西。它测量的东西不再捕获重要的东西。
根本性的挑战是 组织无法优化它们无法测量的东西。速度是可测量的。理解不是，或者至少不是通过任何当前输入绩效评估、晋升决策或人头规划的机制。
直到理解对组织决策系统变得可见，激励结构将继续偏向速度。优先理解而非产出的工程师将显得比优先产出而非理解的同行生产力更低。绩效校准将奖励更快积累债务的行为。
这不是个别经理或工程师的失败。这是一个为生产与理解耦合的时代设计的测量系统，在一个这种耦合不再成立的时代运行。系统正在正确地优化它测量的东西。它测量的东西不再捕获重要的东西。
差距最终会显现。无论是通过超出预测的维护成本，通过需要没有人拥有的理解的事故，还是通过暴露没有深度理解构建的系统脆弱性的新需求。显现的时机和形式仍不确定。潜在的动态则不是。
核心要点
-
认知债务是真实存在的：AI 辅助开发创造了产出速度与理解深度之间的鸿沟。代码能工作，但编写它的人可能并不真正理解它。
-
现有指标体系存在盲区：DORA 指标、Story points、功能交付数都测量的是产出，而非理解。组织看到的”效率提升”可能是假象。
-
审查者的负担更重：初级工程师可以用 AI 快速生成代码，但高级工程师无法以同样的速度深度审查。这导致代码审查流于形式。
-
隐性知识的流失：传统上，工程师通过”摩擦”积累经验。AI 消除了这种摩擦，也消除了学习机会。
-
长期代价尚未显现：今天的”效率提升”可能正在透支未来。当需要修改那些没人真正理解的代码时，代价会成倍增加。
-
没有简单的解决方案：只要组织激励速度而非理解，这个问题就会持续。需要新的指标和新的思维方式。
给我的启示：作为开发者，我需要在使用 AI 工具的同时，有意识地强迫自己深入理解生成的代码。不是为了”学习”而学习，而是因为当系统出问题时，只有真正理解的人才能快速定位和修复。AI 可以帮我写得更快，但不能帮我理解得更深。