初階開發者可以請 AI 助理使用不熟悉的程式庫，取得可運作的程式碼後繼續下一項工作。功能可能已經完成，開發者卻還不明白它為何能運作。下次程式出錯、需求改變，或有人必須判斷助理提出的修正是否安全時，這就很重要。
軟體工程師 Alexandru Nedelcu 在一篇 9 月 22 日的文章中提出這項疑慮。他認為，開發者透過閱讀程式碼、做出選擇並承擔錯誤，逐步培養判斷力。他預測某些公司會宣傳禁止使用 AI 的政策；這是他的看法，不是已觀察到的產業轉變。一項 1 月發表的獨立實驗，則將學習問題縮小為可測試的形式：程式設計師使用 AI 完成任務後，當下理解了多少？ Anthropic 的研究說明
重大變化
- 改變了什麼：AI 讓人更容易提交完成的軟體，卻未必親自理解其邏輯。它可以在新手尚未練習解釋或修復所需判斷前，就提供一套實作。
- 為何重要：管理者今天可能增加產出，卻削弱初階員工成為未來故障診斷者的培養途徑。任務涉及不熟悉概念時，風險尤其明顯；對熟悉工作提供協助仍可能有價值。
- 值得觀察：團隊可能開始將學習視為交付的一部分，預留時間解釋、診斷與調整 AI 輔助工作。若採取這種作法，招募測驗與程式產品或許會在速度之外，也評量已展現的理解能力。
完成任務與學會技能，是兩種不同成果
在 一項對 52 名程式設計師進行的隨機研究中，參與者使用一套不熟悉的 Python 程式庫 Trio 完成兩項程式任務。一半的人可在程式環境中使用 AI 助理，另一半則不能。他們事先知道之後會有測驗；測驗在任務完成後不久進行，內容涵蓋概念、程式碼閱讀與除錯。
AI 組平均得分為 50%，沒有使用 AI 的組別則為 67%：差距是 17 個百分點，不是相對下降 17%。除錯題的差距最大。AI 組平均快約兩分鐘完成，但時間差異未達統計顯著。這些結果來自短暫接觸一套程式庫並立即測驗，並非對開發者職涯或正式環境系統品質的衡量。 研究結果與限制
研究人員也觀察參與者如何使用助理。有些人幾乎把程式撰寫與除錯都交給助理；另一些人會要求解釋或親自推理概念。較投入的使用模式往往得分較高，但這些小組是事後才區分的。參與者是隨機分配能否使用 AI，而不是分配特定的互動方式。要求助理解釋或許能幫助學習者，但此研究無法證明某種提示或工作流程可以避免學習落差。 論文中的互動分析
錯誤常是新手了解程式庫預設行為的時刻。如果助理連最初實作與後續修復都一併處理，開發者可能較少遇到這些預設。這是除錯能力出現落差的一種可能解釋。
速度仍重要，任務不同，答案也不同
在其他條件下，AI 協助也能加快程式開發。在 一項受控的 GitHub Copilot 實驗中，95 名專業自由工作者被分配製作一個 JavaScript HTTP 伺服器。在完成任務的人當中，Copilot 組平均約花 71 分鐘，對照組則約 161 分鐘，完成時間減少 55.8%。研究人員沒有測試參與者事後學會了什麼。該任務是一項範圍明確的實作，並非使用不熟悉的程式庫後再接受理解測驗。
兩項研究都能為管理者提供參考。如果有經驗的開發者使用 AI 清理重複工作，節省時間可能是真實的；若任務重點是學習新系統，就應分別檢查產出速度與理解程度。全面禁止 AI 可能會捨棄潛在收益，卻仍沒有回答人們如何學會監督這些工作。
Nedelcu 的文章提出了比實驗更進一步的主張。他認為，可維護性要經過數月或數年才看得出來，而承擔錯誤責任有助累積經驗。研究沒有衡量長期可維護性，也沒有證明 AI 使用者會完全停止學習。他提出的實用挑戰在於組織安排：如果團隊愈來愈常把練習工作交給 AI，未來的疑難排解人員要從哪裡取得練習機會？ Nedelcu 的文章
讓學習者在程式運作後證明自己理解
一種實際作法是，先交給新手一項由 AI 協助的任務，再於認定學習成功前，要求他們獨立完成簡短檢核。這是我們提出的練習方式，不是任一研究測試過的介入方法：
- 解釋：不詢問助理，說明程式中不熟悉的部分為何能運作、依賴哪些假設，以及在什麼情況下會失敗。資深工程師可針對實際變更追問一個問題。
- 診斷：在安全的測試分支中引入一個小而實際的故障。請學習者找出原因，並說明哪項觀察排除了看似合理但錯誤的修正方向。重點在推理，不是背誦指令。
- 調整：變更一項需求，再請學習者修改實作及測試。他們可以使用 AI，但應能說明新行為的理由，並指出還需要驗證的事項。
例如，助理寫出新的非同步操作後，審查者可以問：若操作進行到一半時遭取消，會發生什麼事？開發者應能追蹤執行路徑並測試需求變更。單靠程式碼審查可能抓出缺陷，卻無法確認學習者能否處理下一個問題。這項檢核要確認的是，知識是否隨交付的程式碼一同保留下來。
不必把每張例行工單都變成考試。團隊可將這項練習保留給涉及不熟悉程式庫、反覆故障模式，或預期初階同事日後要負責的工作。這需要有薪工時，以及熟悉系統的審查者。如果管理階層只計算合併的任務數與節省的時間，這些成本可能最先被刪減。即使今天的產出上升，這也會讓培訓問題更棘手。
師徒培訓的問題也延伸至招募與產品設計
初階職位往往同時包含交付工作與受監督的練習。當求職者可以展示令人印象深刻的完成品，卻不必展現自己的推理過程，AI 就改變了這種安排。雇主可以要求求職者解釋並修改一小段工作內容，而不是把精美的程式碼儲存庫當成具備獨立技能的證明。這是提出的招募作法，不是目前招募趨勢的證據。測試應符合職位實際需要的能力，而非要求每位申請者都不得使用工具。
程式產品也面臨類似選擇。助理可以追求快速給出答案，也可以讓使用者更容易檢查假設、提出概念問題，並在看到解答前先試著修改。研究中觀察到的互動模式，讓後一種設計值得嘗試，但尚未證明某種介面能帶來更好的學習。對雇主而言，相應的採購問題是：工具能否幫助員工學會審查與修改輸出，而不只是產生多少程式碼？
短期測驗無法告訴我們誰會在五年後成為專家，但它說明，在不熟悉的任務中，僅有一份獲接受的實作並不足以證明理解。想同時運用自動化並培養下一代人才的團隊，必須留出練習空間，並檢查需求改變時人們能做些什麼。
