作者从一个历史观察切入：每次技术浪潮都在许诺"更简单、更快、更好"，但事后看，它们做的不是消除复杂性，而是把复杂性搬到了别处。

汇编到高级语言，消除了内存管理的麻烦，但把复杂性搬到了编译器和抽象层上。微服务号称解耦单体，却把复杂性搬到了通信协议、部署管线、可观测性和组织设计上。上云不需要管机房了，但需要管成本、管权限、管跨区域延迟。

AI 编程工具也遵循同样的规律。它降低了"写代码"的复杂度，但复杂度并不是消失了，它转移到了别的地方：代码审查、一致性检查、架构决策。代码生成成本越低，这些地方的复杂度反而越高。因为代码产出速度加快后，一次有问题的架构假设会在更短时间内被扩散到更多模块里。以前你一天手写 100 行，错误也只会出现在这 100 行里；现在 AI 帮你一天生成 1000 行，同一个错误就污染了 1000 行。错误的传播速度和代码产出速度同步放大了。

作者特意追溯了 architecture 这个词的词源：希腊语 arkhitekton （总建筑师），指的不是搬砖砌墙的人，而是决定建筑物各部分怎么连接起来的人。在 AI 时代，这个区分的分量更重了。

文章最有价值的部分是一组研究数据。这些数据共同指向一个结论： AI 提效 这个说法太笼统了，实际情况复杂得多。

一项对照实验发现，有经验的开发者使用 AI 工具后比不用 AI 的对照组慢 19%。多花的时间主要在三件事上：写提示词让 AI 理解意图，审查 AI 生成的代码是否正确，修正 AI 引入的错误。换句话说，体验上感觉快了（因为代码出来得快），但端到端的交付时间反而更长了。

真正要命的是长期成本。有研究分析了大规模代码库后发现，AI 生成的代码容易被反复修改和重写（代码流失率更高），重复代码更多，技术债务积累更快。另外有论文指出，AI 生成代码的缺陷模式和人工代码不同，包含了更多安全风险和结构性问题。

还有一个学者们注意到的现象：AI 辅助开发实际是在重新分配工作量，不是在消除工作量。资深工程师的生产率下降了。下降的原因是他们的时间从"创造新价值"被挤到了"审查和修正 AI 代码"上，审查负担增加直接吃掉了写代码的时间。

MIT 的一项研究还指出了一个容易被忽略的问题：过度依赖 AI，深度思考和分析问题的时间就变少了。工具越快，人越懒得自己动脑。

这些数据放在一起看，指向一个朴素的结论：AI 优化的是生成代码这个动作，但软件工程的核心不是生成代码，是长期维护一个系统。这两件事不完全重合，甚至会互相冲突。

总结历史和数据，作者梳理了工程师角色的变化方向："写代码"这项技能的重要性在下降，"确保对的代码存在"这项技能在上升。

具体来说，工程师正在变成三个角色：

1. 审阅者 ：自己写得少了，主要工作是判断 AI 写出来的东西对不对、跟系统整体设计冲不冲突。
2. 代码库维护者 ：AI 可以快速生成大量代码，但这些代码不会自动保持整洁。需要有人持续清理 AI 引入的技术债务，保证各模块写法一致、风格统一，避免代码库变成各种风格混在一起的垃圾场。
3. 守护者 ：守住架构边界。AI 不理解你的系统，它只解决当前对话框里的局部问题。谁来保证局部改动不破坏全局结构？只有人。

作者引用了 John Ousterhout《A Philosophy of Software Design》里的一个观点：软件工程的核心难题从来不是生产代码，是管理复杂性。AI 时代这句话的分量更重了。

作为 Claude Code 的重度用户，我对这篇文章的体感很复杂。用 AI 写代码确实快，以前要查文档、试参数、反复调试的活，现在几句话就出来了。但作者说的"感觉快不等于真的快"确实值得警惕。当 AI 刷刷刷输出代码的时候，我有没有每次都停下来想：这个方案跟现有模块的接口一致吗？有没有引入隐藏的耦合？这些检查一旦省略，当下是快了，后面排查 bug 的时间会加倍要回来。

作者给的答案是：该用就用，但始终把自己定位为 负责决策的人 。AI 处理机械性工作，你负责结构、正确性和长期可持续性。这个定位一旦模糊了，AI 就从助手变成了技术债务制造机。