1983 年，認知心理學家 Lisanne Bainbridge 在期刊《Automatica》上發表了一篇只有五頁的論文，標題是〈Ironies of Automation〉，自動化的反諷。她談的是工廠和電廠的控制系統，這篇短文後來成為人因工程領域被引用最多的論文之一。
她指出的反諷是這樣的：系統設計者把能自動化的部分都交給了機器，剩下沒辦法自動化的，才留給人。結果留給人的，偏偏是最難的那部分：機器處理不了的異常狀況，要人接手。
但人平常已經不太動手了。日常的操作都由機器負責，人的工作變成在旁邊盯著，而長時間盯著一個幾乎不出錯的系統，本身就是人很不擅長的事。等到真正需要人接手的那一刻，那些很久沒練的技能，早就生疏了。
這個反諷，在 AI coding 上幾乎原封不動地重演。
讀陌生的程式碼、追一個 bug 的來龍去脈、決定資料結構怎麼設計，這些事越來越常交給 agent。它做得又快又好，人只要看結果、按下同意。日子一久，親手從頭追一個問題的次數越來越少。
然後某一天，agent 解不出來的那個 bug 出現了，或是一段沒人仔細讀過的程式在半夜出事。這時候需要的，正是一個能自己讀懂程式、能從錯誤訊息一路往回追的人。Day 18 談過，review 時要有人真的看懂改動；Bainbridge 會補一句：看懂也是一種技能，不練就會退步。
2026 年 1 月，Anthropic 發表了一個小型的隨機對照實驗。52 位大多是資淺的工程師，要學一個他們沒用過的 Python 非同步程式庫 Trio，一半的人可以用 AI 輔助，另一半自己動手寫。
做完之後立刻考一份測驗，考的是剛剛才用過的概念。AI 組平均 50 分，手寫組平均 67 分，差了 17 個百分點。差距最大的是 debug 類的題目，也就是判斷程式哪裡錯、為什麼錯的能力。至於速度，AI 組平均快了大約兩分鐘，但這個差距在統計上並不顯著。
研究團隊也寫明了這個實驗的限制：樣本不大，測的又是做完之後馬上的理解程度，長期的技能發展會不會受影響，這個研究沒有回答。所以它不是 AI 會讓人變笨的證據，比較像是一個警訊，而且跟 Bainbridge 四十多年前的推論方向一致。
這個實驗裡更有用的發現，是同樣用 AI，結果差很多。
分數高的那些人，會追問、會請 AI 解釋、會問觀念上的問題，有人也會在請 AI 寫程式碼的同時，要它說明為什麼這樣寫。分數低的那些人，則是把寫程式和 debug 整個交給 AI，自己很少思考。
差別不在有沒有用 AI，在於思考的那一步有沒有被外包出去。
Claude Code 內建了幾種輸出風格，可以用 /output-style 切換，其中兩種正好對應這個問題。
Explanatory 風格會讓 Claude 照常完成工作，同時在寫完程式碼的前後，加上簡短的說明區塊，講它為什麼這樣做：這個專案的慣例是什麼、為什麼選這個寫法。Learning 風格則更進一步，除了說明，還會刻意留一部分程式碼給人自己寫。
Learning 不是隨便挖空。例行的部分它自己完成；遇到真正需要做決定的地方，例如錯誤怎麼處理、資料結構怎麼設計、有好幾種合理做法的業務邏輯，它會在檔案裡留下一個 TODO(human) 的標記，說明已經完成了什麼、要寫什麼、該考慮哪些因素，然後停下來等人寫完。寫完之後，它會針對寫出來的程式碼給一段回饋，再繼續後面的工作。
這等於把 Bainbridge 擔心的那件事反過來設計：自動化照樣進行，但刻意把最需要判斷的那幾行留給人練習。代價是比較慢，回應也比較長，不適合每個任務都開。學新的程式庫、接手陌生的 codebase，或者單純覺得自己好一陣子沒親手寫程式的時候，切換過去用一陣子，是很便宜的練習方式。
Bainbridge 在 1983 年寫的是控制室裡的操作員。機器越可靠，他們越少動手；越少動手，真正出事時越難接手。她的結論並不是少用自動化，而是設計系統時，要記得人的技能也需要被維持。
AI 讓這個問題來到了寫程式的人身上。agent 越可靠，人越少親手寫、親手追；而那些只有人才能處理的時刻，並不會因此變少。工具已經能替人練習預留位置，要不要坐回那個位置上，還是人自己決定。
延伸閱讀
iThome鐵人賽
看影片追技術