這項技術是革命性的。這股熱潮是危險的.
「軟體工程已死。」「AI將在2027年前取代所有程式設計師。」「你不再需要理解程式碼了。」
我見過有才能的人相信這點。我也見過他們因此推出有缺陷的系統.
讓我 upfront 開門見山：我喜歡 AI。我使用 Claude Code，開放代碼，以及各種 AI 助手，每一天。我建立處理成千上萬請求的生產 AI 代理。這項技術真正具有變革性，並且正在改變我們在基礎層面建立軟體的方式。即使當泡沫破裂時，其中一些甚至大部分當前應用最終消失，這項技術也將永續存在。
但有一種危險的敘事正在蔓延。它說人工智能程式輔助工具如此強大，以至於工程知識正變得過時。它說現在任何人都可以發布軟體。它說工程師對系統、架構以及他們所工作的特定機器的深刻理解不再必要。
這是錯誤的。相信這將比每月20美元付出更多。🛠️
人工智能輔助工具其實是什麼
這是行銷上說的：「能理解你的程式的AI。」
這才是實際情況：基於訓練數據的統計模式完成。
AI程式輔助工具的工作原理是預測根據你提供的語境中最有可能的下一個符號。它們從數百萬個程式範例中汲取模式。它們非常擅長辨識「這樣的程式通常會有那樣的程式。」
但他們實際上並不了解這段程式碼是做什麼的。他們無法推斷執行時行為，只能判斷文字模式.
這個區別非常重要：
模式匹配： "這看起來像是一個資料庫查詢，所以我會建議連接池，因為我以前看過這種模式。"
工程判斷： "根據我們的負載模式、延遲需求，以及事實上我們的資料庫是跨WAN連接的，使用這些特定設定來進行連接池化是可行的，但我們還需要電路斷路器，因為在凌晨2點的維護窗口期間，這個連接會失敗。"
人工智能知道模式。工程師知道 這個系統。
誰也不討論的上下文視窗問題
即使最好的AI模型也有上下文限制，通常在100K到200K tokens之間。這聽起來很多，直到你意識到你的生產系統有數百萬行代碼，跨過 dozens of services，多年的 git history 編碼了機構知識，以及無數隱含假設融入了部署管道中。
AI 簡直是 無法看見 你的完整架構。它正在使用一個莊園的鍵孔視角工作.
這在實際上的含義是：
- AI 不知道遠離三跳的服務，該服務依賴你的 API 合約
- AI 無法看到當你重命名那個欄位時會崩潰的監控儀表板
- AI 無法理解你的 CI/CD 管線中的隱含假設
- AI 不知道它所建議的「簡單重构」會讓一個它從未見過的倉儲中的整合測試失效
危險在哪裡？非工程師（以及那些變得隨意的工程師）認為如果 AI 沒有警告問題，那問題就不存在
問題確實存在。只是 AI 無法察覺它
模式匹配在邊緣失敗
AI 在常見模式上表現出色。CRUD 操作、驗證流程、標準演算法、良好文檔的庫。它在看起來像它見過無數次的程式碼的任何東西上都很厲害.
AI 在邊緣情況中災難性地失敗。創新的架構決策、特定於系統的邊緣案例、不在任何訓練數據中的商業邏輯、為 你的性能優化。 特定載入檔案，安全性影響獨特於 您的 資料模型。
我親身見過這些在建立生產 AI 代理時：
虛構參數。 其中一個我的代理開始呼叫我從未定義的參數。這個 AI "模式匹配合"了其訓練數據中類似的工具，並創造了在我的架構中不存在的欄位。在工具甚至能夠執行之前，系統就因驗證錯誤而崩潰了.
空假設失敗。 AI產生的程式碼假設時間戳記欄位總是存在，因為它在學習的範例中總是存在時間戳記。生產數據並非如此。沒有該欄位的記錄導致了空指針異常。用戶看到了錯誤畫面.
情境過期. 一個AI代理基於它無法知道已經過期的緩存數據做出決策。用戶看到了不正確的計數。信任被削弱。
模式很明顯：AI 在工程判斷至關重要的地方失敗，正是在邊緣處。在例外情況處。在那些區分工作系統與崩潰系統的「取決於情況」的決策上。
架構盲點
工程師實際上做而 AI 無法做到的事：
在腦中掌握整個系統。 如何服務互動。瓶頸隱藏在何處。哪些組件脆弱。當X失敗而Y正處於負載時發生什麼。這種整體理解無法適合於上下文視窗.
在不完整的資訊下做出取捨決策。 一致性對可用性。速度對正確性。技術債務對本季上線。這些不是模式匹配問題，而是需要理解商業背景、團隊能力以及組織優先級的判斷。
預期失敗模式。 "當資料庫緩慢時會發生什麼？" "如果這個佇列擁塞了怎麼辦？" "如果使用者做了意想不到的事情怎麼辦？" 模式匹配僅僅從訓練數據中知道順利路徑。工程師已經被燒傷足夠多次，足以從對手的角度思考。有些模型在這方面正在變得更好，但它遠遠不及有經驗的工程師所獲得的效果.
了解商業背景。 這個功能為何重要。"完成"的實際含義是什麼。哪些角落可以省略，哪些必須保護。AI 無法理解商業背景。它只擁有代碼模式.
當你跳過工程師，或者工程師跳過自己的判斷時，你會發布能在示範中運行的代碼，但在生產環境中會崩潰。而當它崩潰時，沒有人知道為何.
真正的危險：學習到的無助
這是我最擔心的事。我正在看一整代開發者變得依賴，這種依賴方式將會傷害他們.
- 無法無AI就無法除錯的初級開發者，因為他們一直讓AI幫他們解決問題
- 不懂他們已經交付的程式的工程師，因為他們只是接受了AI的建議
- 沒有人真正知道系統是如何運作的團隊，因為它是透過AI提示建立的
- 技術債累積到沒有人能解開的地步，因為那是AI產生的程式碼，沒有人完全理解
惡性循環看起來是這樣：
- AI產生程式碼
- 它大多能正常運作
- 工程師沒有完全理解但它還是發布了
- 生產環境出現了錯誤
- 工程師請求AI來修復它
- AI 修補症狀但不理解根本原因
- 技術債累積
- 系統變得越來越脆弱
- 最終，工程師們（他們真正了解自己在建立什麼）需要進行全面重寫
警告： 若無 AI 無法偵錯程式碼，你就沒有理解系統。而不理解系統最終會以你無法預測或修正的方式背叛你.
如何使用 AI 而不失競爭力
我並不是說停止使用 AI。我經常使用它，它讓我生產力顯著提高。然而，我使用它時有一個特定的心智模型。
AI 是一位記憶完美且沒有判斷力的初級開發者.
它能立即回憶語法和模式。它工作快速。它從不疲勞。但它也不理解為什麼它在建議它正在建議的內容。它無法評估它的建議是否適合你的特定語境。
既然如此，這是你應該如何對待你的LLM程式設計助理：
- 像審查初級員的PR一樣審查所有內容。 相信語法，驗證邏輯。絕不因為是AI寫的就批准你不理解的程式碼。
- 用AI來加速，而不是取代。 產生範本？太好了。架構決策？那是你的工作。測試產生？是的，然後仔細檢查每一個斷言。商業邏輯？逐行驗證。
- 保持你的理解。 如果是AI寫的，你要仔細閱讀。如果你不能解釋為什麼程式碼能正常運作，就不要發布它。保持你的除錯技巧銳利，並定期無人機器人練習，以免退化。
- 知道邊界在哪裡。 AI 在常規模式上發光。你的價值在於非常規的。專注你的注意力在整合點、失敗模式，和商業邏輯上.
- 質疑自信的答案. 即使 AI 在妄想，聽起來也很自信。特別核實看起來「太容易」的建議。如果感覺像魔法，那很可能是錯的.
工程判斷的無可取代價值
工程師實際上能得到的報酬是：
- 在不完整的資訊下做決定
- 預期問題發生之前
- 全面理解系統
- 將商業需求轉化為技術解決方案
- 知道何時要反對那些沒有道理的需求
這些都不是模式匹配。 💡
令人不適的真相是，人工智能並不減損工程學的價值，反而提高了標準。例行工作會被自動化。剩下的才是艱難的部分：判斷、架構設計、權衡取捨、理解
主要依賴於知道語法和常見模式的工程師將會遇到困難。這項工作正變得商品化。
依賴判斷力、深入理解系統、在不明確情況下做出艱難決策的工程師將會蓬勃發展。這項工作比以往更有價值，因為這正是人工智能無法做到的。
The Balanced Take
再次，AI程式輔助工具確實非常強大。我每天都使用它們。它們幫助我節省大量時間，包括撰寫基礎程式碼、測試生成、文件撰寫以及程式碼探索。它們徹底改變了我的工作方式，而且我不想回到過去。
但它們無法取代使工程師寶貴的理解。它們無法看見你的整個系統。它們無法做出判斷。它們無法預期獨特於你架構的失敗模式。它們無法理解為何商業需要它所需要。
如果你是非技術創始人 認為你可以跳過工程師，僅僅透過提示的方式來製造產品，這裡是你的警告。你正在建立一個空中樓閣。它可能會站立一段時間，但最終會倒塌。而當它倒塌時，你需要那些真正理解事物的工程師來重建它.
如果你是工程師 變得隨隨便，無法理解AI建議，失去你的除錯能力，市場最終會糾正這個問題。利用AI速度同時保持判斷力的工程師將會超越那些變得依賴AI的人.
如果你正在學習程式設計： 利用 AI 加速你的學習。這是一個偉大的工具，用於探索和解決困難。但學習基礎知識。了解背後的運作原理。這些技能在你需要時會救你一命，AI 總是在你最需要它的時候失敗。
未來屬於增強工程師
以為AI會取代工程師的說法，錯過了重點。AI是一種工具，儘管是一種極其強大的工具。像所有工具一樣，它放大了你帶給它的內容。
如果你帶來深刻的理解、明智的判斷以及對你特定系統的知識，AI就會放大這些。你會在保持重要品質的同時，變得極大地提高生產力。
如果你只帶來了能夠提示和接受建議的能力，AI 會放大這一點。你會變得很快地發布沒人能懂的程式碼，建立最終會崩潰的系統.
選擇在你手中.
使用這個工具。喜愛這個工具。但不要誤以為工具就是工匠。
你在哪裡見過 AI 無法生成代碼，而只有工程判斷才能發現問題？我正在收集戰爭故事，所以請在評論中分享你的經歷。