技術經驗的貶值不是 AI 的問題，是我們問錯了問題

AI 不是讓技術經驗貶值，而是暴露了我們一直把「寫程式碼」當成經驗的誤解。真正值錢的從來是判斷，不是執行。

15 3月 2026 • 5 min read

Dropbox 前 CTO 說的其實不是新聞

Aditya Agarwal 最近的文章在技術圈引起不少迴響——他說自己花一輩子累積的程式開發能力，現在變得隨手可得又不值錢。這話聽起來像是在說 AI 改變了遊戲規則。但我讀完以後的感覺是：他說的不是 AI 的問題，而是我們對「技術經驗」的定義一直就有問題。

程式開發能力平民化這件事，本身沒有什麼驚人的。GitHub Copilot、Claude 這些工具確實降低了「寫出能跑的程式碼」的門檻。但這個門檻本來就不高。真正的問題是：我們一直把「能寫程式碼」當成技術經驗的核心，而實際上它只是冰山一角。

變便宜的東西很明確：

這些工作在 2015 年值錢，現在確實不值錢了。一個剛畢業的人用 AI 可以做得跟有十年經驗的人一樣快。這是事實，也沒什麼好否認的。

但這只是技術工作的一部分。而且可能是最不重要的部分。

我的觀察是反向的：真正有經驗的人現在更值錢。

因為現在的問題不再是「怎麼寫」，而是「寫什麼」和「為什麼這樣寫」。

你需要判斷：哪個框架對這個問題真的有幫助，哪個只是時髦。你需要預見：這個架構決定三年後會不會成為瓶頸。你需要知道：為什麼某個看起來簡單的需求，實際上隱藏著複雜的權衡。你需要從失敗的經驗裡學到：什麼時候應該堅持，什麼時候應該改變。

這些東西 AI 給不了。不是因為 AI 還不夠聰明，而是因為這些判斷本身就建立在「見過什麼」和「踩過什麼坑」之上。

我猜他的不安全感來自一個假設：如果寫程式碼不再稀缺，那麼寫程式碼的人就不稀缺。

但這個邏輯有問題。

Dropbox 成功不是因為他們的工程師寫程式碼的速度快。成功是因為他們在 2008 年判斷對了「雲端檔案同步是一個值得做的問題」，然後在技術和產品上做對了一系列決定。現在 AI 可以幫助他們寫程式碼，但無法幫助他們做出那些判斷。

如果一個有十年經驗的技術 leader 和一個新手同時用 AI 寫程式碼，快速度可能一樣。但他們做出的架構決定、技術選型、風險評估會完全不同。前者的決定可能讓公司省下千萬級別的基礎設施成本，後者的決定可能讓公司三年後陷入技術債地獄。

這個差異不會在速度上體現，會在後果上體現。

如果寫程式碼這件事被 AI 加速了，那麼經驗的來源就必須改變。

你不能再靠「寫很多程式碼」來積累經驗。因為那個過程被壓縮了。你必須靠「看很多設計決定的後果」和「參與很多系統的演進」來積累經驗。

換句話說：你需要更快地接觸不同的問題、不同的團隊、不同的失敗案例。你需要從一個系統的第一行程式碼看到它五年後的樣子。

這對年輕工程師其實是機會。以前你可能需要十年才能看到足夠多的架構決定的後果。現在因為寫程式碼不再是瓶頸，你可能五年就能看到。前提是你在乎看，而不是只在乎寫。

對資深工程師也是機會。你們的經驗突然變得稀缺了，不是因為 AI 的威脅，而是因為 AI 把低價值的工作清除了。現在公司更需要你們做判斷，而不是做執行。如果你習慣了在執行中找成就感，這會很難受。但如果你習慣了在判斷中找成就感，這是一個升級。

Agarwal 說的「不值錢」，其實反映的是一個職業身份的危機。如果你的身份是「會寫程式碼的人」，那麼確實有危機。但如果你的身份是「能做出好決定的人」，危機就變成了機會。

這不是 AI 改變的問題。這是你怎麼看待自己的問題。

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。