之所以 AI 能讓你「看起來資深」，是因為 AI 可以讓工程師更快速的產出程式碼，也可以讓沒有太多經驗的人，看起來像是能處理更複雜的任務。但是當沒有使用 AI 時，就什麼都不會了。
你有沒有一種經驗，當你平常計算數字都依賴計算機，突然讓你心算，你會不會突然不知道怎麼辦了? 你使用計算機可以很快的算出結果，不代表你很會數字計算。
「真正資深」是思考、判斷、與經驗的累積，不是使用 AI 能讓你達到的境界。真正的資深是「我可以很快做出來」之外，還要「我知道為什麼要這樣做? 這樣做的原因是什麼? 什麼情況下不該這樣做?」
這是 AI 時代，很多人容易誤判自己能力的地方。以為自己會走路了，其實你是靠 AI 扶著你才能走路的。
AI 讓工程師解決問題更快，但不是更快變資深
根據 Stack Overflow 2025 Developer Survey 顯示大約 84% 的受訪者已經使用或計畫在軟體開發流程中使用 AI 工具，專業開發者中有 51% 每天使用 AI 工具。這代表 AI 已經不是少數工程師的玩具，而是進入主流開發流程的日常工具。
另一個是 GitHub Copilot 的研究，Microsoft Research 發布的 GitHub Copilot 生產力實驗中，使用 Copilot 的開發者完成 JavaScript HTTP server 任務的速度，比未使用者快了 55.8%。
這些數據說明了一件事：AI 對「產出速度」確實有幫助。但判斷工程師是否資深，不能完全只看速度。
如果只是比誰能更快生成程式碼，AI 當然能讓很多人看起來進步很快。問題是軟體開發真正困難的地方，常常不是第一版 code 怎麼寫，而是這段 code 進入既有系統之後，會不會影響資料一致性、權限邏輯、效能、部署、監控、資安、維護成本，甚至團隊未來半年到一年的開發效率。
真正的差距在於「經驗的累積」
很多初階工程師使用 AI 之後，會快速跨過以前需要幾個月才能摸熟的東西。例如語法、框架、工具設定、單元測試、文件摘要、錯誤訊息解釋。
這雖然是一件好事，但這也會製造一種錯覺：我好像變強了。
真正需要小心的是，AI 讓人更快拿到「答案」，卻不一定讓人理解「答案怎麼來的」。
以前只有紙本地圖的時候，要去一個陌生的地方出差或旅遊，一定都會抱著地圖研究半天，搞清楚所有週遭的路線資訊。現在有了 Google 地圖或導航系統，連路癡都可以到達目的地。
但是一旦 Google 地圖或導航系統出了問題，就可能帶來災難式的後果，例如開車開到懸崖邊、湖裡、或是深山深處，然後發生意外事故，這主要都是因為「過度依賴科技」。
Stack Overflow 2025 Developer Survey 有一個很值得注意的數字：66% 的開發者對「AI 給出的答案幾乎正確，但還是不完全正確」感到挫折；45.2% 認為除錯 AI 生成的程式碼更耗時；16.3% 提到很難理解程式碼如何運作或為什麼會這樣運作。
這篇文章"你不能不知道的 AI 風險，多數人都沒看到全貌"就提到 :
AI 真正最深遠的風險，不是我們常談的失控或取代，而是更隱微、更難察覺的一件事：讓人類逐漸停止思考。
相對於顯性的風險，隱性的風險才更致命。因此要能質疑 AI 給你的結果 : 如果你一直滿意 AI 給你的結果，你應該要開始擔心。 當 AI 給你答案之後，你應該做的是 : 這結果怎麼來的? 我自己能否產出這樣的結果?
AI 產出一段 code 表面上可以執行，測試可能也會過關。但如果工程師不知道它背後的假設，就會錯誤地相信它是正確的。這種錯誤不一定會馬上爆出來，但是通常會在流量變大、需求變複雜、資料變髒、第三方服務不穩、權限規則改變、邊界資料出現時才會浮現出來。
這篇文章"Vibe Coding 的真正核心競爭力：資料庫思維"就提到，業餘的阿三利用 Vibe Coding 替老媽的團購做了一個管理系統。剛開始都很美好，很快速的處理進庫、領貨、結帳，讓老媽很高興。結果因為 AI 使用資料中的行動電話當主鍵，讓客戶無法更改行動電話。結果 AI 修改成可以修改行動電話欄位後，竟然找不到資料了。在正常情況下沒有問題，但是當特殊情況出現就可能搞亂整個系統了。
資深工程師和「看起來資深」的工程師，差別就在這裡。
看起來資深的人會說：「這段 code 可以跑。」
真正資深的人會知道：「這段 code 在什麼條件下可能會出問題？」
AI 會放大能力，也會放大弱點
Google Cloud 的 DORA 團隊在 2025 年發布 State of AI-Assisted Software Development 報告時，提出一個很重要的觀察：AI 不會修好一個團隊，而是放大團隊原本的狀態。強的團隊會因 AI 變得更有效率；原本流程混亂、測試不足、架構耦合嚴重的團隊，會因 AI 更快暴露問題。DORA 也指出，AI 採用雖然和生產力提升有關，但仍然和軟體交付穩定性（Software Delivery Stability）呈現負面關係。
這段觀察放到個人工程師身上也很適合。
如果一個工程師本來就會問 「為什麼」，AI 會讓他更快檢查假設、更快比較設計選項、更快閱讀陌生程式碼。
但如果一個工程師本來就習慣複製貼上、不追問原因、不驗證邊界條件，AI 只會讓他更快產出更多自己也不懂的 code。
所以 AI 並不是平均地提升所有工程師，AI 比較像放大器，它會放大你的思考方式。
會思考的人，變得更快。不思考的人，也會變得更快，而且可能更快地製造風險。
資深的核心不只是產能，而是穩定的可信任程度
很多公司在評估工程師時，仍然太容易把「產出速度」誤認為是「能力成熟」。
但資深工程師的核心價值，不只是一天能寫多少行 code，也不是能不能很快把任務結案，真正的核心是穩定的可信任程度。
交給你一個模糊的需求，你能不能釐清真正要解決的問題?
交給你一個老舊的系統，你能不能先理解它，而不是急著重寫?
交給你一個看似簡單的改動，你能不能看出它會影響哪些模組?
交給你一個 production incident，你能不能先止血，再追根因?
交給你一個 AI 生成的解法，你能不能判斷它適不適合這個系統?
這些能力，不會因為多用幾個 AI 工具就自動產生出來。
GitLab 2026 AI Accountability Report 的資料也提醒了同樣的風險，GitLab 調查 1,528 位 DevSecOps 專業人士與技術採購者後發現，91% 的組織已經同時使用兩種以上 AI coding tools，78% 表示開發者寫 code 與 commit code 的速度變快；但同一份資料也顯示，73% 擔心 AI 生成程式碼的長期可維護性，82% 認為 AI 生成程式碼可能形成一種新的技術債（Technical Debt）。
這就是問題所在 : AI 加快 code 產生速度，但也讓「沒想清楚的 code」變多。
真正的資深工程師要處理的，往往不是如何更快產生 code，而是如何讓系統在一年後、五年後，仍然能被安全地使用與維護。
會用 AI 的新人，還是可能不夠資深
很多人會說，未來企業不用聘用傳統新人，只會聘用能跟 AI 協作的新人。
這句話只講對一半。
會跟 AI 協作的新人，當然比完全不會使用 AI 的新人更有優勢。但如果企業只是把新人訓練成 AI 操作員，讓他們負責產出更多初稿、更快把需求變成 code，這樣培養出來的人，可能很快變成中階工程師，但未必能變成真正的資深工程師。
原因很簡單：他們少了成熟過程中最重要的東西 : 透過試錯產生的經驗。
他們可能少了慢慢閱讀文件的耐心。
少了被 code review 打回來後，理解設計取捨的過程。
少了自己 debug 三天後，終於看懂系統的經驗。
少了 production 壞掉時，那種知道自己要負責的壓力。
少了親手處理資料錯亂、部署失敗、權限漏洞、效能瓶頸的記憶。
這些經驗不漂亮，也不有效率，但很重要，這是累積實作經驗的過程。
資深工程師不是靠看答案長大的，資深工程師是靠理解錯誤、承擔後果、修正判斷長大的。
真正要提醒自己的是「持續問為什麼」
AI 時代最有價值的工程師，不是最會下指令 (prompt) 的人，而是用了 AI 之後仍然持續問為什麼的人，因為這樣可以驗證答案並且知道答案怎麼來的。
例如，「要如何才能有較高的機率讓 AI 搜尋引用?」
AI 告訴我 : 「每頁有一個主要主題，不要一頁塞太多主題」。
我就覺得奇怪，不要塞太多主題的話，主題串的 Pillar Page 怎麼辦呢?
於是詢問後 AI 又告訴我 : 「不是指每頁只能談一個很窄的小問題，而是指每頁要有一個明確的核心搜尋意圖或核心語意主軸」。
那麼這樣就清楚了，原來不是「每頁只能有一個主題」，而是最好「每頁只有一個核心主題」。
例如，本篇文章的核心主題是 : 「AI 會不會取代工程師」，只要在這個核心主題內，以下都算屬於這個核心主題範圍。
「工程師使用 AI 應該注意什麼?」
「新手如果會使用 AI ，是否能夠取代資深工程師?」
「如果 AI 會取代工程師，還必要念電資科系嗎?」
因此「持續追問為什麼」並搞懂原因，是使用 AI 工具必要的態度，不然長久下來，你的能力會相對的逐漸退化。
AI 給你一段 code，你要問：為什麼它用這個資料結構？
AI 說這樣比較安全，你要問：它根據的是通用的安全建議，還是根據我們系統裡的現況？
這些問題，才是工程師從「解決問題」走向「累積經驗」的關鍵。
一份 2025 年針對 GitHub Copilot 在既有程式碼任務中的研究，也有類似提醒。研究中學生使用 Copilot 處理既有程式碼時，任務完成速度快了 35%，解題進度也提升；但訪談中，學生也表達了對於不理解 Copilot 建議如何運作、為什麼這樣運作的擔憂。
參考資料 : https://arxiv.org/abs/2506.10051
這個研究雖然樣本數不大，但它點出一個很實際的問題：AI 可以提高效率，但如果學習者沒有被要求解釋、驗證、反思，他可能只是更快完成任務，並沒有更深理解系統。
這也是為什麼「持續問為什麼」會變得如此重要。
可以這樣分辨一個人是真的資深，還是只把 AI 用得很熟
這張表不是要否定 AI，也不是要否定會用 AI 的工程師。
未來真正強的工程師，一定會善用 AI。但差別在於，他不會把 AI 當成權威，他會把 AI 當成一個很有用的助手，但是解答需要被質疑。
企業也要改變培養資深工程師的方式
這件事不只是工程師個人的問題，也是企業的人才培養問題。
如果企業只知道用 AI 取代初階任務，未來會出現人才斷層。因為以前新人就是靠修小 bug、補測試、讀舊 code、接小功能、被 review，慢慢長出工程判斷力。
但是如果企業雖然聘了新人，卻只讓新人用 AI 快速產出，不讓他們理解系統、不讓他們承擔責任、不讓他們經歷完整的上線與維護流程，也一樣培養不出真正的資深工程師。
比較合理的做法，是把 AI 納入訓練流程，但不要把學習責任交給 AI。
新人可以用 AI 寫初稿，但要能解釋每個重要決策為何這麼做。
新人可以用 AI 找 bug，但要能說出原因。
新人可以用 AI 補測試，但要能說明測試覆蓋哪些風險。
新人可以用 AI 做方案比較，但最後要由人承擔取捨。
Google Cloud 的 DORA ROI of AI-assisted Software Development 資源也提醒企業，不該只把 AI 導入視為削減人力，而是要把回收的工程產能，重新投資到減少繁重工作、改善流程與提升交付能力上。
這點很關鍵，如果 AI 省下的時間全部拿去塞更多需求，工程師會更忙，系統會更亂，團隊不會自己變得更成熟。
如果 AI 省下的時間被拿去做 code review、測試、自動化、文件、架構改善、技術債治理，工程師才有機會真正變強。
AI 不會讓你變資深，你要挑戰 AI 才會
AI 可以讓你更快完成任務，但資深工程師不是完成任務的機器而已。資深工程師要能看見任務背後的系統、風險、人、流程、歷史包袱與未來代價。
所以 AI 時代的工程師成長應該是：
不會用 AI 的工程師，會逐漸失去效率優勢。
只會用 AI 的工程師，會變成高產能但低判斷力的執行者。
會用 AI，又持續挑戰 AI 的工程師，才有機會變成真正可靠的資深工程師。
0 留言