20 年經驗工程師撰文：AI 程式碼仍須逐行審查
一位寫了 20 年程式碼的軟體工程師撰文主張，AI 生成的程式碼仍要逐行讀、逐行審，不能因為能跑就盲信。他承認這類工具寫得比自己快，經審查後品質往往也不差，但它的做法主要是不斷做加法：堆砌覆蓋錯條件的單元測試、重複實現已有函式、每行都加無用註釋，出問題後還會編造一套語氣篤定的根因分析。他認為 95% 的正確率不等於 100%，靠提示詞“配方”解決不了問題，行業還缺少可重複的驗證流程；只要 PR 上署著自己的名字、自己還在值班，就該讀懂這段程式碼。
原標題：I Read the Clankers' Code
閱讀原文
| 評分 | 42 / 50（平均 46，門檻 76） |
|---|---|
| 狀態 | 未入選 |
相關報導
Meta 工程師稱難逐行審查 AI 生成程式碼
Meta 工程師在 LinkedIn 發帖稱，用 AI 寫程式碼後難以逐行審查，交付的系統成了自己不完全理解的黑盒。帖文說 AI 輔助交付節奏太快，逐行檢查會耗費大量時間，結果可能只懂高層結構、不懂每個細節，這違背軟體工程習慣。該帖被轉到 Hacker News 的 Ask HN 後獲得 179 分、292 條評論，討論工程師該理解到什麼程度、又該如何應對才敢繼續交付。
研究：AI 程式設計代理生成更多程式碼，軟體產出未增加
哈佛大學研究者在 700 多家公司、70 萬名員工、3 億條工作事件的資料中發現，AI 程式設計工具並未讓企業軟體產出增加或減少用人，編碼階段省下的時間被下游環節吸收。程式碼審查時長明顯增加，pull request 更常需要返工，審查者留下的評論也更多。研究據此認為人工程式碼審查是 AI 編碼效率的主要瓶頸。
開發者稱用 Claude Code 後不再手寫程式碼
一位寫了 18 年程式碼的開發者表示，自去年在 Claude Code 中使用 Opus 4.5 後，用自然語言描述需求比手寫程式碼更快，於是徹底停止了手寫程式碼。他所在的 Filestage 團隊月合併 PR 從約 200 增至 300，bug 報告未增加，每位開發者每月 AI 訂閱費 20 美元，工具可自選 Codex、Claude Code 或 Cursor。
評論：AI 借 Lean 寫數學證明，不讀 AI 程式碼漸成常態
一位電腦科學家在這篇評論中指出，AI agent 結合 Lean 等互動式證明助手，正在把希爾伯特百年前設想的「證明機器」變為現實，其對數學界的衝擊甚至超過希爾伯特綱領的失敗。他同時警告，程式設計領域已把不讀 AI 生成程式碼當成常態；而在 Curry-Howard 對應下程式與證明本質相同，放棄閱讀就等於放棄理解。他主張像數學家反覆簡化 AI 證明那樣，用抽象、重構與更高層語言把程式碼簡化到能裝進腦中。
部落格：讀 AI 生成文字速度至少慢三分之一，風格與精度雙雙流失
一位作者在部落格中稱，自己閱讀 AI 生成文字的速度至少慢三分之一，即便篇幅相同。他把原因歸為兩點：AI 會平均化寫作風格，讀者難以感知作者本人及其語境；AI 為把文字拼接通順必須自行假設，傾向選擇更模糊的措辭，從而損失精度。他還指出多數模型輸出囉嗦，讀者需自行替換含糊詞，寫作者省下的時間會轉嫁到讀者一側，並帶來更多追問、更多迭代與信任下降。