起因很簡單。一位 Meta 工程師在 LinkedIn 上坦承，現在每天寫的程式碼像黑箱。AI 產出速度太快，逐行檢查根本跟不上，只能掌握大方向，細節交給模型。這篇貼文被轉到 Hacker News，釣出 493 則留言，358 分，吵成一團。
結論先講。留言沒有共識，但有一句話是多數人同意的：你把自己定位成 reviewer 還是 shipper，答案完全不同。底下六派，挑適合自己的拿去用。
六派立場
最高票是一串設計派留言。主張很硬：不讓 LLM 做設計，只讓它填實作。自己先畫好抽象架構、模組邊界，甚至用 Python 寫一份骨架，再讓 agent 補洞。實作寫爛可以換，架構錯了整組陪葬。附和的人補了一句，LLM 的品味就是差，API 邊界和去重做得一塌糊塗。
第二派拿職級打比方。Principal Engineer 早就這樣工作：底下 junior 寫細節，自己掌握設計和關鍵路徑。AI 只是讓每個人都升格成 PE，工作變成設計加審查。有人說得更白，職稱直接改叫專案經理也沒差。
第三派是測試派，人數不少。做法是用 TDD、E2E、staging 浸泡、監控和一鍵還原蓋過去。Ops 出身的人最坦然，他們本來就負責幾千萬行沒寫過的程式碼，Linux 核心也不是自己寫的，照樣上線。
第四派是強硬派。沒讀懂就上線是失職，至少要有一個人講得出每段程式碼在幹嘛。速度變快更該有時間檢查，拿沒時間當藉口，只是中了 AI 公司的行銷話術。
第五派反其道而行，直接放飛。功能上線比程式碼漂亮重要，下一代模型會幫忙清掉這批技術債。有人自稱 FAANG 資深工程師，看完標題就合併。
第六派走工具路線。用 AI 解釋 AI，請模型畫呼叫鏈和架構圖，或者自建 PR 檢視工具，把注意力留給真正要看懂的部分。
可以直接抄的技巧
- 範圍分層。越靠近使用者眼睛的前端越放飛，核心資料路徑嚴審。資料模型、遷移和 feature flag 是底線。
- 先寫一支會失敗的 E2E，再讓 agent 補實作。測試和正式碼互相映照，看不懂正式碼就去讀它的測試。
- transcript 開在第二個螢幕放著，不必全神貫注，有怪味自然會瞥到。
- 有人出怪招。叫 AI 在 MR 裡故意埋一到三個 bug，只給出事區域提示，逼自己讀懂程式碼流向才找得到。
- 用型別守邊界，用灰度控制爆炸半徑。
三個最吵的爭點
第一，LLM 到底懂不懂設計。有人說模型也讀過設計原則。反駁的人拿實測打臉，Opus 5.5 照樣產出大泥球，只會左右打補丁，就是不建抽象。折衷的說法是，模型跟著訓練資料隨波逐流，你不導正，它就選最偷懶的解法。
第二，技術債會不會被便宜 token 吃掉。樂觀派說維護成本在降，債不重要。悲觀派說債越大越麻煩。未來上下文更大，模型更貴，才讀得動，結帳那天設計就重要了。
第三，工程師還重不重要。一位十年資深留言說，PR 動輒幾千行，只能閉眼按批准，已經在看水電課程。另一邊有人嗆，連模型犯錯都看不出來的人，本來就不夠熟。情緒都很真，結論自己判。
一頁懶人包
上面全文做成一頁圖文版，六派對照和分流圖都在裡面，手機可以直接滑。
手機看不到內嵌頁的話，用這條直連開啟：https://static.blog.derekhsu.net/hn-ai-code-ship.html
出處
- Hacker News 原文：https://news.ycombinator.com/item?id=50151036
- 起因：Meta 工程師 Ali Hamie 的 LinkedIn 貼文，經整理取樣約 135 則主樓留言，非逐則普查。