決定性的 codemod 是大遷移的地基，agent 只做擴建
Linear 遷移 1,000+ PR 的順序是：先有決定性工具，再讓 agent 擴建它，而不是把遷移整包交給 agent。
為什麼當時不能整包交給 agent
styled-components 難自動化的三個原因：
- 它給你一個圖靈完備的語言
- 它給你完整的 CSS 能力
- 它的 API 完全開放
結果是同一個意圖有無數種寫法，agent 很容易產出「看起來對但其實不對」的東西。
codemod 的起點是測試，不是轉換邏輯
styled-components-to-stylex-codemod 一開始就是一大包測試加上刻意設計的架構，agent 之後才幫忙擴建。它包含線上 playground、跨檔案 selector 處理、以及大部分已知 edge case 的回歸覆蓋。
派 agent 的五個前提
agent 在這五項齊備時表現較好：
- 範圍窄
- 有 codemod runner
- 有範例
- 有驗證腳本
- 有清楚的 checklist
失敗模式：團隊讓 agent 去看 render 出來的 UI、比對生成的 CSS 與原版，agent 經常卡在驗證視覺差異——複雜 hover 狀態、theming 分支、細微 layout 差異。所以模型能力提升之前，這段需要大量人工測試。
另外兩個前置條件：先把樣式地基（variables、constants、共用 primitives）定義好，codemod 才有東西可以轉；兩套系統要能共存，才不必凍結產品開發。
相關：監督 AI 產出的檢查成本可能比自己寫還高、怎麼評估一個 API 的 agent 人體工學？、讓遷移進度可見是推動採用的手段