出品 | 51CTO技術棧（微信號：blog51cto）
AI 正在徹底重塑程序員的工作方式，這已經不是什么新聞了。
但 GitHub CEO Thomas Dohmke 最近在推特上的一句話，依然掀起軒然大波：
你要么擁抱 AI，要么就退出這個行業。
聽起來像某種 PUA 式威脅。仿佛是哪個苛刻老板對員工的“勸退信”。
為什么他說得這么絕？
圖片
其實，他不是一時沖動，而是在分享自己發布的一篇關于AI IDE的深度博客。
這篇文章基于對 22 位深度使用 AI 工具的開發者 的實地訪談，總結出了他們從“AI 懷疑者”轉變為深度使用者的全過程。
Dohmke 寫道：
“那些從早期懷疑中堅持下來的開發者，普遍展現出更強的野心、更高的技術素養，以及更強的職業滿足感。”
在這份報告中，Dohmke 還觀察到以下四個核心趨勢：
- 在未來 2 到 5 年內，AI 有望生成 90% 的代碼；
- 開發者并不焦慮，而是以現實而樂觀的態度迎接變化；
- 新技能已經成為核心：智能體編排、迭代協作與批判性驗證等都尤為關鍵；
- 節省時間？當然有。但真正的變化，是開發者的“野心更大了”，他們正在“抬高能力上限”，而不只是“壓低開發成本”。
然而這番高調預言，也引發了網友的激烈爭論。
一位開發者在 Hacker News 上直言：
“AI 只會創造更多屎山！程序員早就飽和了，很多代碼壓根不該被寫出來！”
而也有人站在另一邊，提出了截然相反的觀點：
我認為Dohmke的觀點成立的可能性很大，編程極易受到“杰文斯悖論”影響：當某項技術提升效率后，反而促使我們去做以前不會做的事。
比如我現在就在開發一些一年前不敢動手的項目： 那時要么耗時太久，要么根本不可能做——而現在靠 LLM（像 MCP server 那種）就能搞定。
圖片
Dohmke 在博客中還進一步將開發者的 AI 成熟過程分為四個階段，并提出了面向未來的七項核心技能。這篇博客可以說是一次結構清晰、觀點明確的職業路線圖。
接下來，就讓我們一起看看這篇博客中的那些干貨內容：
一、發出警告的原因：別讓一次失望，錯過整個時代
在博客中，Dohmke 表達了一個明確的擔憂：
太多人因為對 AI 編程工具的“一次失望”，就徹底放棄了探索的機會。
他說，許多開發者第一次接觸 AI 編程工具時的反應是：
“挺酷的，但不實用，有點花架子。”
這并不罕見。很多人一開始對 AI 寄予厚望，結果卻遭遇模型“答非所問”、提示詞沒反應、代碼不靠譜……最終認定它不值得依賴，索性直接棄用。
但 Dohmke 觀察到：那些堅持下來的開發者，往往會迎來關鍵的“啊哈時刻”——
他們學會了如何調整期待、掌握提示技巧、配合工具特性，并在實戰中節省了大量時間，把 AI 真正變成了“得力助手”。
因此，他的建議非常簡單直接：不斷嘗試各種 AI 工具，哪怕工具本身尚未成熟或始終達不到預期。
二、擁抱 AI的四個階段：從懷疑者到策略家
Dohmke指出，對開發者來說，擁抱 AI 是一個逐步演進的過程，由每天的試錯積累而來。
他總結了開發者嘗試AI編程工具的四個典型階段：
階段 1：AI 懷疑者
只在小任務中嘗試 AI，使用場景多為代碼補全，對反復調試和錯誤容忍度低。堅持下來的開發者，往往會放下“一次成功”的幻想。
階段 2：AI 探索者
開始用 AI 做調試、寫樣板代碼和代碼片段，逐漸了解 AI 的局限性。隨著實踐增多，他們會開始借助 AI 頭腦風暴復雜任務，接受“迭代提示”的策略，意識到當結果不理想時，推倒重來比硬拗下去更劃算。
階段 3：AI 協作者
進入深度共創狀態，形成上下文管理的直覺。他們在 AI IDE 中完成多步操作和多文件修改，習慣在開始前先讓 AI 輸出整體計劃，制定智能體規則，并根據任務切換工具或模型。他們也會在團隊內參與討論或演示，分享提示詞、用例和經驗。
階段 4：AI 策略家
將 AI 視為強力搭檔，共同承擔功能開發、復雜任務和大型重構。他們設計復雜的多智能體工作流，將任務拆分給不同模型，并逐步實現更高的自動化和并行處理。這一階段的開發者對未來充滿信心和樂觀。
進入第四階段的開發者無一例外地認為：他們的角色已經發生了質的變化。他們的關注點轉向了“任務的委派與驗證”。
委派意味著：為 AI 智能體創造成功的前提，包括提供詳實的上下文和指令，設計并反復優化提示詞，評估 AI 的方案與權衡，并在執行前進行必要的調整。
驗證則意味著：對 AI 的產出進行拆解與審核——確認 AI 實現的功能是否符合預期目標、是否遵守規范。
他們的角色從“編寫代碼者”轉變為“設計架構與驗證實現者”。
三、90% 的代碼將由 AI 編寫，人類開發者負責善后！
GitHub 在調研中還詢問了開發者對 AI 寫代碼比例的預期。結果顯示：
- 50% 的開發者認為：未來 5 年內，AI 將生成 90% 的代碼；
- 另外 50% 更激進：這個結果將在 2 年內出現。
但最關鍵的是：Dohmke 強調開發者并不因此感到被剝奪價值，反而認為這是一次“身份的重塑（reinvention）”。
AI的普及意味著一些傳統的編碼崗位將減少，或者被深度改造：工作重心從“親手寫代碼”，變成“如何指揮 AI 完成任務，再進行驗證”。
但與此同時，美國勞工統計局（BLS）依然預測：未來十年，軟件開發者的崗位將增長 18%——這是所有行業平均增長率的 5 倍。
所以，它不會是我們熟悉的“舊程序員”，但它依然是一個值得投入的職業身份。
我們還發現了一個很有趣的現象：
幾乎沒有開發者把“節省時間”當作使用 AI 的最大收益。他們更多談到的是：野心變大了，想做的事情也變多了。
四、未來開發者最需要掌握的7大關鍵技能
1. AI 素養（AI fluency）
未來的開發者，必須理解不同 AI 工具、平臺與模型的能力與局限，才能有策略地調整工作流。
這不僅要求持續的實踐性學習，更要求一種適應變化的心態，因為 AI 的發展速度是“瘋狂”的（breakneck speed）。
2. 委派與智能體編排（Delegation & Agent Orchestration）
要讓 AI 智能體高效完成任務，開發者必須學會如何：
- 提供完整清晰的上下文與指令（Prompt Engineering）；
- 正確定義問題邊界與拆分任務；
- 并行處理工作流；
- 明確表達成功標準與限制條件。
隨著 AI 素養提升，開發者也會逐漸形成判斷：什么時候該實時配合 AI 完成任務，什么時候可以完全交給 AI 后臺異步處理？
別小看“溝通”這件事。寫清楚一段指令，不只是自然語言能力——模糊指令或一句話提示，無論對人還是對 AI，都不足以驅動出色的執行結果。
3. 人機協作能力（Human-AI Collaboration）
當你選擇“同步協作”AI 時，還必須建立起：
- 快速迭代反饋機制；
- 合理的停止判斷機制；
- 讓 AI 自我批評的提示；
- 鼓勵 AI 反向提問，幫助它更理解你的意圖。
4. 編程基礎（Fundamentals）
是的，AI 已經能生成代碼了，但這并不意味著基礎知識不重要，反而更加關鍵。
開發者依然需要理解：
- 編程語言的基本原理；
- 常見算法與數據結構；
- 軟件系統的整體架構。
只有這樣，才能理解復雜代碼背后的邏輯，判斷 AI 的輸出是否合理，也才能在“驗證 AI 工作”的過程中發現問題。
5. 驗證與質量控制（Verification & Quality Control）
AI 生成的代碼需要更嚴謹的審核，這就要求開發者具備：
- 代碼審查能力；
- 測試編寫與覆蓋；
- 對規范、安全性的敏感性。
AI 工具越強大，驗證環節就越不可忽視。有經驗的開發者會提前考慮如何設計“上游的質量保障機制”。
6. 產品理解力（Product Understanding）
這不僅是寫代碼的能力，而是一種“系統思維”。
未來的開發者，必須更像產品經理，懂得：
- 整體把控用戶需求；
- 原型設計與構思；
- 定義明確的目標與驗證標準。
否則，即使 AI 幫你寫出功能完整的代碼，也未必能達到產品目標。
7. 系統架構與設計能力（Architecture & System Design）
隨著 AI 逐漸承擔底層編碼工作，人類開發者就更需要站在高處思考整體架構：
- 各模塊如何協同？
- 哪些設計模式最優？
- 怎么讓 AI 的輸出與整個系統無縫集成？
這一層能力，才是未來開發者不可替代的核心競爭力。
五、寫在最后
Dohmke 對 AI 編程未來的描繪，的確充滿樂觀，甚至有些“玫瑰色濾鏡”。
而這份愿景背后，也不乏商業動機——畢竟，作為 GitHub CEO，他自然希望更多人為 Copilot 續上那一份訂閱。
但樂觀并不等于盲目。
我們不能忽視，AI 編程依然面臨不少挑戰。此前，不乏研究指出，AI 生成的代碼可能降低整體質量；此外，安全漏洞、隱私泄露、提示注入等風險，也仍在持續暴露中。
但不可否認，從 Claude Code 到 GPT-5，每一家 AI 公司都在以“接力賽”的速度，持續推進 AI 編程的邊界。從輔助寫代碼，到理解系統、主導架構，AI 參與程度越來越深，改變也愈發不可逆。
那么你怎么看？
你覺得 Dohmke 的預言會實現嗎？AI 寫 90% 的代碼，離我們還有多遠？
歡迎在評論區一起聊聊。
參考鏈接：
1.https://www.finalroundai.com/blog/github-ceo-thomas-dohmke-warns-developers-embrace-ai-or-quit
2.https://ashtom.github.io/developers-reinvented
