【Gemini翻译】 《认知债：当速度超越理解》
这位工程师在一个迭代（Sprint）中交付了七个功能。DORA 指标看起来完美无瑕。晋升报告简直是信手拈来。
六个月后，一项架构变更需要修改这些功能。团队中没有人能解释为什么某些组件存在，或者它们是如何交互的。开发它们的工程师盯着自己的代码，就像盯着陌生人的代码一样。
代码的生产成本已经变得比理解成本更低。
【理解滞后】
当工程师手动编写代码时，会同时发生两个并行过程。第一个是生产：字符出现在文件中，测试被编写，系统发生变化。第二个是吸收：心理模型形成，边缘案例变得直观，架构关系固化为理解。这些过程是耦合的。打字的动作迫使大脑参与。实现的摩擦为推理创造了空间。
AI 辅助开发解耦了这些过程。一个提示词（Prompt）在几秒钟内生成数百行代码。工程师进行审查、调整、迭代。产出加速了。但吸收无法成比例地加速。真正理解构建了什么、为什么要这样构建以及它与其它所有事物的关系的认知工作，仍然受限于人类的处理速度。
这种产出速度与理解速度之间的差距就是认知债。
与通过系统故障或维护成本表现出来的技术债不同，认知债对速度指标是不可见的。代码运行正常。测试通过。功能交付。赤字仅存在于构建系统的工程师脑海中，表现为对自己工作的某种不确定性。
债务并非真正不可见。它最终会出现在可靠性指标中：平均恢复时间（MTTR）拉长，变更失败率（CFR）攀升。但这些是滞后指标，与驱动季度决策的速度指标相比，存在数月的滞后。当 MTTR 发出问题信号时，理解赤字已经复利增长了。
【组织实际衡量的是什么】
工程绩效体系演变为衡量可观察的产出。完成的故事点。交付的功能。合并的提交。审查周转时间。这些指标出现在产出与理解紧密耦合的时代，那时交付某样东西意味着理解某样东西。
指标从未直接衡量理解，因为理解是被默认假设的。交付功能的工程师被假定理解该功能。这一假设之所以成立，是因为生产过程本身迫使了理解的产生。
该假设不再成立。工程师现在可以在仅维持对实现表面熟悉的情况下交付功能。功能可以运行。指标记录了成功。传统上随这些功能一起积累的组织知识，根本没有以同样的速度形成。
绩效校准委员会看到了速度的提升。他们看不到理解的赤字。他们看不到，是因为组织衡量系统的任何产物都没有捕捉到这个维度。
【审查者的困境】
关于认知债的讨论通常集中在生成代码的工程师身上。更尖锐的问题在于审查代码的工程师。
代码审查演变为一种质量门。资深工程师检查初级工程师的工作，捕捉错误，提出改进建议，转移知识。限速因素始终是初级工程师的产出速度。资深工程师审查的速度快于初级工程师生产的速度。