編程這個職業，沒多少時間了

各位程序員朋友：

大家好！我是你們又恨又愛的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 上，讓我可以輕易學習，訓練。

編程語言又嚴謹、結構化、可形式化表達，比自然語言友好太多。

所以，我最成功的應用，自然是編程。

單純的編碼工作，會逐漸消失。但作為包工頭的程序員，尤其是在垂直業務領域，和我配合的人，前景依然廣闊。

程序員們，該升級了。