The Human-in-the-Loop is Tired: The Psychological Toll of LLM-Assisted Programming

LLM-Assisted Programming Increases Work Intensity and Cognitive Fatigue

使用大型語言模型 (LLMs) 進行程式設計既能提高生產力，也會造成不穩定性。雖然 LLMs 可以快速生成大量程式碼，但它們將開發者的主要負擔從「創作」轉向了「監督」，導致了一種以高強度和滿意度降低為特徵的特定倦怠感。

這種轉變造成了「監督疲勞」，人類必須在審查大量大致正確但偶爾顯得荒謬的輸出時，維持系統的整體意圖與連貫性。糾正 AI 的錯誤——它可能會產生看似合理但無法在複雜變更中維持連貫意圖的程式碼——所帶來的認知負荷，往往超過了手動編寫程式碼的努力。

The Human Reward Function Problem

傳統的程式設計提供了一連串穩定的、由多巴胺驅動的小型獎勵：在腦中解決一個邏輯謎題、理解一段複雜的程式碼，或是看到程式第一次成功編譯。LLM 輔助的程式設計將這些令人滿足的里程碑自動化了，取而代之的是令人精疲力竭的審查任務。

這種現象被稱為 human reward function problem。在機器學習中，獎勵函數定義了什麼是「好」；對於人類開發者而言，「獎勵」則是發現與控制的過程。當這個過程被自動化時，令人滿足的工作部分縮減了，而品質保證的認知負荷卻增加了，導致工程領域的情感獎勵週期出現了缺口。

The Shift from Creator to Quality Gate

隨著生成程式碼的成本趨近於零，開發者的價值從編寫語法的能力轉向了行使使判斷的能力。軟體工程的瓶頸不再是程式碼本身，而是人類的注意力與工程判斷力。

The Evolution of Craft

這種轉變反映了 2000 年代後期從固定寬度到響應式網頁設計的轉變。正如設計師必須從像素級的精確控制轉向為流動系統與不確定性進行設計一樣，現代工程師必須從逐行控制轉向系統層級的編排 (orchestration) 。如此，核心技能——品味、細微差別與架構觀點——變得更加關鍵，因為開發者現在是面對大量輸出時唯一的品質把關者。

Emerging Strategies for AI Orchestration

經驗豐富的開發者正在演進其工作流程以應對這種新的強度：

• Pre-mortems: 使用一個全新的 LLM 會話來假設一個複雜的計畫已失敗，並診斷失敗原因以捕捉規格說明書的缺口。
• Knowledge Distillation: 將多年的隱性判斷編碼成結構化指令（例如 AGENTS.md 檔案），以更有效地引導 AI agents。
• Iterative Planning: 避免「agentic」的一次性嘗試，轉而採用「計畫、執行小步驟、並在繼續下一步之前審查每個步驟」的緊密循環。

Community Perspectives and Counterpoints

雖然許多開發者回報說，他們對提示詞 (prompting) 的「老虎機」性質感到精疲力竭，但其他人則發現這種轉變是解放性的。LLMs 的影響似乎很大程度上取應決於開發者的類型 (archetype) ：

"Some will find their joy through building fast, through building fast, they tend to
build LLMs. Some love the art of writing code; they don't tend to love LLMs... LLMs make some developer archetypes more effective and others more exhausted."

有些開發者認為 AI 移除（或說）了語法與導航的「瑣事」 (drudgery) ，讓他們能完全專注於高層級的架構設計。其他人則指出，程式設計的社交面向正在侵蝕，因為與同事進行「橡皮鴨除錯法」 (rubber-ducking) 的自然衝動被另一個對機器的提示詞所取代，增加了專業上的孤立感。

最後，有些觀察者指出責任歸屬的轉變變。在某些工作場所，「human-in-the-loop」一詞正在被「human on the hook」一詞取代，反映出一個現實：人類不再是過程中的協作者，而是當 AI 生成的輸出在生產環境中失敗時，承擔唯一責任的一方。