開發者的工作從親手撰寫程式碼，轉向帶領 AI 代理、守住品質，並且設計讓 AI 能穩定工作的環境
週五傍晚，Kevin 照例回顧這一週合併進主線的程式碼。他在一個電商平台負責訂單與金流相關的服務，做了五年後端。這次他特別算了一下，發現這一週合併的程式碼裡，大約八成是 AI 代理產生的，他親手敲出來的部分，主要是幾處關鍵邏輯的修正。那一刻他有點恍神：這一週明明很忙，但自己到底在忙什麼？
這樣的感受，在許多工程團隊裡越來越普遍。程式碼審查花掉的時間，開始超過撰寫的時間；任務說明寫得好不好，比打字速度更影響產出；以前覺得麻煩的測試與文件，突然變成大家搶著補的東西。工程師的一天，正在被重新排列。
一個反直覺的問題因此浮現：當 AI 寫程式比人還快，工程師的價值還在寫程式嗎？價值依然和程式碼緊緊相連，但重心已經從「寫出來」移到「確保寫出來的東西是對的」，以及「讓 AI 有能力寫對」。
在 AI-native 的開發團隊裡，開發者的角色正從程式碼的撰寫者，轉為 AI 代理的帶領者、程式庫環境的設計者，以及系統品質的最終把關者。
一週的程式碼，八成來自 AI 代理
Kevin 回想這一週的時間分配：週一花了一個早上，把一個退款流程的需求拆成六個小任務；接下來幾天，他輪流交代 AI 代理處理這些任務，自己則在審查產出、修正細節、和產品經理確認邊界情況之間來回切換。真正長時間專注寫程式的時刻，只有週三處理一個金額計算的錯誤。
這種工作方式，一開始讓他覺得自己像在當監工，少了那種把問題一路解到底的成就感。後來他慢慢發現，成就感換了來源：一個早上拆好的任務，三天內就能變成完整的功能；過去要兩週的退款流程改版，這次一週就上線了。工作的手感變了，但對結果的掌握反而更多了。
給合作夥伴的提醒是：工程師現在常常看起來「沒有在寫程式」，可能正在做更關鍵的事。他們審查的速度與判斷，決定了 AI 產出的程式碼能不能放心上線。
帶 AI 代理工作，是一門新手藝
Kevin 剛開始用 AI 代理時，常犯一個錯誤：把整個需求一次丟過去。結果代理寫出一大包程式碼，看起來都能跑，細看卻到處是隱藏的問題，審查起來比自己寫還累。
幾個月下來，他整理出幾條心得。第一，任務要切到審查一次就能看完的大小，大約是一個小時能讀懂的範圍。第二，交代任務時要給足脈絡：相關的模組在哪裡、有哪些既有的慣例、哪些地方絕對不能動。他習慣寫一段簡短的任務說明，包含目的、範圍、驗收方式三個部分。第三，審查時先看測試，再看邏輯，最後才看風格；測試沒過或根本沒寫的，直接退回去。
帶領 AI 代理的能力，很像帶領一位聰明但不熟悉環境的新同事：說清楚目的、切好範圍、檢查成果。資深工程師過去帶新人的經驗，在這裡意外地派上用場。
另一個容易被忽略的問題是審查疲勞。同時讓三四個代理平行處理任務，產出的速度很驚人，但到了下午，Kevin 發現自己開始只看程式碼「長得像不像對的」，細節越看越鬆。他後來替自己訂了規矩：同時進行的任務不超過三個，關鍵模組的審查一律安排在上午精神最好的時候。AI 的產出可以無限加速，人的專注力卻有上限，帶領代理的節奏，要配合自己能好好審查的速度。
明天就能嘗試的做法：下一次交給 AI 的任務，先寫三句話說明目的、範圍與如何驗收，比較一下產出品質與審查時間的差異。
讓程式庫成為 AI 讀得懂的地方
Kevin 注意到，同樣的 AI 代理，在不同模組裡的表現差很多。在訂單模組裡，它幾乎每次都能寫對；在三年前留下來的優惠券模組裡，卻常常寫出和既有邏輯衝突的程式碼。差別在哪裡？訂單模組有完整的測試、清楚的命名，還有一份說明架構決策的文件；優惠券模組什麼都沒有，所有規則都藏在當年那位工程師的腦袋裡。
他開始每週挑一個模組，補上三樣東西：一份簡短的說明文件，寫明這個模組負責什麼、有哪些不能違反的規則；一組涵蓋關鍵情境的測試；以及把幾個意義不明的變數與函式重新命名。補完之後，AI 在這些模組裡的錯誤明顯減少，新進同事看懂程式的時間也縮短了。
過去被視為「有空再做」的測試與文件，現在直接決定了 AI 能發揮多少效果。程式庫的整潔程度，變成整個團隊開發速度的上限。
他也開始記錄架構上的重要決策。例如訂單狀態為什麼只能單向變化、為什麼退款要拆成兩個步驟，這些當年在會議裡討論出來的結論，過去只存在少數人的記憶裡。寫成短短幾行說明之後，AI 不再提出違反這些原則的修改，團隊也少了很多重複的討論。
明天就能嘗試的做法：挑一個 AI 最常寫錯的模組，替它補上一頁說明文件，列出三條最重要的規則，觀察接下來的產出變化。
前後端的界線變淡之後
Annie 入行一年，是前端工程師。過去她做的功能，只要碰到資料庫或新的 API，就得在團隊頻道裡等後端同事排時間。這陣子，她開始在 AI 代理的協助下，自己寫簡單的 API 與資料查詢，一個商品比較功能從畫面到後端，她一個人一週內就完成了。
Kevin 也反過來嘗試。他過去從不碰畫面，現在會順手調整後台管理介面的操作流程，因為 AI 處理了大部分的樣式細節，他只需要專注在操作邏輯是否合理。
前後端界線變淡，帶來的好處是一個人能負責一整個功能切片，等待與交接大幅減少。但 Kevin 也提醒 Annie，自己寫得出來，不代表理解了所有後果。她寫的第一版 API 沒有考慮權限檢查，任何登入的會員都能查到別人的比較紀錄。這類問題，仍然需要熟悉該領域的人一起看。跨出去之後，要記得找對的人審查。
有些判斷，不能交出去
Kevin 這一年審查 AI 程式碼的經驗裡，有幾類問題反覆出現。資料庫查詢寫在迴圈裡，資料一多效能就崩潰；錯誤訊息裡不小心印出了會員的電話與地址；為了快速完成任務，代理直接呼叫了昂貴的雲端服務，一個月的帳單多了好幾萬；還有一次，金額計算用了浮點數，造成幾筆訂單差了一分錢。
這些問題有個共通點：程式都能正常執行，測試也可能通過，但在真實環境裡會造成嚴重後果。效能、資安、成本與資料正確性，是開發者必須親自把關的四個領域。 Kevin 和團隊整理了一份清單，凡是碰到金流、個人資料、權限與外部服務費用的程式碼，一律需要資深工程師人工審查，不能自動合併。
這份清單也幫了產品經理與設計師。他們開始自己用 AI 修改一些小功能，清單讓大家清楚知道，哪些地方可以放心動手，哪些地方動之前要先找工程師聊聊。Kevin 發現，界線一旦講清楚，其他職務反而更敢嘗試，工程師也不再擔心有人在不知情的情況下碰壞了關鍵系統。把不能交出去的判斷說清楚，其他的工作才能放心地交出去。
明天就能嘗試的做法：和團隊一起列出三到五個「不能只靠 AI 審查」的程式碼區域，寫進團隊的審查規範裡。
三種資歷，三種起步
同一個團隊裡，三個人的轉換方式並不相同。
Annie 是新進者。她最大的風險，是太早依賴 AI 而錯過打底的機會。技術主管 David 建議她，每週保留一些時間親手寫程式，特別是自己還不熟悉的部分；讀 AI 產生的程式碼時，遇到看不懂的地方一定要追到懂為止。她的起步是：把 AI 當成隨時可以請教的資深同事，同時刻意練習自己的基本功。
Kevin 是資深者。他的挑戰是接受工作手感的改變，把經驗轉成讓 AI 與新同事都能遵循的規則與環境。補文件、補測試、寫審查清單，這些過去被他視為雜事的工作，現在成了他影響力最大的地方。他的起步是：從自己寫得好，轉為讓整個團隊與 AI 都能寫得好。
David 是主管。他發現，衡量工程師的方式需要跟著改變。程式碼行數與完成的任務數量失去了意義，他更在意功能的品質、上線後的穩定度，以及每個人對程式庫環境的貢獻。他在每個衝刺週期裡，固定留下兩成時間給測試、文件與工具改善，也明確告訴團隊，所有人都會留下來，只是工作的內容正在重新設計。他的起步是：調整審查流程與評估方式，讓改善開發環境的工作被看見、被重視。
回到那個週五傍晚。Kevin 後來想通了，這一週他確實很少親手寫程式，但他拆解的任務、審查時攔下的那幾個金額問題、補上的那份說明文件，決定了這一週上線的功能能不能讓顧客放心付款。程式碼的來源變了，對程式碼負責的人始終沒變。
當 AI 寫程式的速度超過人類，開發者最重要的工作，是確保每一行上線的程式碼都值得信任。
發佈留言