AI 都會 coding 了，我為什麼還要學程式？真正稀缺的是理解 system

AI 讓「寫出 code」變得愈來愈便宜，但這不代表「理解 software」也跟著變便宜。

如果你最近看過 coding agents 寫 feature、修 bug、補 tests，甚至一次修改整個 codebase，很容易冒出一個合理的問題：

AI 都會 coding 了，我為什麼還要學程式？

我覺得這個問題問得很好。

因為如果「會 programming」只代表記 syntax、背 API、手動打一堆 boilerplate，那其中很大一部分工作，確實正在快速變得不稀缺。

但 software engineering 從來不只是把 syntax 打進 editor。

真正困難的問題通常是：

• 你到底想讓 system 做什麼？
• 需求裡有哪些還沒說出口的 constraints？
• AI 產生的 code 到底有沒有符合真實 business rule？
• 當它在 edge case、security boundary 或 production 才壞掉時，你看得懂發生什麼嗎？
• 你能不能驗證、修改、接手，而不是只能再問一次 AI？

所以我現在比較喜歡把問題改寫成：

當 code 幾乎可以免費生成時，什麼 programming capability 反而變得更重要？

Productivity 變高，不等於 programming capability 也一起成長

目前關於 AI coding 的 evidence，其實比「AI 讓 programmer 快很多」或「AI 讓 programmer 退化」都更複雜。

2025 年一篇整合 35 個 controlled studies 的 systematic review / meta-analysis 發現，AI-assisted programming 整體上可以提高學生的 programming performance；但在 learning success / ease of understanding 上，並沒有穩定的顯著優勢，而且不同研究之間差異很大。

2026 年 Technical University of Munich 一個 N=275 的 introductory programming RCT 又看到一個更直接的現象：使用 scaffolded AI tutor 或 unrestricted ChatGPT 的學生，在 programming exercise 上都比 no-AI control 做得更好，frustration 也更低；但 pre–post conceptual learning 與 code comprehension 並沒有因此更高。

這和我前一篇談的 Performance ≠ Learning 是同一個問題，只是 programming 把它變得更具體。

能產生更好的 code，和你是否更能理解、debug、verify 一個 software system，是兩件不同的事。

1. Code 是 answer；Specification 才是 problem

「幫我做登入」看起來像一個清楚的 request。

但真的開始做之後，問題立刻變成：

• 誰能登入？
• session 怎麼管理？
• password reset 呢？
• OAuth 呢？
• rate limiting？
• account takeover？
• privacy？
• audit log？
• edge cases？
• 失敗後怎麼 recover？

AI 很擅長回答一個已經說清楚的 programming request。

但真實世界最稀缺的，往往就是把模糊需求變成一個可以安全實作的 specification。

一個 novice 看見「做登入功能」。一個更有經驗的 engineer 看見的是一整個 constraint network。

2. 能 Generate，不代表能 Verify

AI coding 最重要的不對稱之一，是 generation 可以非常快，但 verification 不會自動一起變快。

一段 code 能跑，不代表它：

• edge cases 正確；
• 沒有 security vulnerability；
• scale 後仍可接受；
• 不會破壞既有 behavior；
• 符合 privacy constraints；
• 真正符合 business rule；
• 未來仍可維護。

如果 AI 一次生成一千行 code，而我們只能用「看起來合理」來驗證，那 productivity gain 很容易同時變成一種 verification debt。

真正的 debt 不是「我沒有逐行讀完」。

而是：system complexity 增長得比我的 causal understanding 更快。

3. 未來更值得學的是 computation 的 structure

Languages、frameworks、APIs 都會一直變。

更 durable 的東西是：

• state 如何改變；
• data 如何流動；
• abstraction 如何隱藏 complexity；
• interface 如何劃分 responsibility；
• algorithm 的成本怎麼隨 input 成長；
• concurrency 為什麼會產生 race condition；
• distributed systems 為什麼不能假設每件事都同時成功；
• tests 能證明什麼、不能證明什麼；
• failure 如何 propagate；
• security boundary 在哪裡。

這些不是 syntax trivia。

它們是你用來理解 AI-generated code 的 computational mental models。

4. Debugging 可能比「從零打 code」更能代表未來的 programming literacy

真實工程常常不是「請你從零寫一個 function」，而是：

為什麼這個 system 在 production 偶爾壞掉？

Debugging 要求你提出 hypothesis、找 evidence、縮小 search space、理解 state、重建 causal chain。

AI 當然可以讀 logs、解釋 stack trace、提出可能原因。但如果 learner 每次都只把 error 貼給 AI，再把 patch 貼回去，他可能永遠沒有練到最值得留下的 cognition。

我現在很喜歡一個極小的 practice：

問 AI 以前，先寫下：我現在認為 bug 最可能在哪裡？什麼 observation 會支持或反駁這個 hypothesis？

只多花幾十秒，但它保留了 debugging 裡最重要的 scientific reasoning loop。

5. 同一個 shortcut，對 expert 是 leverage，對 novice 可能是 missing curriculum

一個資深 engineer 讓 AI 產生 boilerplate，和一個還沒有任何 mental model 的 beginner 讓 AI 完成整個 project，看起來都是「AI coding」。

但 cognitive consequence 完全不同。

Expert 已經 internalize 大量 patterns、failure modes 與 standards。他可以高速 scan code、察覺 anomaly、要求 architecture changes，也比較知道什麼值得測。

Novice 還在建立這些 structures。

所以我不覺得答案是「初學者不要用 AI」。

更合理的做法是：讓 assistance 隨 expertise 與 learning target 改變。

如果今天練的是 decomposition，就不要讓 AI 一開始把 decomposition 全部做掉；如果練的是 debugging，就不要永遠讓它直接給 patch；如果已經熟悉基本結構，就可以讓 AI 承擔更多 repetitive implementation。

6. Productivity evidence 本身也提醒我們：不要把 AI coding 想成一個單一效果

AI coding 對專業開發工作的 productivity，也沒有一個適用所有情境的簡單數字。

Microsoft Research 2025 年整合 Microsoft、Accenture 與一家 Fortune 100 公司的三個 field experiments、共 4,867 名 developers，估計 AI coding assistant 讓 completed tasks 增加約 26%，而較缺乏經驗的 developers adoption 與 gains 更高。

但 METR 在 2025 年針對熟悉自己大型 open-source codebase 的 experienced developers 做 RCT 時，早期 AI tools 反而讓完成時間增加。METR 到 2026 年又看到 newer tools 可能已轉向小幅 speedup，但研究者明確提醒 selection effects 很嚴重，無法可靠估計現在真正的 speedup。

這些結果並不互相矛盾。

它們提醒的是：AI coding 的價值取決於 task、codebase、developer expertise、tool capability、workflow 與 evaluation protocol。

也因此，「AI 已經能 coding」本身不足以回答「人還要學什麼」。

7. 我會怎麼學 programming in the age of AI？

如果今天重新開始，我不會用兩個極端：

• 「什麼都不能用 AI，全部手刻才算學習」；
• 「既然 AI 都會寫，就不用理解 code」。

我會比較像這樣：

1. 先 prediction：在問 AI 前，先寫出你覺得程式會怎麼跑、bug 可能在哪裡、solution 大概怎麼拆。
2. 再 assistance：讓 AI 給 hint、比較方案、產生 repetitive code，或挑戰你的 model。
3. 要求 explanation：不是只拿 patch，而是把主要 state / control flow / trade-off 說清楚。
4. 主動 inject error：故意改壞一段 code，看自己能不能找到原因。
5. 減少 assistance：同類 task 下一次少給一些 context，確認能力不是綁在同一個 prompt。
6. 換情境 transfer：不要只重做一模一樣的 exercise，換 codebase、requirement、bug type。

這樣 AI 就不只是代寫工具，而是 learning scaffold。

未來的 programmer 可能寫更少 code，卻需要理解更多 system

我不認為 programming 的價值會因為 AI 能生成 code 就消失。

比較像是它的中心正在移動：

• 從 syntax → specification；
• 從 typing → architecture；
• 從 implementation → verification；
• 從「能不能寫出來」→「知不知道什麼值得寫、怎樣才算正確」。

所以真正值得問的不是：

AI 都會 coding 了，我還要不要學寫 code？

而是：

當 code 幾乎可以免費生成時，我需要具備什麼能力，才能安全地指揮、理解、驗證並改進一個由人與 AI 共同建立的 software system？

那個答案，仍然需要 programming literacy。

只是它愈來愈不像「誰能最快把 code 打出來」，而更像「誰真正理解 system」。

研究與延伸閱讀

• Nathaniel et al. (2025). Literature Review on the Integration of Generative AI in Programming Education.
• Alanazi et al. (2025). The Influence of Artificial Intelligence Tools on Learning Outcomes in Computer Programming.
• Bassner et al. (2026). Less stress, better scores, same learning.
• Cui et al. (2025). The Effects of Generative AI on High-Skilled Work.
• METR (2026). We are Changing our Developer Productivity Experiment Design.

Boundary note：這些研究來自不同 populations、tasks 與 outcome measures。本文不主張 AI coding 一定提升或傷害 programming ability；較穩健的結論是，performance / productivity 與 durable capability 必須分開測量，而 AI assistance 應該依 learner stage、task 與 learning target 設計。

延伸閱讀

• AI 幫你做到，不代表你已經學會 — 從 learning science 理解 performance 與 durable capability 的差別。
• AI-native delivery：速度不等於完成 — 從真實產品交付看 generation、verification、authority 與 release。