AI 輔助開發工具與 AI 代理日益普及，程式碼生成變得更加便利，但長期依賴自動化工具，也引發開發者獨立撰寫與理解程式碼能力可能逐漸退化的疑慮。針對這項問題，來自印度邦加羅爾（Bengaluru）的開發者 Ashutosh Rath 打造命令列（CLI）工具 Atrophy，試圖讓使用者在技能退化變得難以逆轉前，及早發現需要加強的領域。
五大核心能力分開追蹤
Atrophy 將程式設計能力拆分為五個領域，並對每項能力進行獨立評估與計分：
- 語法記憶（Syntax recall）：根據指定規格，要求使用者從零開始撰寫符合條件的小型函式。
- 除錯能力（Debugging）：分析看似正常但實際上隱藏 Bug 的程式碼，測試使用者找出問題並完成修復的能力。
- 程式碼閱讀（Code reading）：不依賴電腦執行程式，直接在腦中模擬程式碼流程並推導最終結果。
- API 記憶（API memory）：針對標準函式庫的呼叫設計題目，要求使用者填寫程式碼中的空白部分。
- 架構拆解（Decomposition）：評估使用者從宏觀角度規劃系統，以及將整體程式架構拆分為可執行工作的能力。
Python 與 JavaScript 支援隨機變化題
目前 Atrophy 的練習內容涵蓋 Python 與 JavaScript，並分為三個難度等級。工具採用隨機種子生成（Seeded generation）機制，讓每次練習都能產生不同變化的題目，降低使用者因重複作答而只靠記憶答案過關的可能性。
使用者首次使用時，必須完成基準測驗，五個技能領域各回答一題。Rath 估計整份測驗約需 25 分鐘；完成後，他建議每週練習兩至三次，每次約 5 至 10 分鐘。系統會優先選出使用者最久未練習的技能領域，並為題目設定軟性時間限制。即使超過時間仍可能通過，但可取得的分數增幅會相應降低。
類 Elo 評分，觀察能力變化趨勢
Atrophy 的評分系統參考西洋棋 Elo 等級分制度，但並未完全照搬。五個技能領域各自計分，初始分數均為 1,200 分，且沒有硬性的最高或最低分數限制。Rath 表示，系統會在每次練習後以類 Elo 公式動態調整分數，早期練習對評分的影響幅度較大，後期則會逐步降低。
如果使用者長時間沒有使用 Atrophy，系統對評分準確性的信心水準會下降，但不會因此直接扣分。這項設計意在區分「能力可能改變」與「系統缺乏近期資料」兩種情況。
Rath 另外建議使用者每月進行一次 AI 輔助練習。這類測驗的分數會獨立記錄，用來比較使用 AI 與不使用 AI 時的表現差異，讓使用者觀察自己對 AI 的依賴程度是否隨時間增加。
工具定位不是反對 AI
Rath 強調，Atrophy 的練習結果只是實際技能的替代指標，分數不應被視為個人程式能力的絕對衡量標準。對他而言，工具的主要價值在於呈現一段時間內的變化趨勢，協助開發者找出可能正受到 AI 影響的技能領域。
Rath 也表示，Atrophy 並不是要反對 AI，而是希望衡量兩種狀態之間的差距：開發者在 AI 協助下能完成什麼，以及在完全依靠自己時仍能完成什麼。他認為，獨立寫程式的能力可能在沒有明顯警訊的情況下逐漸生疏，因此有必要透過定期測試建立可觀察的紀錄。
研究顯示 AI 輔助可能影響認知投入
對 AI 依賴可能造成能力退化的擔憂，也有學術研究提供部分佐證。麻省理工學院（MIT）去年發表的研究指出，使用生成式 AI 聊天機器人協助寫作的學生，大腦活動量明顯低於未使用 AI 的學生，且在事實記憶與內容回想方面表現較差。
相關結果被解讀為，過度依賴 AI 可能導致較為「淺層編碼」的學習方式，並在離開 AI 代理後降低獨立完成工作的能力。不過，這類研究主要聚焦於特定的寫作任務與受試情境，不能直接等同於所有程式開發工作都會產生相同影響。Atrophy 的設計則是透過持續測驗，讓使用者自行觀察個人能力變化，而非宣稱單一分數能完整代表工程能力。
在便利與基本功之間建立可見差距
隨著 AI 代理逐漸參與需求理解、程式碼生成、除錯與重構，開發流程正從逐行撰寫轉向更高層次的指揮與審查。這種轉變可能提升生產力，但也使部分基礎技能較少被直接使用。Atrophy 嘗試以短時間、分領域的練習，將「AI 輔助下的表現」與「獨立完成任務的能力」分開記錄，提供開發者另一種檢視自身技能狀態的方法。
