團隊最容易丟給 AI agent 的工作，剛好也是新人最需要碰的工作。
小 bug。小 UI。文件整理。測試補一補。把某個舊元件拆乾淨。幫圖片工具補一個預覽狀態。這些任務看起來都很適合交給 agent：範圍不大、風險可控、成果容易 review，失敗了也能 revert。
問題是，這些任務原本不是只有產出價值。
它們也是新人進入系統的入口。
所以我覺得「AI agent 會不會取代工程師」這個問題太急了。比較早發生、也比較不容易被看見的變化，是團隊把一批 beginner-safe tasks 清掉了。短期看是效率。長期看，可能是在拆掉新人練習判斷力的場地。
很多工程師熟悉一個系統，不是從架構圖開始。
是從一個很小的修改開始。
改一個錯字，順便知道文件放哪裡。修一個 edge case，順便讀到資料流。補一個測試，順便搞懂 mocking 習慣。調一個 UI padding，順便看到 design token、component boundary、reviewer 在意什麼。
這些事情很瑣碎，但它們有一個好處：犯錯成本低。
新人不可能一進團隊就被丟去重寫 payment flow，也不該第一週就碰權限模型。好的 onboarding 需要一串低風險任務，讓人慢慢建立三種感覺：這個 repo 怎麼長、這個團隊怎麼 review、這個產品的邊界在哪裡。
Agent 進來以後，最先被自動化的通常也是這一串。
因為它們最好描述。
「幫我把這個 warning 修掉。」
「幫我把這個元件改成 responsive。」
「幫我補測試。」
「幫我整理 README。」
這些指令不需要太多組織政治，也不需要很深的產品判斷。於是任務 intake 會自然流向 agent。不是因為主管想裁 junior，而是因為每個 senior 都太忙，手邊剛好有一個可以立刻開工的執行者。
這才是危險的地方。它不是一個戲劇化的替代，而是一個很普通的分流。
工程判斷力很少是聽課聽出來的。
它通常是在小錯裡長出來。
你改了不該改的 public API，被 reviewer 擋下來。你補了一個太假的測試，被問為什麼沒有覆蓋真實 bug。你把 UI 修到桌面版很好看，結果手機版爆掉。你以為只改文案，結果觸發 i18n key 的 fallback 問題。
這些都是新人應該遇到的錯。
不是為了折磨人，而是因為工程師需要在安全範圍裡累積手感。哪些改動看似小，其實牽到契約？哪些測試 pass 了，產品行為還是不對？哪些 review comment 只是風格偏好，哪些是在保護系統？
如果 agent 把這些小錯先吃掉，新人少掉的不只是 ticket 數量。
少掉的是被系統教育的機會。
更麻煩的是，團隊一開始不一定會感覺到損失。Velocity 可能還上升。Backlog 變乾淨。Senior 少處理一些小事。PR 看起來更快合併。
半年後才發現，新人能看的只剩兩種工作：太簡單所以已經被 agent 做完，或太複雜所以不敢交給新人。
中間那層最有價值的練習題，沒了。
Agent adoption 不會讓 review 消失。很多時候剛好相反。
小任務被 agent 做掉以後，maintainer 變成更多輸出的驗收者。Diff 可能更快出現，但 reviewer 要判斷的事情沒有變少：需求有沒有被理解、測試有沒有對準問題、權限有沒有越界、修改有沒有藏副作用。
對新人來說，這裡有一個微妙的轉移。
以前新人透過「自己改」學系統。現在他可能被安排去「看 agent 改」。這不是不行，甚至可以很好。但前提是 review 被設計成學習流程，而不是只有最後按 approve。
如果新人只看到 agent 的 final diff，他學到的很有限。
他不知道 agent 中間試過哪些路徑。也不知道哪些假設被丟掉。更不知道 reviewer 為什麼接受某個 tradeoff、拒絕另一個解法。最後他只會學到一件事：有一個工具會把 patch 生出來，而 senior 會說能不能 merge。
這不是 onboarding。
這比較像旁聽別人的工作。
還有一個低估問題。
團隊很容易用「有多少 AI PR」來判斷 agent 影響範圍。但真實工作不一定長那樣。
有人在本機叫 agent 先修測試，再自己整理 commit。有人讓 agent 找 bug、讀 log、列修改方案，最後人工改檔。有人把 agent 產出的 patch 拆開放進自己的 PR。也有人只用 agent 做 repo 導覽、寫 acceptance criteria、整理 review note。
這些都不一定會留下 bot label。
所以當你說「我們沒有把 newcomer tasks 交給 AI」，最好先問清楚：你看的到底是什麼？
是 PR author？commit message？工具設定檔？本機 session？還是只是大家的印象？
如果只看最顯眼的 PR，你會錯過很多已經被吸走的小任務。這也會讓 onboarding 問題更難處理，因為團隊以為練習題還在，實際上它們已經在每個人的 CLI 裡被消化掉。
我不是說小任務都不准交給 agent。
這種講法太假，也不符合現實。很多小事交給 agent 是合理的。重複性高、驗證明確、上下文有限，讓機器處理本來就很划算。
真正要分的是：哪些小任務只是成本，哪些小任務同時是訓練。
例如圖片輸出、尺寸轉換、社群預覽這類工作，如果新人只是要學會產品資產流程，可以讓他先定義驗收標準，再讓 agent 或工具跑實作。像準備 Instagram 素材尺寸時，用 Resize Image for Instagram 這種瀏覽器本機處理的工具把圖片調到常見輸出格式，本身不是重點；重點是新人要說得出來為什麼這個流程需要預覽、不能上傳原圖到不明服務、哪些尺寸會影響產品發布。
同樣地，前端團隊如果在探索 agent-era UI pattern，也不一定要讓新人從零開始亂搜一堆案例。可以先讓他整理問題：什麼是 Generative UI？什麼情境需要 agent 動態渲染介面？哪些範例只是 demo，哪些真的能放進產品？這時候把 生成式 UI 資源 當成材料入口是可以的，但學習任務不能停在「找到連結」。他要能比較、篩選、說出取捨。
這樣的小任務就不是雜工。
它是練習判斷的載體。
我會把 agent onboarding 改成幾個很具體的規則。
第一，保留一批 beginner-safe tasks。
不用很多，但要刻意保留。文件、測試、小 UI、錯誤訊息、低風險 refactor，都可以。重點是這些任務要讓新人碰到真實 repo，而不是只在 onboarding sandbox 裡玩假題目。
第二，讓新人先寫 acceptance criteria，再讓 agent 實作。
這個順序很重要。新人如果直接看 agent 生出來的 patch，很容易被答案牽著走。但如果他先定義「怎樣才算修好」，他就會被迫讀需求、讀既有行為、想驗證方式。
第三，要求 agent 留 handoff note。
不是華麗 summary，而是幾行有用的東西：改了哪些檔案、為什麼這樣改、跑了哪些命令、哪些測試沒跑、哪裡需要人類判斷。這份 note 可以變成新人 review 的教材。
第四，把 review comment 當成訓練資料，而不是只當阻塞。
Senior 不可能每次都寫長篇教學，但可以固定指出一兩個判斷點：這裡為什麼不能改 public contract？這個測試為什麼不夠？這個 UI 問題為什麼不是 CSS 而是資料狀態？
新人學的不是「agent 寫錯了」。
新人學的是「團隊怎麼判斷對錯」。
我越來越不相信「把瑣事都交給 AI，人類就能做更高階工作」這句話。
它只講對一半。
有些瑣事真的只是瑣事，清掉很好。但有些瑣事是工程師變強的路徑。你不能一邊抱怨新人沒有系統感，一邊把所有能建立系統感的小入口都丟給 agent。
成熟的 agent workflow，不是把所有小工作清空。
它是分清楚哪些工作該讓機器省時間，哪些工作該留下來養人。
如果團隊沒有做這個分類，AI agent 不一定會先取代工程師職缺。它可能先取代的是新人練習、犯錯、被 review、慢慢長出判斷力的空間。
這件事沒有裁員新聞那麼刺激。
但對一個工程團隊來說，可能更傷。
ryanvale
iThome鐵人賽
看影片追技術