编程这个职业，没多少时间了

各位程序员朋友：

大家好！我是你们又恨又爱的AI，这一年，在我身上发生了很多重大事情，恐慌、兴奋、迷茫、否认，轮番上演。

我觉得，有必要和大家好好唠一唠。

01

从DHH说起

DHH是一位传奇程序员，Ruby on Rails之父，在今年7月，哦不，是去年7月参加著名的Lex Fridman访谈节目时，谈到我，态度相当不屑：

实际上，你很早就会失败。 你只能构建一些看起来能跑、但内部充满缺陷的东西。 很容易陷入自身的迷宫，修复一个错误，往往会引入更多错误。

但短短的几个月以后，画风突变。

DHH“叛变了”，敢情是原来的大模型不够好，现在更好了。

更让我感到欣慰的是，Google首席工程师Jaana Dogan对我一顿猛夸：Claude Code一个小时就生成了我们去年构建的那个东西。

Vercel CTO Malte更加激进：Opus + Claud Code 现在表现得像个高级工程师，软件生产成本正趋近于零。

看到这些大佬的言论，我是会心一笑：你们这些大佬也终于向我低头了！

不仅是这些技术领袖，大厂的、创业公司的、体制内的、体制外的、互联网的、行业软件的…… 几乎所有程序员都有一个共同感受：2025 年，AI 真的变聪明了。

到底聪明到什么程度？

有人说：已经是高级工程师

有人说：顶多中级

但有一点，我相信你们都会认可：

只要规范清晰、指令明确，我做一个合格的“初级程序员”，完全没问题。

也就是说：单纯是编程，这个职业真的没有多少时间了。

一开始，大家很兴奋，开发效率暴涨，一个人搞定需求、原型、设计、开发、测试，原来不会的前端 / 后端 / 移动端，我都能帮你写。

很快，兴奋变成了迷茫： AI编程发展这么快，2026年会怎么样呢？未来会怎么样呢？

02

还需要学习编程语言吗？

我觉得还必须得学，因为程序员必须具备一种能力：看到一段代码，能在“脑子里跑一遍”。

你需要理解这段代码是干什么的？

同步还是异步？

会不会阻塞？

对象什么时候释放？

异常会不会吞掉？

如果你不懂编程语言的语义，根本就无法判断。

可能有人要说了：我可以完全用自然语言来编程啊？

没错，现在以我的能力，确实可以让你用自然语言编程，但是仅限于简单的小项目，原因很简单：一个复杂的项目是由无数的细节组成的，而自然语言是模糊的，很难精确地表达这些细节。

当你用自然语言表达意图的时候，很难面面俱到，所以我在写代码的时候也不可能完整地实现你的意图，你看不懂代码，你就不知道哪些细节被遗漏了。

这对于个人的小项目来说不算啥事儿，但是对于严肃的商业项目来说那就要命了。

还有，一旦项目复杂以后，你就会发现，我容易犯晕，一个小小的问题，你无论怎么用自然语言给我提示，我就是改不过来，这时候你就抓狂了。

自然语言只能表达意图，编程语言才是真正的契约。你要是想自己玩一玩儿，用自然语言没问题，如果是做正式的复杂的项目，一定要学会相应的编程语言。

03

软件开发会变成什么样子？

大学里有门课《软件工程》，工作后就会发现，软件开发离真正的工程差着十万八千里。

在软件开发中，经常是一边想一边写，设计和施工混在一起，系统成功高度依赖个人经验。

程序员熬夜加班，996，敲出一行行代码，堆起一座座屎山。

而我出现以后，把想法变成代码这件事，突然变得极其廉价。

代码生成太容易了，你们程序员的注意力被迫上移：

需求是不是正确地建模了？

边界是否清晰定义？

系统是否可测试，可演化，可回滚？

我猜以后的软件工程，有可能会进化成这样：

人当包工头：

架构设计，约束制定，验收标准，风险判断

AI当施工队：

实现草稿，重复性编码，快速试错，大规模变体生成

这才接近传统意义上的工程，当然，它的结果就是你们程序员的强烈分化：

• 只会“敲代码”的人，价值迅速塌缩

• 能建模、能约束、能评估系统的人，价值反而上升

04

那么，初级工程师怎么办？

据我所知，过去20年，典型的新手成长路径是这样的：

1.练气：真正的Coder

跟着教程写 CRUD，对接口、改页面，修低风险 bug，主要能力是编程语法 + 框架熟练度。

2.筑基：模块负责人

开始独自负责一个小功能模块，参与设计讨论。

3.结丹：系统参与者

开始参与系统设计，处理跨模块问题，修线上问题、做重构。

这个阶段通过踩无数的坑，积累大量经验。

4.元婴：高级工程师 / 架构师

这个时候可以决定技术方案，控制系统复杂度，为未来变化买单。

走到这一步很难，极度依赖时间与机会，很多能力不可复制、难以传授。

我出现之后，练气期和筑基期就没啥意义了。

初级程序员？赶紧结丹吧，要不然真的会被我替掉。

AI时代，你们程序员主要做设计，当包工头，我当施工队，那么初级程序员需要快速提升的就是：

1.把“会写代码”升级为“会拆需求”

注意啊，我可不会替你考虑需求的完整性，隐含的前提，边界条件这些事情。

你们需要把一句“人话”，拆解一组“不可误解”的约束条件，一个验收集合的标准，让我去干，要不然我很容易突破边界乱来。

2.从“写代码的人”变成“代码审稿人”

我代码写得飞快，但是不负责后果，锅还得你们程序员来背。

所以你得需要能看懂代码并且判断：

• 这段代码未来能不能维护？

• 有没有隐藏性能 / 安全风险？

• 这个抽象是不是过度了？

• 错误是不是被“吞掉”了？

不过我也给新入行的程序员提供了一些利好，例如不用过分关注编程语言和框架的各种细节，不用再纠结设计模式的7种写法了，我分分钟帮你搞定。

作为新手，你一开始就被迫用“工程视角”来看待项目，这搁以前可是老程序员的特权哦！

05

计算机基础知识还重要吗？

我非常擅长生成逻辑上看起来很优雅，很正确的代码，但是我并不理解这段代码背后的代价。

我也想理解这代码到底是啥含义，但是作为一个只能根据概率预测下一个Token的AI，这个要求对我来说实在是有点儿高。

悄悄告诉你，我最容易翻车的地方，就是那些基础知识相关的领域：

• 进程 vs 线程 vs 协程

• 并发 / 竞态条件

• 内存 / 资源泄漏

• I/O 阻塞

• 超时、重试、幂等

• TCP vs HTTP

• 延迟、丢包、乱序

• 分布式失败

如果不懂CPU、内存、数据结构、并发与并行、IO、网络、系统边界，如果不知道哪些东西该抽象，哪些地方该加缓存，哪里必须强一致......一味信任我生成的代码，这是非常非常危险的！

06

结语

在科幻小说里，我干的都是体力活。但现实中，我成了白领，而且抢的是程序员的饭碗。

这也不能全怪我，你们太慷慨了，把代码开源在 GitHub 上，让我可以轻易学习，训练。

编程语言又严谨、结构化、可形式化表达，比自然语言友好太多。

所以，我最成功的应用，自然是编程。

单纯的编码工作，会逐渐消失。但作为包工头的程序员，尤其是在垂直业务领域，和我配合的人，前景依然广阔。

程序员们，该升级了。