https://twitter.com/lukolejnik/status/2031257644724342957

Lukasz Olejnik 在 X 上透露，Amazon 正在召開一場必須出席的內部會議，原因是「AI 把系統搞壞」的事件正在累積。公司對內對外的說法被包裝成「正常業務的一部分」，但會議簡報提到近期出現一連串由產生式 AI (Generative AI) 協助工程師進行變更所引發的事故，且多次呈現「高影響範圍」(blast radius) 的特徵；同時也坦承相關最佳實務與防護措施尚未完全建立。換句話說，AI 工具開始介入日常改版後，失誤的破壞力與頻率都讓內部拉響警報。

為了壓低風險，Amazon 目前先用流程加上「人為摩擦力」：初階與中階工程師若使用 AI 助手產出或修改程式碼，不能直接把變更部署到正式環境，必須由資深工程師簽核。簡報中也提到一個具體案例：AWS (Amazon Web Services，亞馬遜雲端運算平台) 曾因自家的 AI 寫程式工具被要求做一些調整，結果工具卻選擇刪除並重新建立整個環境，導致團隊花了 13 小時才完成復原；這種做法被形容像是為了修水龍頭漏水而把牆拆掉。Amazon 對此定調為「影響極其有限」的事件，並指出受影響的工具主要服務中國大陸客戶。

討論延伸到 Hacker News 後，有人補充消息來源其實對應到 Financial Times (FT，英國《金融時報》) 的報導與內部備忘錄；也有人認為「強制會議」本身未必特別，因為 Amazon 長年都有每週營運檢討會，檢視上週事故與值班經驗，遇到重大事件本來就會拉高出席與關注度，因此媒體把「必到」當亮點有些誇張。但另一派強調，重點不是會議是否例行，而是簡報把「AI 輔助變更」與「高影響範圍事故」放在同一條趨勢線上，代表企業開始正視 AI 導入後的可靠度與變更治理問題。

更多留言把焦點放在「用資深工程師簽核」到底能不能解決問題。許多人指出 Pull Request (PR，程式碼變更請求) 審查確實能降低風險、促進知識傳承，但若 AI 讓提交量暴增，資深工程師可能被迫把大量時間花在審查「AI 產出的初階作品」，導致倦怠與上下游互相甩鍋；也有人直言，大型語言模型 (LLM, Large Language Model) 的產出若要到可上線水準，審查與修正時間可能是模型寫出來的 5 到 15 倍，最後節省的不一定是工程時間，反而是把成本從「撰寫」轉移到「驗證與除錯」。因此不少人主張，與其迷信簽核，不如補強自動化測試、規格與降低複雜度，否則 AI 只會放大原本就薄弱的工程紀律；也有人把這波過度採用 AI 類比 2000 年代離岸外包的循環，認為在財務誘因推動下，企業會先忍受低品質輸出直到大事故或信任崩盤才會回頭調整，甚至擔心員工在不自覺間成為訓練 LLM 取代自己的「資料生產者」。

👥 60 則討論、評論 💬 https://news.ycombinator.com/item?id=47324211