一位初级工程师最近交付了一个已经投入生产环境的功能，各项测试通过，指标显示正常，本应是一次值得庆贺的成功交付。然而，他却显得疲惫而茫然。
他坦言：“我无法解释这段代码是如何工作的。”这并非他没有尝试，也并非能力不足。在会议前，他曾盯着这个函数二十分钟，试图追踪逻辑，重建产生这段代码的推理过程。代码编译通过，测试也通过了。但当他试图逐行理解时，那种深入的理解却不见了。代码的逻辑感觉像是借来的，陌生而疏远，就像阅读别人的笔迹，却发现认不出自己的名字。
这段代码是他写的。但他又不是他写的。
摩擦消失了
他描述了事情的经过：他遇到了一个他并不完全理解的问题，于是向AI助手进行了描述。AI生成了看似合理的代码，编译通过，测试也通过了。他便将其部署上线。整个过程花费的时间，仅仅是他自己与问题搏斗、陷入困境、解决困境并真正理解自己所构建内容所需时间的一小部分。
曾经迫使开发者深入理解的“摩擦力”消失了。
我曾听到一个观点，令我印象深刻：“能力较弱的开发者加上AI，结果就是更弱的产出……而且速度更快。”那些感受最深切的初级工程师之所以挣扎，并非因为AI太难，而是因为AI让他们太容易跳过那些本应能建立判断力的工作。
曾经迫使开发者深入理解的摩擦力消失了。
当速度取胜时，我们失去了什么？
这并非一个工程师糟糕一周的个例。一旦我开始留意，这种模式便随处可见。代码合并请求（PRs）变得越来越大，代码审查意见越来越少。工作背后的能量正在发生转变，而这种转变并非导向更好的工程实践。
我看到一个由500多名经验丰富的工程师组成的讨论串，他们描述了AI工具在缺乏深思熟虑的防护措施下推广后的情况。这些故事惊人地一致：AI生成了远超人类合理审查能力的代码，导致PRs膨胀。代码库充斥着不一致的模式，每个工程师通过不同的提示词为相同的问题生成了略有差异的解决方案。服务边界变得模糊，错误处理成了修修补补的大杂烩。代码库开始感觉不再像一个有意的系统，更像一个带有CI/CD流水线的“杂物抽屉”。
一位工程师用一句话描述了这种现象，让我久久不能忘怀。最初的迹象并非团队错过交付日期，也并非质量一夜之间崩溃。它发生得更早、更悄无声息。首先是参与度（Engagement）下降了，人们开始退缩。然后，工作的质量也随之……