AI编程时代的工程师困境：当没人再读代码

一封“受够了”的匿名吐槽

一位刚入职大公司半个月的工程师在网上发出这样的控诉：规格文档、代码、测试、PRD、工单、工单的解决方案、报告——所有一切都由 Claude Code 生成。团队里没人喜欢这种状态，却被逼着尽可能多地“出货”。

他描述的场景令人不安：管理层反复强调“推代码不是瓶颈，那我们为什么还慢”，于是工程师每天工作 12 到 13 个小时，只是为了“按下回车键”。从 L1 到 L7，每个人做的事情都一样——和 Claude 对话。没有人在读任何东西，没有人在解决 bug，甚至“没有人在思考了”。他形容这种体验“吸走灵魂”（soul-sucking）。

这段吐槽之所以引发共鸣，是因为它触到了当下软件行业的一根神经：当 AI 能生成一切，工程师的价值到底在哪里？知名主播 ThePrimeagen 在其视频中花了大量篇幅回应这个话题，他的观点值得每个从业者认真思考。

白板辩护：负责任使用 AI 的标准

ThePrimeagen 引用了 Mitchell Hashimoto（HashiCorp 联合创始人）提出的“白板辩护”（whiteboard defense）概念，并称之为负责任使用 AI 的基准线：

我应该能在任何时候把你拉到一边，让你解释你交付的任何面向客户的系统。你应该能清楚地说明它如何工作，并为你做出的决策辩护。

关键在于，Hashimoto 并不要求逐行熟悉代码，甚至不在意你是否知道具体调用了哪个函数。他关心的是更本质的问题：为什么用 X 而不是 Y？当有恶意行为者出现时会发生什么？这里用了什么数据结构、为什么？这个系统在哪里会失败？

这恰恰是那条吐槽的反面。它说明——理解你构建了什么、为什么这样构建，仍然有价值。如果你要为客户交付一个最终由你负责的产品，你至少应该慢下来，搞清楚引擎盖下的一些机械原理。ThePrimeagen 认为，能回答这些问题的人不仅能做出更好的产品，也更不容易陷入那种“全程 Claude、无人读代码”的灵魂被抽空的状态。

Mitchell Hashimoto 是基础设施即代码工具 Terraform 和 Vault 的背后公司 HashiCorp 的联合创始人，长期深度参与工程实践与工具链设计，因此他的观点在工程师圈子里有较高的权威性。"白板辩护"这一概念的精髓在于将"能否交付"与"是否理解"剥离开来——在 AI 时代，二者正在以前所未有的速度脱钩。传统上，交付某段代码与理解它几乎是同一件事，因为生产成本本身就逼着工程师去弄懂逻辑。而当生成成本趋近于零，工程师完全可能在毫不理解的情况下交付复杂系统，这使得"理解"这件事需要被显式地要求和评估，而不再是副产品。

这一切其实从未改变

ThePrimeagen 的核心论点或许出人意料：现在发生的事情，本质上并不新鲜。

他引用 Uncle Bob（Robert C. Martin）的话——“正在发生的事情一直都在发生。讽刺的是，什么都没变。管理层仍然在问为什么一切花了这么久。”

他回忆自己 2007 年的第一份专业工作：需要交付一个功能，同时要盘算“能砍多少个角、多快能上线”。从 2007 年到他在 Netflix 工作十年后于 2024 年离职，这场对话从未改变：我们要交付功能，砍哪些角？哪些可以等上线后再修？哪些现在必须处理？

变化的只是人们感觉离代码更远了。“为未来的代码库着想”的那种思考正在从人们脑中慢慢滑落。问题并没有因为 AI 而凭空出现，任何愿意花时间审查那种“薛定谔代码”的人都懂——代码运行得很好，一切正常，可你一打开看就被吓坏了：这玩意儿到底是怎么跑起来的？

学会说“不”，别做“Yes 工程师”

在 ThePrimeagen 看来，很多问题的解药是重新学会说“不”，不要做那种只会按需求“拉出”功能的“yes engineer”。

在 AI 出现之前，工程师有资本说“事情需要点时间”；而现在说“不”几乎是零成本的。任何优秀程序员都知道，如果你不设好护栏、不去思考、不问对问题、不真正参与开发过程、无法回答上述那些问题，最终产出的就是彻底的垃圾。在糟糕的代码库里工作毫无乐趣——无论这代码是机器人写的，还是你不得不重写的。

分裂的两个软件世界

ThePrimeagen 提出了一个“幕后理论”来解释为什么人们对 AI 编程的感受如此两极：我们生活在一个被割裂的世界里。

一边是庞大的群体，他们做的只是“一个网站连一台服务器、数据存远程数据库、用远程登录系统”。在这个世界里，把东西胡乱拼在一起就能神奇地跑起来，因为问题空间相当直白：有服务器、有客户端，从外部看这是个“已解决”的领域。这群人用 AI 时，会以为所有问题都被解决了。

另一边的人则要面对多台服务器、更复杂的交互。一旦进入这个世界，复杂度和疯狂程度会让你无法“撒手让 Dario（Anthropic CEO）替你开车、直接开向产品成功”。这种方法对除了最简单软件之外的一切都行不通——早晚要还债：你选错了几个抽象，撤销它们将是地狱般的体验。

ThePrimeagen 此处提到的 Dario 指 Dario Amodei，Anthropic 的联合创始人兼 CEO，Claude 正是 Anthropic 旗下的大语言模型产品。这句话用"让 Dario 替你开车"作为隐喻，暗指将所有决策完全委托给 AI 自动驾驶——在简单、线性的"直路"上也许可行，但一旦遭遇系统复杂度叠加、架构分叉等"弯道"，没有人类工程判断介入的自动驾驶就会失控。这个比喻也呼应了当下关于 AI 自主性（autonomy）与人类监督（human oversight）之间边界的广泛讨论：工具的能力边界，往往只有在出错之后才变得清晰。

最令人担忧的：初级工程师怎么成长？

如果说这套讨论里有什么真正让 ThePrimeagen 焦虑，那就是新人的成长问题。

他坦言：如果处在这样一个“一切都被替你写好”的环境里，他不确定自己当年能不能学出来。他需要那种困难的环境，才能真正被逼着去研究这些东西。

他引用 Clay（一个即时模式 GUI 库）作者的观点点破了这个“第 22 条军规”：资深工程师能解释系统，是因为他们曾亲手实现过；而初级工程师被期望去“生成”代码，而不是亲手写代码。问题是——一个人如果从没坐下来亲手搭建过系统，怎么可能真正理解什么才是好的系统架构？

“白板辩护”对已经积累了多年经验的人来说容易，对那些从未真正学习过、也不太会编程的人来说却几乎不可能。ThePrimeagen 说自己至今仍身体力行：打开文本编辑器，亲手写代码，亲手实现特定的库和重大架构决策，因为他需要“感受”它们、需要理解它们是否真的好。他甚至自嘲——也许只是自己脑子太笨，光读文档理解不了，必须坐下来动手写。

文中提到的 Clay 是由 Ryan Fleury 开发的一个即时模式（immediate mode）GUI 库。所谓即时模式 GUI，与 Qt、WinForms 等"保留模式"（retained mode）框架相对：保留模式框架在内存中维护一棵持久的 UI 组件树，由框架负责状态和重绘；即时模式则在每一帧重新从头描述整个 UI，状态全由调用者管理，框架不保留任何 UI 对象。即时模式因控制流清晰、易于调试而受到游戏界和工具开发者的青睐，但设计一套真正好用的即时模式 API 需要对渲染管线、内存布局和调用约定有深入理解。Ryan Fleury 本人正是以这种"亲手推导架构、不依赖既有框架"的风格著称，因此他对"必须亲手实现才能真正理解系统"的论断具有直接的示范意义。

结语：我们本该活在更好的时代

ThePrimeagen 最后的感慨发人深省：我们本应生活在一个能比五年前更快、更稳健地构建软件的时代，这是一个很酷的时间点。然而现实却是所有人都很痛苦。

工具的进步没有自动带来幸福，问题从来不在 AI 本身，而在于我们是否还保留着理解、思考和拒绝的能力。当交付速度成为唯一目标，当没人再读代码，被抽空的不只是工程师的灵魂，还有整个行业培养下一代的能力。