Netflix工程师Jake Nations演讲分享:
我得坦白一件事：我曾经发布过自己并不完全理解的代码。这些代码由AI生成，通过了测试，也成功部署了，但我却无法解释它的工作原理。Netflix的工程师Jake Nations在他的演讲中以这样一句坦诚的开场白，揭示了当下软件开发领域一个日益严峻的现实。他甚至断言："我敢打赌，在座的每一位都做过同样的事。"
这正是我们面临的核心矛盾：一方面，AI工具以前所未有的速度加速着软件开发，那些积压数年的重构项目如今得以完成；另一方面，它也催生了一个致命的新问题------我们对自己部署的代码，理解正在迅速减少。当系统在深夜发生故障时，我们还能像过去一样自信地进行调试吗？
这篇文章将为你提炼Jake Nations演讲中最具冲击力的观点，并探讨我们该如何在这场由AI驱动的变革中，重新夺回对代码和系统的主导权。
1. 我们掉进了"简单"与"容易"的陷阱
我们面临的第一个问题，源于对两个词的根本性混淆：我们把"简单"（simple）和"容易"（easy）搞混了，而AI工具恰恰利用了这种混淆。
Clojure语言的创造者Rich Hickey曾对这两个概念做出过精辟的区分：
- 简单（Simple） 意味着"一褶、一辫、无缠结"（one fold, one braid, and no entanglement）。它关乎事物的结构，指的是各个部分只做一件事，互不纠缠，从而使整个系统清晰、可被理解。
- 容易（Easy） 则意味着"邻近的、触手可及的、不费力的"（adjacent, within reach, without effort）。它关乎我们完成任务所需的精力，比如从Stack Overflow复制粘贴代码，或是安装一个"神奇"的框架。
简单需要思考、设计和解耦，而容易则唾手可及。AI正是那个"终极的容易按钮"。它让获取代码的路径变得如此 frictionless（无摩擦），以至于我们常常忽略了那条需要更多前期思考的"简单"之路。
每一次我们选择容易，都是在选择当下的速度，以及未来的复杂性。
这种取舍之所以变得危险，是因为AI彻底打破了过去的平衡。在过去，复杂性是在代码库中缓慢累积的，我们有时间去重构、反思和重建。而现在，AI让复杂性以指数级速度复合增长，系统在我们意识到之前，就已经变得难以管理。
2. AI是盲目的：它将你的技术债误认为是一种模式
AI工具的一个致命缺陷是：它缺乏辨别优劣的上下文。在AI眼里，你代码库中的所有代码都是需要保留和模仿的"模式"，它无法区分什么是精心设计的架构，什么是日积月累的技术债。
《人月神话》的作者Fred Brooks曾提出过两种复杂性：
- 本质复杂性（Essential Complexity）： 这是你试图解决的问题本身固有的难度。例如，"用户需要为商品付款"这个业务需求就是本质复杂性。
- 意外复杂性（Accidental Complexity）： 这是我们在开发过程中附加的复杂性，比如临时性的变通方案、过时的抽象层、防御性代码等等。
问题就在于，当AI分析你的代码库时，它会将这两种复杂性一视同仁。技术债在它看来不是"债"，只是更多需要被复制的代码模式。
Jake Nations分享了一个Netflix的真实案例。他们曾尝试使用AI来重构一个旧的授权系统。结果AI失败了。原因是，旧代码中的业务逻辑和授权逻辑已经紧密地交织在一起 ：权限检查被编织进业务流程，角色假设被固化在 数据模型中，授权调用散布在数百个文件中。当AI代理开始重构时，它根本无法理清这种纠缠，常常在处理了几个文件后就因为无法解开依赖关系而陷入死循环然后放弃。更糟糕的是，它有时会试图保留旧系统的逻辑，用新的系统重新实现旧的、糟糕的设计模式。
只有具备上下文和经验的人类工程师，才能分辨出哪些是必须保留的精华，哪些是历史遗留的糟粕。但这需要我们慢下来思考------而AI的速度恰恰在阻止我们这样做。
3. 真正的危险：我们正在丧失识别问题的直觉
比发布难以理解的代码更危险的，是我们作为开发者正在丧失识别复杂性的能力。
工程师那种"这个架构很危险"的直觉，并非与生俱来。这种模式识别能力，几乎完全是通过维护和调试失败的惨痛经历建立起来的。正如Nations所说："当我能发现一个危险的架构时，那是因为我就是那个凌晨三点处理它引发的故障的人。"
然而，当你不再理解自己的系统时，这种直觉就会萎缩。我们把思考外包给了AI，跳过了那些本可以磨练我们模式识别能力的关键过程。
AI只会生成你要求的东西。它不会编码从过去失败中吸取的教训。
长此以往，我们将培养出一代只能快速生成代码，却缺乏深度理解去维护、调试或安全地演进复杂系统的开发者。这才是AI带来的最大风险。
4. 解决方案：用"三阶段法"重新掌握主导权
面对这个困境，我们并非束手无策。Jake Nations提出了一套与AI协作的"三阶段法"。这不仅仅是一个工作流程，更是一种将人类的理解压缩成可快速评审的工件的纪律，旨在将战略思考牢牢掌握在人类手中，同时利用AI加速机械化的执行部分。
- 第一阶段：研究 (Research) 在这一阶段，我们不仅仅是把上下文信息------如架构图、设计文档------投喂给AI。这是一个反复探查 的过程。我们会追问AI（"缓存策略是怎样的？"），纠正 它的分析，补充它缺失的上下文。这个过程的最终产出，是一份浓缩的**"单一研究文档"**。它将数小时的探索压缩成几分钟的阅读，清晰地呈现了系统的现状、组件关系以及变更可能带来的影响。在这一阶段，设立一个"人类校验点"至关重要，由我们来验证AI的分析是否符合现实。
- 第二阶段：规划 (Planning) 基于经过验证的研究成果，由人类主导，创建一个极其详尽的实现计划。这份计划需要详尽到可以称之为**"按数字填色"（paint by numbers）的级别------即使是团队里最初级的工程师，也能精确地照着它完成工作。这一步的真正魔力在于评审速度**：一份详尽的计划可以在几分钟内得到验证，而评审数千行AI生成的代码则可能需要数小时甚至数天。
- 第三阶段：实施 (Implementation) 当有了一份清晰、明确、经过审查的计划后，最后一步才是让AI来执行。由于所有的思考和决策都已前置完成，我们可以将执行工作委托给一个**"后台代理"（background agent）**。开发者可以去处理其他任务，稍后再回来评审结果。评审过程也变得飞快，因为你只需验证代码是否符合计划，而无需从头理解任何新创造的逻辑。
这一方法有一个至关重要的前提：你必须首先通过手动实践来赢得理解（earn the understanding）。就像Netflix的授权系统重构一样，团队必须先手动完成一个模块的迁移，才能真正摸清所有隐藏的约束和依赖，并为AI提供一个干净的、可供学习的范例。这是有效利用AI进行重构的入场券，没有捷径可走。
5. 最后的思考：我们为何而写代码？
AI改变了我们编写代码的_方式_，但它没有改变软件工程失败的_原因_。每一代工程师都面临着自己的"软件危机"，而我们的解决方案，不应是另一个更强大的工具，而是回归到软件工程最核心的认知。
我们必须记住一个永恒的真理：软件是一项人类事业。正如演讲中所说："软件开发最难的部分，从来不是敲代码，而是知道该敲什么代码。"
在这场变革中，最终能够脱颖而出的开发者，不会是那些生成代码最多的人，而是那些真正理解自己正在构建什么的人。
Jake Nations最后留给我们的，是一个值得所有人深思的问题：
问题不在于我们是否会使用AI......问题在于，当AI编写我们大部分代码时，我们是否还能理解我们自己的系统。