Amazon告訴軟體工程師真正重要的事：AI迎來「文藝復興開發者」時代

在內部追蹤包括 AI 使用量、權杖消耗量和程式碼行數在內的指標，並利用排行榜依據其中部分指標為團隊排名。

但備忘錄警告，將這類指標當作目標，可能導致不良結果，包括「tokenmaxxing」，而不是帶來更好的軟體或客戶體驗。

2026矽谷新指標：「Tokenmaxxing」下的工程師生產力革命與泡沫危機｜iBonnie_愛邦尼

其實在遠古純靠手工的碼農時代，這種評估方式就很不怎樣，通常是反指標， AI 時代更甚。近來在評量愈來愈多由 AI 產出的程式碼時，最常發現的是，寫了一大堆碼，卻只是掩蓋病癥，並沒有抓到真正的問題根源（註）。手工時代這就是人類常見毛病，AI 時代呈指數成長，讓評量者十分沮喪。累死了，應該把評量工作也交給 AI😒。

往好處想， AI 可以快速產出基礎架構，省卻大量打字工夫；而詳盡的註釋，是老一輩碼農特別懶得做的事。缺點則是高速產生的大量程式碼，品質有時候可疑，而做為行動遲緩的兩足動物，卻很難仔細審查。我自認閱讀程式碼的效率不低，現下的量卻不只需要一目十行哩。

真的需要培養幾隻 AI Agent 來搞這檔事，然後，就可以考慮退休了。

註： 這類問題的成因，通常是工程師自己搞不清楚問題何在，把客戶或品保回報的狀況照抄，要求 AI 解決。AI 不太可能知道成因，但既然被要求解決，就想盡辦法把狀況解除。有句話「粉飾太平」，就是這個意思。

我自己遇過的極端情境，是原始碼最終只需要改一行，真正問題就解決了，而 AI 花四、五百行去「粉飾太平」，害我讀碼讀得快吐血😡。怎樣讓 AI 成為得力助手，仍然需要用功學習。

P.S. 啥叫「tokenmaxxing」哩，就是既然老闆拿消耗多少 token 當績效指標，工程師就搞隻 agent 成天空跑，專吃 token，所謂上有政策下有對策是也。