6.0
关注
AI SCORE
观点评论2025-12-22 06:06
AI 时代的代码理解危机
DEV Community · GrahamTheDev#AI哲学#工程文化#代码质量
Editor brief · 编辑速览
深度思考在无限代码生成时代，人类代码理解能力的不可替代价值。
在 AI 时代，你组织中最危险的工程师不再是最慢的那个，而是最快的那个。
能够以难以置信的速度发布功能的工程师。
速度最高的团队。
每个冲刺都显示绿色的仪表板。
这些乍一看并不像听起来那么好。
在代码廉价且无限的世界里，速度不再能告诉你是否在取胜。它只能告诉你在积累某样你可能无法理解、修复或控制的东西时的速度有多快。
但我稍后再讲。
首先，让我们看看软件工程过去是什么样的，以及最近根本发生了什么变化。
50 多年来，这个房间里的每个人都因为掌握一种秘密语言而获得报酬。我们因为懂得"字典"而获得报酬。我们因为会说"机器语言"而获得报酬。
如果一个商业领袖想要一项功能——新的结账流程、搜索栏、数据管道——他们就有问题了。他们有想法，但没有语法。他们需要我们将他们的人类意图翻译成 Java、SQL、React。我们懂得如何与机器对话，而其他人则不然。
正因为这项技能稀缺，我们对这种翻译行为征收了"费用"。这个费用证明了我们的薪资、我们的时间表、我们的敏捷仪式和整个职业生涯的合理性。
但基础性的事情已经改变了。今天，机器说自己的语言。字典是公开的。翻译的税收正在迅速接近零。
我想说清楚：这并不意味着软件工程已经完成。但这意味着我们历史价值中最明显的部分——人们能看到和欣赏的部分，即将英文需求转化为语法的实际行为——已经商品化了。
如果编码不再稀缺，软件工程中的价值现在在哪里？这是我们今天必须回答的显而易见的问题。
我听到很多关于"被替代"的恐惧。但我们面临的不是替代危机。这是一场通胀危机。
想想基本经济学。当你印太多钱时，货币的价值就会下降。当你生成代码（我们现在可以以几乎无限的规模进行）时，写一行代码的价值也会下降。
我们正在从稀缺时代转向丰富时代。这导致了我现在看到公司犯的最大错误。
我称之为效率陷阱。
高管们看着这种丰富并想："太好了！如果 AI 让开发人员快 50%，我就可以解雇 50% 的人并获得相同的产出。"（对于质疑该陈述的人：那句话是由 ChatGPT 写的。它很自信、简洁，但完全错了。50% 的生产力提升意味着你要解雇三分之一的团队，而不是一半。它与这次讲演的其余部分完美地结合在一起，所以我保留了它。）
但抛开 AI 的过度自信不谈：这种思维根本上是错误的。高管看到了短期收益，但对长期复杂性视而不见。
丰富隐藏了风险。
每一行额外的代码、每个新的微服务、每个新的集成都可能以任何人都无法跟踪的速度悄悄积累复杂性。系统可能看起来很健康。仪表板可能显示绿色。但在下面，脆弱性在增长。
这就是直觉背叛我们的地方。我们看到产出的爆炸，认为需要更努力地衡量它。更密切地追踪它。更积极地优化它。
在 AI 时代，速度不再是领先指标。这是一个滞后指标。
但对速度指标的盲目崇拜最终会导致你的失败。
当你直接为速度优化时，你就会增加复杂性。当你为理解优化，真正了解你构建的东西以及它的行为方式时，系统会自然流畅，速度作为副产品而出现。
只关注输出的团队最终会陷入停滞，不是因为他们慢，而是因为他们害怕触及自己构建的东西。
如果你认为维护当前的遗留代码很困难，那就等着吧——当你必须维护你的团队即将生成的代码山峰时。
在任何系统中，价值总是转向制约因素。如果编写代码是廉价的、充足的、快速的……那么新的瓶颈是什么？
制约因素不再是编写软件，而是理解已编写的内容。
制约因素是要知道这个生成的代码块实际上做什么、它在哪里表现良好，以及更重要的是，它在哪里表现不良。
我们需要停止对速度的痴迷，开始关注 MTTU（理解的平均时间）。
DevOps 和 SRE 团队长期以来一直使用这个术语来衡量警报和诊断之间的差距；现在是我们其他人调整并将其应用于代码本身的时候了。
在开发人员的语境中，MTTU 是一个不是原作者的人有信心地回答以下两个问题所需的时间：
这个代码实际上做什么？
如果它坏了，我需要在哪里查找以修复它？
关键是：如果你为 MTTU 优化……如果你设计系统和团队来最大化理解……其他一切都会随之而来。速度、可靠性、可维护性，所有这些都会自然改进。
如果你忽视理解而只追求输出，系统最终会停滞。不是因为你慢，而是因为复杂性的增长速度超过了任何人的推理能力。
从现在开始，你做的每个架构决定要么压缩 MTTU，要么扩张它。
快速理解和验证你没有写的代码的能力——这是新的核心技能。这就是资深开发者在这个新时代拥有可转移技能的地方。
你多年的模式识别、你的心智模型、你辛苦获得的判断力实际上都会带来回报。
AI 可以生成无限的解决方案，但你是可以看到这些解决方案并理解它们对你的系统实际意义的人。
但考虑到这一点，让我们看看为什么这个指标和原则是如此重要。
第一个问题是反直觉的。问题不是 AI 不擅长编码。问题是它太擅长了。AI 好到足以看起来很称职。
AI 不是初级开发人员。AI 是一个无限的"赞成者"。它倾向于创造。
它总是会给你一些东西。
如果你要求 AI 解决一个问题，而正确的工程答案是"不要写代码，只需更改这个配置文件"，AI 很少会这样告诉你。它会为你写一个 500 行的脚本并绕过配置。
它构建你要求的，而不是你的意思。
它产生看起来正确的代码。它使用正确的库。它遵循正确的缩进。它甚至可能通过单元测试（当然是它为自己写的）。
如果你读过丹尼尔·卡尼曼的《思考，快与慢》，那么你就知道系统 1（快速、直觉）和系统 2（缓慢、深思熟虑）的思维，这种看似称职的代码的问题对你来说会很熟悉。
AI 生成的代码足够好，足以激活我们的系统 1 思维。我们扫一眼，它看起来像有效的代码，逻辑一目了然，我们点点头。"看起来很棒。"
但这就是陷阱。我们信任它的表面看似合理，所以我们关闭了我们的大脑。
我们停止了在脑子里模拟代码。我们接受解决方案而不退一步验证它是否符合我们特定系统的细微差别。我们从不进行缓慢而深思熟虑的思维。
而且因为我们太容易信任它，我们让它做我们永远不会让人类做的事情。这导致了第二个陷阱。
这是这种行为在现实世界中如何显现的：
想象一个团队要求一个简单的功能。比如说，一个提交用户名和电子邮件地址的网络表单。
在旧世界里，开发人员会叹气，写一个文件，希望有一点验证逻辑，然后发布它。
但现在呢？开发人员要求 AI"稳健地处理提交"。
AI 生成脚手架。它为验证生成一个单独的微服务。它为失败的提交添加一个重试队列（因为队列是"稳健的"）。它启动无服务器函数来清理输入。它添加分布式日志服务以保证完整性。
从技术上讲？一切都有效。从语法上讲？它是完美的。但这就是陷阱。
AI 是一个局部优化器。
它看着工单"使表单稳健"，然后以最大的力度解决那个特定的问题。它不关心你系统的其余部分。
你的职责就是这个。你是全局优化者。你是架构师。
你的职责是理解这个表单如何融入用户会话、计费系统和遗留数据库中。
但因为 AI 刚刚生成了五个新服务和三个队列，它制造了一个复杂性尖峰。要判断这个方案是否正确，你现在必须把所有这些新的复杂性加载到你的脑子里。你必须为五个服务而不只是一个文件绘制故障模式。
这是认知膨胀。这是危险所在。
当方案变得太复杂，你无法将其保存在工作记忆中时，你停止验证架构。你停止问"这是否适配？"转而开始接受"它能工作"。
你放弃了架构师的角色，因为蓝图变得太混乱，无法阅读。
这把我们带到了硬极限。极限不是我们能多快编写代码。极限是序列化带宽。
要成为架构师，要确保方案是安全的、合规的、正确的，你必须能够将逻辑序列化到你的脑子里。你必须能在你的脑海中"运行"这个系统。如果我在这里改变 X，它会在那边破坏 Y 吗？
我们现在有无限的生成带宽（AI）流入固定的序列化带宽（你的脑子）。
序列化带宽是你的脑子容纳系统的能力。无论 AI 打字有多快，如果你的脑子无法追踪逻辑，系统就是不安全的。
现在，房间里的 AI 崇拜者和乐观主义者（还有向你推销 AI 工具的供应商）会说："没关系！我们会给 AI 上下文。我们会喂它文档。我们会更好地提示它。"
这是我们这个行业现在最危险的谎言。你不能为你还不知道是否相关的上下文进行提示。
软件中的上下文不是你可以上传到向量存储的静态数据库。上下文是动态的。
你不知道"用户"对象与另一个项目中的"计费"对象有隐藏依赖关系，直到你看到代码尝试改变它的具体方式。你不知道这个特定的重试逻辑违反了一条新的合规规则，直到你看到队列被构建。
上下文是代码与现实之间的碰撞。
AI 只看到代码。你是唯一看到真实世界上下文的人。
如果你不能以快于代码创建的速度理解代码（而你做不到），你就失去了发现那些碰撞的能力。你失去了治理系统的能力。
瓶颈不是打字速度。瓶颈是架构验证速度。
然而，看看我们的 Jira 看板。我们仍然使用速率来衡量进度。每次迭代的功能数。关闭的工单数。发布的代码行数。那个不匹配是我们如何制造认知债务的。
在新世界中："好的速率"是在保持理解均值时间平稳的同时发布功能。"坏的速率"是通过峰值化理解均值时间来发布功能。
如果你用 AI 在四小时内发布一个功能，但一位资深工程师需要三天时间来理解下周它破坏时如何修复它，那么你的理解均值时间远高于你的代码速率。
如果你的理解均值时间太高，那么你处于认知债务中。
这个债务不只停留在代码中。它泄漏。
更长的事故（因为没人知道根本原因在哪）。
更慢的新人入职（因为新员工看不懂地图）。
功能瘫痪（因为每个人都害怕碰"魔法代码"）。
为了进一步说明这一点，让我问你一些事：
你们中有多少人在上个月合并了一个你没有完全理解的 PR？
如果你告诉自己稍后会回过头来正式审查，请举起手。
如果你真的这样做了，请继续举起手。
是的。我也没有那样做！
这就是为什么我们需要一个新的协议。
别担心。我不是在谈论瀑布式协议……以防你刚要走神！
到目前为止，我告诉你什么被破坏了和为什么。但我不想让你走出这里就感到焦虑。我想给你一个你明天就能使用的协议。所以让我具体一点。
我们必须改变协议。
我们需要转向 AI 和理解均值时间友好的规范驱动开发。
在这个新世界中，我们不是从读代码开始。我们从建立结构开始。
这发生在三个不同的层级：
这是你的生存工具。这是让你保持理智的东西。它严格来说是为你准备的。
它是"认知手柄"。在你生成一行代码之前，你在你的脑子里定义高级意图（或便签纸上）。
目标："添加用户存档功能"
约束："必须是可逆的"
架构适配："这应该属于用户服务还是管理服务？"
微规范是你的"BS 和不适配检测器"。
它允许你查看 AI 的输出并立即回答：这个代码是否适配我们系统的形状？这个代码是否看起来有我们要求的功能？
如果 AI 尝试为一个简单的 UI 更改重写数据库模式，微规范会告诉你立即拒绝它。
这是让每个人保持一致的东西。
一旦你知道了代码的形状，你就需要实质。
这是主规范。这是你和 AI 都依赖的文档。
对于 AI：它是说明手册。它包含验收标准、特定的边界情况、输入/输出定义。
对于你：它是技术验证的检查清单。
在 AI 生成代码后（你修复明显的错误），你从"架构师"切换到"审计员"。你将代码与主规范进行比较。
"它是否处理了我们要求的空值情况？""它是否实现了我们定义的特定重试逻辑？"。你在这里验证技术需求。
如果微规范检查代码的灵魂，主规范检查的是身体。
这是你的进化系统，这是让你随时间变快的东西。最后，我们有了力量倍增器。
当我们构建时，我们会注意到我们不断重复某些说明："使用 Tailwind。""不要使用 'any' 类型。""遵循仓库模式。"
我们不把这些放在每个规范中。我们将它们转移到全局上下文。
这是 CLAUDE.md 文件或 .cursorrules 文件这样的工具发挥作用的地方。
我们将这些文件视为我们的进化规则集。
每次 AI 犯了风格错误，我们不只是修复代码。我们更新全局上下文。我们添加一条规则。
随着时间的推移，这会自动把 AI 拉近到你的工程文化中。
当这个全局上下文成熟时，机器会成为你的模式专家。你会花费少得多的时间审查语法、导入和文件夹结构。
那么节省的时间去哪了？它去了唯一不能放入上下文文件的东西：现实世界的歧义。
无论 AI 对我们的代码库有多了解，它不知道我们的策略。它不知道营销团队刚改变了发布日期。它不知道用户讨厌那个特定的模态框。
你停止做代码审查员，开始做现实审查员。
微规范是灵魂，是代码的风味。主规范是身体，是代码的实质。全局上下文是潜意识，是代码的指导原则。
但即使有了这一切，你可能想知道一旦提示和上下文完善后，你在哪里仍然有价值？在接下来的 20 年里，有什么是人类能做的，AI 不太可能能做的？
一旦你接受了朝向编排和评估的角色转变，"提示"的论点就完全死去了。AI 无法替代你，因为 AI 无法越过这三条护城河：
AI 基于可见代码建议一个方案。你基于不可见的现实拒绝它。
示例：承重打字错误。
AI 扫描你的 API 并发现一个错误信息："Err (500)"。它建议一个"最佳实践"改进："让我们让它更接近常见术语：Internal Server Error (500)"。
这更好的 DX，更具描述性，更符合行业术语。
但你知道世界的上下文。你知道运维团队有一个遗留监控脚本，该脚本 grep 日志中具体是"Err (500)"字符串。如果它看到那个字符串，它会自动重启服务器。
如果你让 AI"修复"那条信息，grep 失败。自动重启失败。下次服务器挂起时，它会一直处于宕机状态（直到你收到电话去修复它……AI 不会现在收到电话，不是吗？）。
AI 看到的是文本。你看到的是真实的世界依赖关系。你不能为你不知道存在的服务器上运行的 bash 脚本进行提示，直到它变得相关。
AI 精确回答提示。你回答隐含的需要。
业务要求"快速搜索"。
AI 为了实时响应而启动 Elasticsearch，成本高达数千美元。
你知道"快速"仅意味着"一秒以下"，而一个简单的 SQL 查询是免费的。
使用 AI，你并不是做更少的工程工作，而是在做更高阶的工程工作。
AI 是局部修复的高手。如果你给它展示一个错误，它会让那个错误消失。它会编写防御性代码。它会捕获异常。但它对系统级副作用是盲目的。
它通过添加重试循环来修复数据库超时。
它不知道上面三层，前端也在重试，负载均衡器也在重试。它在本地修复了错误，但却创造了一场重试风暴，这将在下次流量峰值期间击垮整个平台。
AI 查看文件。你查看爆炸半径。你的工作是问："如果这段代码完美地工作，它还会破坏什么？"
但这种高阶工程工作不是你在训练营中学到的，那么初级开发者在这个新世界中如何适应呢？
如果你一直在关注，并且你职业生涯早期感到担忧...很好。这意味着你在认真关注。但你需要理解的是：AI 并不会让你过时。
它让你变得危险。资深开发者受到他们心智模型的限制。他们知道什么"应该"工作，所以他们会要求 AI 构建显而易见的东西。
你还没有那些先入之见。
你可以在一个下午内让 AI 尝试五种不同的架构，没有认知负担。你在探索方面更快，因为你需要学习的更少。
这引出了管理层和招聘经理可能仍在问的一个问题：为什么还要招聘初级开发者呢？如果 AI 表现得像一名中级开发者，为什么要付钱让人去学习？
因为 AI 是引擎，不是司机。
如今初级开发者的价值不是"代码生产"。而是选项生成和验证。
在旧时代，如果我们不确定如何构建某个功能，我们会派一名资深开发者花三天时间制作原型。这很昂贵。
现在，我们派一名初级开发者。我们说："这是规范。用 AI 原型化三种不同的解决方案。比较权衡。测试边界情况。给我最好的那个。"
初级开发者提供了立竿见影的投资回报，因为他们充当了资深开发者的力量倍增器。
他们穿过 AI 的幻觉。他们验证库。他们过滤噪声。他们向资深开发者呈现的不是空白文本文件，而是精心策划的选项。
（比喻）：初级开发者探索 AI 的丛林，映射机器可能采取的路径，为资深开发者带回安全的道路。他们今天很有价值，因为他们做了探索的基础工作，让资深开发者能够做出高杠杆的选择决策。在做这项工作中，他们学会了成为资深开发者所需的判断力。
房间里的资深开发者呢？你们是编排者。你定义约束。你决定复杂性在哪里被允许，在哪里被禁止。
你审计代码与代码库其他部分接触的接缝。
你确保当 AI 写个别音符时，旋律保持一致。
（比喻）：每条 AI 生成的行是一个乐器；只有资深开发者能确保它演奏正确的旋律。你是唯一能看到整个交响曲的人。
我想通过解决房间里的大象来结束。
我们已经确立 AI 提供无限的生成带宽。
我们已经确立人类有固定的理解带宽。
只有一种方式来解决这个方程。不是读得更快。
不是只是"雇更多人"。生存的唯一方式是成为伟大的过滤器。
在一个添加代码是免费的时代，你能做的最昂贵的事情就是接受它。
最高价值的工程活动不再是创建软件。而是拒绝软件。
如果你不能对代码说"不"，你在这个新的智能时代就不再是工程师了。你是一个拿工资的部署管道。
你的价值在于看一个来自 AI 的"工作"解决方案并说："不。这会激增我们的理解平均时间。删除它。简化它。重新做一次。"
我们需要减慢摄入速度以匹配我们消化的速度。
我们需要是那些说的人："仅仅因为我们能在 30 秒内生成一个微服务，并不意味着我们应该这样做。"
你的工作是站在闸门前，控制流量，安全地引导它，谨慎和精确地发布。
在一个代码像河流一样流动的世界中，你的责任很清楚：阻止代码的海啸。不要让复杂性和认知债务吞没和压倒你的系统。
不仅仅是构建软件。成为软件仍然可以理解的唯一原因。
你是伟大的过滤器：AI 可能能够无限生成，只有你可以决定什么生存。
如今，你的职业生涯不再由你发布多少来定义。而是由你拒绝发布多少复杂性来定义。
保护你的团队的理解平均时间。
如我所说，这个演讲需要一些编辑和润色，但我希望这个主题和概念能引发思考。我希望这个信息是清楚的。
我们的角色正在演变，但不是说你所有技能都过时了。只是你可能需要花更少的时间在 leet code 上，花更多的时间在架构上，以及在审查代码时变得更好和更勤奋。
你应该在提交代码（或由 AI 生成的代码）时优化理解平均时间。
让我知道你是否认为这会成为一个有趣的演讲，还是你会在后面一边刷 X 一边心不在焉？
某些评论可能只对已登录的访问者可见。登录以查看所有评论。
如需采取进一步行动，你可以考虑封禁此人和/或报告滥用