.

Agentic coding 讓架構設計從幾天壓縮到幾小時，但過去的品質與判斷力，要怎麼在加速後保留？

「慢」的價值不在慢本身，而在過程裡發生的兩件事：context 的內化，以及方案選擇之間的掙扎——判斷力正是在這種不舒服裡長出來的。AI 壓縮了產出時間，也一併壓縮了這兩件事。資深者還能靠累積把關，但「AI 給什麼、看起來合理就收下」的下一代，判斷力要從哪裡養成？資深判斷又要趁什麼場合交接？

這場分享不是呼籲放慢，而是把隱性的養成過程重新設計成顯性機制：從判斷力養成的條件談起，說明 AI 協作為何恰好破壞每一個；依「做錯後回頭的代價」篩選哪些決策放給 AI、哪些留給人；主體聚焦兩個可直接執行的做法——「人先設計、AI 後提案」的順序紀律，以及設計評審中陳述被否決方案的規則。被否決的方案與理由，正是資深判斷的顯性化，是給下一代的免費教材。最後談三個判斷力成長的觀察訊號，以及最大的敵人：機制淪為形式化。

.

原本只是想找 AI 幫忙寫程式，讓自己輕鬆一點，沒想到一路從 VS Code 搭配 GitHub Copilot，玩到現在使用 Herdr，竟然莫名其妙變成了一支 AI 開發團隊！

既然 AI 已經會寫 Code、修 Bug、跑測試，那乾脆讓它們組隊工作吧！有人負責 Coding、有人負責 Code Review、有人檢查資安風險，再搭配開發規範與品質驗證流程。看起來分工明確、各司其職，工程師終於可以準備躺平了……才怪！

因為很快就會發現，AI Agent 會寫程式是一回事，讓一群 AI Agent 好好合作，又是另外一回事。 這次，我們來聊聊如何組建 AI Coding Agent Team、設計 Agent 的角色與職責、建立團隊開發規範，以及如何實際透過 Herdr 指揮這群 AI 隊友，進行任務分派、協作開發與品質把關。

當然，也少不了一路上的踩坑經驗：Agent 之間如何協調？怎麼避免各做各的？如何確保最後交付的 Code 真的能用？ 當 AI 開始負責寫 Code，而工程師開始負責帶AI團隊，我們的工作似乎真的不太一樣了。 只是說好的 AI 幫我分擔工作，怎麼最後變成要管理一整支 AI 團隊？ 所以，這次我們真的能躺平了嗎？還是終究注定這是一場以 Token 決定差距的競賽？