AI 與程式設計難度的轉變

從回憶到判斷的轉變

AI 不一定讓程式設計變得更容易，但它根本改變了難度所在的位置。軟體開發的主要挑戰已從 recall （知道如何寫特定函式或記住語法）轉移到 judgment （判斷生成的程式碼是否正確、安全且架構合理）。

雖然 LLMs 能快速生成樣板碼並解決孤立問題，但驗證的負擔現在完全落在人類開發者身上。這產生了一種新的認知負荷，開發者必須充當持續的審查者，對機器生成的輸出進行一系列關鍵決策，而不是從零開始構建邏輯。

AI 輔助編程中的經驗悖論

在程式設計中有效使用 AI 需要深厚經驗的基礎，而 AI 本身可能會阻礙新開發者獲取這種經驗。要評估 AI 生成的程式碼是否「makes sense」，開發者必須先理解只有透過多年手動編碼才能獲得的權衡與失效模式。

社群見解指出此轉變帶來的幾個風險：

• 進步的幻覺： AI 可以作為生產力倍增器，讓開發者在未意識到的情況下快速朝錯誤方向前進。
• 見解的侵蝕： 類似於 AI 生成的文字，AI 生成的程式碼在表面上可能看起來連貫，但缺乏真正的架構見解，使得編輯或維護變得困難。
• 維護債務： LLMs 生成的程式碼隨時間可能變得更多錯誤或難以理解，導致當原始作者不再理解他們委託給機器的底層邏輯時產生遺憾。

"要評估它是否有意義，你首先需要編寫程式碼的經驗…… AI 是一種超能力，但如果沒有經驗來引導它，它可能會很快地出錯。"

認知疲勞與 "決策負擔"

使用 AI 編程會引發一種特定的精神疲勞形式，其特徵是持續的決策過程。與積極編寫時獲得的流暢狀態不同，開發者現在必須面對一連串需要持續驗證的複雜計畫與建議。

此現象被比喻為「土豆分類」問題：而 AI 能處理大量重複性任務（如劈柴或修補籬笆），人類則被留下持續的分類任務——決定什麼保留、什麼播種、什麼丟棄。從 創建 到 策展 的這種轉變可能比傳統開發更耗費精力。

對生產力與架構的不同觀點

人們對 AI 是否真的「移動」了難度，或僅僅揭示了軟體架構固有的難度存在顯著爭議。

AI 作為效率工具

一些開發者主張，AI 通過移除語法障礙，客觀上讓程式設計變得更容易。透過自動化「簡單部分」（編寫程式碼），AI 讓開發者能完全專注於高層意圖與系統設計。從這個角度來看，透過提示生成可執行程式的能力是生產力的淨增益，不管監督需求增加與否。

程式碼作為真實的首要性

「AI-first」方法的批評者認為，雖然提示和計畫是有用的工件，但程式碼仍然是唯一的具體真相。因為 LLMs 缺乏真實語義且無法以 100% 確定性執行邏輯，最終輸出必須被視為需要嚴格人類驗證的商品，以確保它不僅是一個運作系統的「幻覺」。

經濟現實

一些觀察者指出，雖然 AI 提高了個人生產力，但該效率的價值常被市場而非勞工所捕獲。更快完成更多工作的能力不一定會減少工作量；它只是提高了在競爭環境中所預期的基準線。