2026：代码苦力“末日”！谷歌开源力挺AI编程，初级程序员慌了？

“程序员世界的旧职级体系彻底崩塌了！”

“代码苦力死了，我为26届的计算机学生感到担忧。”

2026伊始，AI 对于开发者的冲击，再度成为热议话题。

比如知名开源大佬、Ruby on Rails 之父 DHH（没错，就是那个两年前高调宣布告别K8s，去年夏天还在给大模型编程祛魅的技术狂人），几个小时前，也开始表示：2026，要乐观地拥抱AI了。

再比如昨天，ClaudeCode创建者Boris转发了谷歌的首席工程师Jaana Dogan（负责Gemini API）的一则帖子。帖子中，Jaana称：这不是开玩笑，ClaudeCode 一小时完成了自己团队过去一年构建的内容。

这意味着什么？强如谷歌、开源大佬，也开始公开认可AI在编程界的威力了。

再比如，今天小编在Reddit上刷到一篇高赞热议文章：《初级软件工程师的消亡，我们关注得不够！》

作者是一位取得软工硕士学位、从事AI算法交易平台开发工作的朋友。元旦前夕，他用不到一天时间，通过AI工具，独立上线了一个过去至少需要 3 个人、一个季度才能完成的系统，并投入了生产。

文章中，他详细介绍了这一与AI共创的过程。而让人不安的是，他复盘了整个过程，他发现：整个过程中，初级程序员的工作直接被AI干掉了。

初级软件工程师，正在被 AI 从工程结构里直接压缩掉。

一些网友们看罢，纷纷表示：的确，初级职位（不包括实习生招聘）实际上已经不存在了，关于初级职位需要2-3年的经验的说法现在已经成为了事实。

甚至，一位网友讲述了一个更为扎心的招聘故事。工程VP在会议上，他被明确告知停止招聘大三和大四学生来培养初级工程师，那都是外包的活儿。

问题就在于，如果初级工程师的岗位干脆直接消失后，他们如何成为资深工程师？

如果新人不再经历“实现的痛苦”，他们要如何成长为真正的资深工程师？

怎么判断 AI 写的代码是不是在胡扯？

怎么在系统“看起来都对”的时候，意识到它其实已经埋雷了？

作者在文中对于这个问题，给出了自己的思考。

下面是小编整理的该文内容，希望能给大家启发。

我在 2021 年从卡内基梅隆大学

（CMU）

拿到了软件工程硕士学位。这发生在 ChatGPT 时代之前。那时的 LinkedIn 充斥着企业味十足的“水文”，但至少还是人一字一句写出来的，不是为了互动率而被大模型“内容工程化”的产物。

你知道的，那些“美好的旧时光”。

当年我进入就业市场时，对初级工程师最重要的判断只有一个是/否问题：坐在我面前的这个人，会不会写代码？

那时候，如果要从零开始做一个新应用，至少要投入一个月。就算你知道该用哪些库、怎么用，知道怎么做鉴权、需要注意哪些坑，知道如何把应用 Docker 化、如何在 CI/CD 流水线里配置自动部署——你

仍然

得老老实实坐下来，一行一行地敲代码。这是一个枯燥、繁琐、而且极其容易出错的过程。

但现在，这整个过程几乎被抹掉了。从一台 MacBook Pro 到绑定自定义域名，一个可扩展、可维护、还挺好看的 Web 应用，6 个小时之内就能上线。我知道这一点，因为我已经反复这样做过。

初级工程师曾经最有价值的那部分技能，几乎是一夜之间消失的

，而我们一点都不够恐慌。

这就是我为什么对初级工程师的未来感到担忧。

过去，初级工程师基本被当成“代码苦力”。在几乎所有大型科技公司里，不管是像

Meta

这样市值数千亿美元的巨头（我双胞胎兄弟就在那儿做中级工程师），还是像 Oscar Health 这样估值 50 亿美元的公司，层级结构大致都是这样：

一名资深到 Staff 级别的工程师写一份设计文档。它可能来自任何地方：要么是凌晨 3 点在冷汗中敲出来的，要么是从 C-SUIte 一路传到产品经理手里的。结果都一样——一份详细的技术文档，通常还带着代码片段，逐步说明要做什么。一名中级工程师把设计文档里的任务分配给自己、初级工程师，以及一位项目快做完的高级工程师。一名初级工程师，代码苦力。她被期望去写代码，但连 IDE 都不一定能跑起来，本地单测也可能根本跑不通。

ChatGPT 刚发布时，这套体系已经开始出现裂痕。但现在，随着

Gemini 3 Pro

和

Claude Opus 4.5

这样的模型出现，这个等级体系算是彻底粉碎了。AI 可以直接接收一份 BRD，在几乎没有人工干预的情况下，15 分钟内把它实现出来——一条提示词，从文档到 PR。

作为一个在

Coinbase

的工程团队里

完全没有初级工程师

的人，我忍不住开始想一个问题：

如果文章到这里就结束，那它也只会变成我在 LinkedIn 上每天躲不开的那种“水文”。

问题在于，我手里有证据。

12 月 30 日，我为自己的算法交易平台写了一份新功能的设计文档：一个完整的学习管理系统，类似

Coursera

。视频课程、测验、阅读材料、动手练习、结业证书，一应俱全。

在 2025 年 12 月 30 日，我的 Git 提交记录显示我创建了这份设计文档（“save course dsign”）。

我写设计文档的方式有点不一样。我会先让 AI 生成一个 HTML 文档，基本上就是带我走一遍完整的用户旅程。这样一来，它几乎可以替代 Figma 这类工具——我能真正“看到”一步步的流程，而不是停留在抽象描述上。

多张用户流程截图，可在该 git paste 中实际点击查看

地址传送门：

基于这个，我再写一份 Markdown 格式的设计文档，内容包括：

数据模型控制器，以及可能需要的异步任务前端页面前端组件最终的实现计划

12 月 31 日，我完成了初版设计。1 月 1 日，我把它上线了。

12 月 31 日，我交付了 MVP，并在此后一直做小幅迭代，直到 1 月 1 日。

这可不是落地页，是一个真实运行的生产系统，包含：

代码质量是真的不错。我也经历过那个年代：VSCode、YouTube、Stack Overflow，还有一个一周没洗、装着当天第三杯咖啡的马克杯。我不会假装它完美无缺，但它是

可理解的

。我能顺着逻辑推演下去，这让我至少有一半的信心，觉得自己可以在接下来几个月里维护它。

NexusTrade Learn 页面，在不到一天的时间里就完成上线并投入生产。 （项目：https://nexustrade.io/learn）

即便后期维护更难，账也已经算清楚了：一个周末加上持续修修补补，仍然比一个季度的人力投入要快。

当然，这个功能大量复用了我之前已经搭好的基础设施，比如支付系统、应用内教程等。但测验系统和学习管理这一整块，全部都是全新的代码。

两年前，这个项目至少需要三名工程师、一个季度的时间（甚至更久）。我很清楚，因为我做过类似规模的项目评估。

通常的配置是

：

一名资深工程师负责架构，一名中级工程师负责核心功能，一名初级工程师负责“苦力活”——堆组件、写测试、修边角问题。

根据设计稿实现那 35 个 UI 组件实现测验逻辑与校验串起学习进度追踪处理证书 PDF 的生成编写 API 接口修复随后冒出来的成百上千个小 bug

这些工作——也就是

实现层面的工作

——正是被 AI 吃掉的那一部分。

我并没有手写这 35 个组件。我只是描述需求，然后审核返回的结果。在很多情况下，Opus 4.5 第一次就生成了正确的代码。而我真正做的，是那些决策层的事情：这个系统该做什么？模块之间怎么连接？用户体验应该是什么样？

初级工程师，原本是连接“高级思考”和“可运行软件”之间的那一层实现缓冲区。而现在，这一层正在被压缩到几乎为零。

随之而来的，是一个

让我不安、却答不上来的问题

：

如果初级工程师从未真正经历过实现层面的苦工，他们要如何培养出成为系统架构者所需的直觉？如何学会在 AI 胡说八道时识别问题？

我

之所以知道

这些代码是对的，

是因为我曾经站在另一边

——那个每一个想法都伴随着巨大实现成本的时代。而现在，这个成本几乎不存在了。不管你是否愿意把它称作“水代码”。

先说清楚，我并不是 AI 末日论者。相反，我还因为频繁戳破 AI 炒作而“出过圈”。

备注：此前作者有写过一篇爆文，点赞超过了7k，评论多达330条：

“如果你真的相信所谓的 ‘AI Agent’ 叙事，那你就是个彻头彻尾的傻子。”

但我也不是瞎子。

在 Oscar Health 的第一份工作里，我被认为是一名优秀工程师，原因只有一句话：“执行力极强。”

说白了，就是我能又快又稳地写出能跑、质量还不错的代码。

如果我是在 2026 年入职这份工作，我还会被这样评价吗？还是只会被视为“中等水平”？

当然，后来我学会了系统设计，学会了如何写出更易维护、也更愿意被他人 review 的代码。这些能力都很重要。但在我当年的工作环境里，

最有价值的一项能力是什么？

把事情尽快做完。

而这道门槛，现在已经……消失了。AI 几乎不需要人手把手教导，就能在几小时内写出不错的代码。如果 AI 的能力永远停留在今天，那这整篇抱怨都没有意义。但 ChatGPT 是在 2022 年 11 月 30 日发布的，到现在也才刚过三年。你真觉得三年后它不会强得多吗？

我并不认为整个软件工程行业会消失。

我也不相信 AI 会抢走所有人的工作，更不觉得计算机专业会变成“废学历”

。

但有一个事实我始终绕不开：

初级工程师这个角色之所以存在，是因为“实现”本身很难。把设计文档翻译成可运行的代码，需要时间、技能和耐心。这种摩擦，支撑起了工程师层级中的一个完整梯度。

而现在，这种摩擦没了。

那初级工程师还能做什么？

也许，他们会变成“审稿人”而不是“作者”——验证 AI 的输出、抓住幻觉错误、对系统理解得足够深，知道机器什么时候在胡扯。也许，这个角色会被压缩成更偏“初级架构师”的形态，更早开始关注系统设计。也许，它会直接消失，我们得重新发明一套学徒制度。又或者，他们只会沦为一种被美化的代码审查员，逐行阅读自己既不被指望真正理解、也几乎无法判断实际影响的代码。

说实话，我是有点害怕的。

所以，这是我给初级工程师的建议。我知道这听起来很刺耳：

花 12 个月，从零开始，独立做一个完整系统。不用 Cursor。不用 Claude。不用 Copilot。甚至不要把报错信息复制进 ChatGPT。

自己搭一个真正的系统：鉴权、数据库、API、React 前端。只靠官方文档、Stack Overflow，以及你自己的痛苦，把它部署到云端。

在你第一次走进“真实世界”、开始第一份软件工程实习之前，把这件事做完。

当你不得不手动重构一个糟糕抽象时，感受它的重量。

当你第二个月设计错的数据库 schema 在第八个月持续折磨你时，体会那种具体而真实的痛。

当页面加载要 11 秒、而你只能一行一行排查原因时，真正理解“走捷径”意味着什么。

这听起来像是入职前的折磨。

像是“我当年上学可是翻山越岭”的老派说教。

也像是已经上岸的人在抽走梯子、搞门槛。

也许确实如此。但有一点我无法否认：

我之所以能判断 AI 写的代码是不是好代码，是因为我曾经写过很多烂代码。

我之所以能抓住幻觉，是因为那些错误我自己亲手犯过。

我之所以信任自己的判断，是因为我是慢慢熬出来的。即便如此，我仍然会出错。

如果从未真正失败过，品味从何而来？

我不认为那做得到。

那些跳过痛苦阶段的初级工程师，不会成长为资深工程师。他们会变成“AI 操作员”：能交付代码，却无法评估代码。他们会在 AI 信心满满却犯错的时候，合并那个把生产环境干趴下的 PR，因为他们没有足够的直觉去否定它。

我理解为什么这些建议听起来很残酷。既然捷径已经存在，为什么还要主动选慢路？当同龄人借助 AI 快你 10 倍交付时，为什么要自我设限？

因为捷径是有上限的。

2030 年的资深工程师，不会是 2025 年写了最多 AI 辅助代码的人。他们会是那些

能在 AI 看不懂的方式出错时，调试 AI 代码的人

。他们会是那种在指标出问题之前，就已经“感觉哪里不对”的人。

这种直觉，不可能靠看 AI 干活学会。

所以，是的：至少一次，走那条难路。做一个没有拐杖的真实项目。感受每一道纸割般的小伤。堆时间，熬经验，把知识挣到手。

然后，也只有在那之后——再拿起 AI 工具，你才真正知道自己在看什么。

否则，我们很可能迎来这样一代工程师：

然而，一个让人讨厌的事实是：我很清楚，我们现在正朝着那个方向走。

参考链接：

https://medium.com/@austin-starks/the-death-of-the-code-monkey-why-i-fear-for-the-class-of-2026-13dbf531a76f