这是2020年。你是团队中资历最深的成员，负责代码质量和架构。你设立了良好的工程实践，认真审查来自经验不足的同事的PR（合并请求），并努力维护一个健康的代码库。然后，在某个时候，你去度假了。当你回来时，代码库一片混乱。每个人在合并彼此的PR时都没有真正关注，有人添加了一堆新的数据库表以进行反规范化，因为这样更方便，并且没有任何确凿的证据表明需要将无服务器计算或Kafka添加到技术栈中。这没关系。你可以修复这个问题。快进到2026年。你没有度假。只是一个普通的星期一早晨。你为自己做了一杯咖啡，打开电脑，发现有7个PR需要审查。你打开第一个：增加了24506行，减少了3938行，伴随着一些AI生成的描述，不知道它们该做什么。不知怎的，自上周五以来，你的团队的变更比你在外几周时所做的还多。人工智能去除了速度限制，人工智能使得工程文化薄弱的项目更快失败。曾经人们会坐下来讨论他们要如何做某事。现在他们可以在几个小时内向一个代理提出请求然后打开PR。这种工作方式最悲惨的方面在于，对于没有训练的眼睛来说，它似乎是有效的。如果你拉取这个分支并进行测试，你可能会得到某种功能正常的结果。那么，他们接下来会做什么？他们不断继续。一次又一次。直到项目到达一个没人知道任何事情是如何运作的状态。就像有人用信用卡买了一辆新豪华车。你看不到债务。你只看到看起来很棒的车。但随后用户开始报告奇怪的错误。这是你的团队试图修复的第四次。我是说……请AI来修复它。不幸的是，连Fable似乎都无法找到解决办法。你去找负责这个功能的人。“那么数据来自哪里？”“嗯……其实我不知道。让我问一下Claude。”你们两个坐在一起，看着屏幕上出现无尽的文本。你们都不知道其中的任何内容是否真实，但Claude似乎非常自信。“我们只需打开ultracode，问它进行双重检查？”这个会花一些时间。你开始谈论X上的最新戏剧。你终于得到了回复。“这对你有任何意义吗？”“我不确定。”“难道你上周不刚建立了这个吗？”沉默。这个项目变得如此复杂，层次和服务如此多，以至于你团队中的任何一个人都不可能理解发生了什么。那么，你该怎么办？修复它需要如此巨大的工作量，以至于连向管理层开始辩解都不可能。你甚至在考虑什么？反正几个月后它会再次进入完全相同的状态。“我们就请Claude来修复它吧。”“好的。我会创建一个循环和目标，这样在一切运作正常之前就不会停止。”“听起来不错”“其实，我今天的Fable使用已经用完了，所以我明天再运行。”你拿了一杯咖啡，走回电脑。现在你还有13个PR待审核。你看到了一些不太理解的东西，于是给写它的人发了信息。“我们为什么要在这里做这个？”他们给你发了一个链接。那是一个Claude的对话。在那段对话中，埋藏在Claude自信地推荐一种架构、道歉、改变主意、你的同事要求它重新考虑以及另外15轮的更改之间，显然就是这个代码背后的设计决策。“我该看哪一部分？”“可能全部。”这听起来熟悉吗？每当我谈论这个话题时，总有人告诉我，没有人能完全理解大型系统。这是对的。你从来没有被期望全面理解每一个服务和每个数据库。但至少有人知道并能解释给你听。现在他们在问LLM，因为他们自己其实也不知道。你再也负担不起糟糕的工程师了。在每个团队里，都有能让项目得以实施的有能力的人。也有一些人实际上使得其他人的工作变得更加艰难。而现在任何人都可以在一天内生成比以前一年更多的代码。在上述故事中，每个人都在失败：打开一个25000行PR的工程师本应该早早阻止代理代码生成。他们应该理解它在做什么，将工作分解成更小的部分，并质疑每一个新引入的抽象。审查它的人本应该拒绝审查这样庞大的内容，而不是屈服于审查。添加Kafka的人本应该能够准确解释为什么需要它。构建该功能的人本应该能够解释数据来自何处，而不是仅仅发送一个Claude对话的链接。但问题到底出在哪里？就用AI来修复它。好吧，这并不那么简单......在此之前没有人会对此提出反对。