AI 可以幫你 Coding，但不要把認知一起外包

最近看到 Lars Faye 寫的一篇文章 AI Coding will Prevent Expertise，我覺得寫得非常好。

原文： https://larsfaye.com/articles/ai-coding-will-prevent-expertise

它講到一個我最近也一直在想的問題。

現在 Claude Code、Codex 這類 Coding Agent 越來越強，我們都說工程師應該 move up the stack：

不要再把時間花在 syntax、boilerplate、手刻 API，implementation 可以交給 AI，人去做 architecture、review、judgment、decision。

這個方向我完全同意。

但問題是：

如果 architecture、review、decision 需要 expertise，那工程師到底要怎麼累積這些 expertise？

因為很多 expertise，偏偏就是從那些我們現在準備外包給 AI 的工作裡面長出來的。

我自己做軟體二十幾年之後，現在看到一些 code 或 architecture，有時候會很快覺得：

「這個東西之後應該會出事。」

可能 abstraction 過頭，可能 dependency 切錯，也可能現在看起來很漂亮，但 integration 或 debug 的時候一定很痛苦。

這種 engineering intuition 不是看書看出來的。

很多都是以前真的踩過坑、debug 過、做錯過，甚至做了兩個禮拜最後整個砍掉重來，才慢慢累積出來的。

Lars 在文章裡有一句我很喜歡：

Friction is a feature.

那些卡住、犯錯、debug、重寫，看起來很沒效率，但某種程度上，正是 expertise 形成的過程。

所以 AI Coding Agent 有一個很有趣的 paradox：

越資深的工程師，越能從 Coding Agent 得到巨大的 productivity gain。

因為他知道自己要什麼，也有能力判斷 Agent 給的答案到底對不對。

AI 幫他省掉 implementation effort，但沒有拿走他的 judgment。

可是 Junior Engineer 可能剛好相反。

以前遇到問題，要查 documentation、看 error message、試不同方法、debug 半天，最後才慢慢建立 mental model。

現在 Claude Code 三分鐘就把問題解掉了。

Test 也過了，功能也動了。

但有一個問題：

到底是他會了，還是 Claude Code 會了？

Anthropic 之前也做過相關研究。使用 AI 的工程師雖然工作完成得稍快，但之後對相關技術的理解與 debugging ability 反而比較差。

研究： https://www.anthropic.com/research/AI-assistance-coding-skills

不過重點不是「不要用 AI」。

真正的差別在於，你是在用 AI 幫助自己理解問題，還是直接讓 AI 取代理解問題。

所以我讀完這篇文章最大的結論是：

你可以把 Coding 外包給 Coding Agent，但不能把認知跟決策一起外包。

Mechanical work 本來就應該 offload。

CRUD、unit test、refactoring、查 syntax，AI 做得比較快，就讓它做。

但如果開始變成：

「為什麼要這樣設計？」 不知道。

「還有沒有別的方法？」 不知道。

「為什麼這個 dependency 放這裡？」 Claude 寫的。

那就不是單純的 Cognitive Offloading，而是在累積 Cognitive Debt。

Code 一直增加、ticket 一直 close、velocity 看起來很好，但團隊對系統的理解沒有跟著成長。

這件事情對 Engineering Manager 特別重要。

未來我不會太在意：

「這段 code 是不是你自己寫的？」

我反而更在意：

• 你知不知道為什麼這樣做？
• 你考慮過哪些 alternatives？
• Agent 給你這個 solution，你怎麼知道它是對的？
• 如果 production 出問題，你知道從哪裡開始查嗎？

換句話說：

Implementation 可以交給 Agent，但 ownership 不能交出去。

AI 可以幫我們少寫很多 Code。

但不要因為少寫 Code，最後連怎麼成為一個 Expert 都一起跳過了。