15 posts
LLM 對話包含意圖、被拒絕的替代方案以及可執行的程式碼。這正是文件應該包含的內容。以下是將 ephemeral chat 轉換為持久、可搜尋的文件，同時不遺失敘事的方法。
你花了 45 分鐘和 Claude 設計一個 retry circuit。你解釋了 failure modes，因為 exponential backoff 會掩蓋 cascading pressure 而拒絕了它，確定了 token-bucket rate limiting with…
費根審查需要四到六個人、兩小時才能審完250行程式碼。大型語言模型可以透過承擔準備工作與檢查清單的執行來削減這部分成本，但它無法取代人類角色去發現最昂貴的缺陷。
一次完整的費根審查需要一名主持人、一名朗讀員、兩到四名審查員，以及作者本人。團隊以每小時125行的速度，花費兩小時審查大約250行程式碼。這意味著一次小小的改動就要消耗八到十二人時。 大型語言模型可以在不到一秒內讀完250行程式碼。它可以執行檢查清單、標記可疑模式，並在任何人開啟檔案之前就產生一份結構化的缺陷紀錄。…
N-version programming 聽起來很簡單：跑多個實作，挑最好的答案。但在實務上，「最好」比「最常見」難定義得多。
你有同一個函式的五種實作。三個回傳相同的結果。一個稍有不同。一個拋出例外。哪一個才是對的？ 大多數團隊預設採用多數決。當輸出完全一致且錯誤顯而易見時，這麼做沒問題。但只要你的實作在細微處出現分歧，或每個變體都回傳不同答案時，這套方法就會崩解。N-version programming…
用 LLM 進行 N-version programming 不需要多個模型。只要改變 prompt、角色設定和推理限制，就能從單一模型中產出多樣且正確的實作。
N-version programming 的假設是：多樣性來自不同的作者。對 LLM 來說，這意味著不同的模型、不同的供應商，甚至不同的訓練版本。但這個假設是錯的。只要改變「怎麼問」，而不是「問什麼」，就能從同一個模型中獲得有意義的多樣性。 問題在於：把 temperature 調到 1.0 然後重複跑五次…
AI 寫程式遵循一條驗證梯度。後端在毫秒內完成驗證。網頁端需要幾分鐘。行動端需要幾小時。回饋循環的速度與確定性直接決定了 AI 寫程式在各技術層的實際效果與可靠程度。驗證速度沿著光譜遞減，決定了 AI 編碼在哪裡能自主迭代、在哪裡必須仰賴人類的判斷。
AI 模型自己寫程式這件事本身並不有趣。有趣的是它生成程式碼之後發生的事：模型能以多快的速度知道程式碼是否正確？生成與驗證之間的回饋循環有多緊密？ 這個循環決定了一切。它決定了模型能否迭代自己的輸出，決定了人類能否在不手動檢查的情況下信任輸出，也決定了 AI 寫程式究竟在哪些領域行得通。…
AI 程式設計對能從任何混亂中恢復的精英團隊有效。其他人得到的只有恐懼、失敗的 CI，以及被放棄的實驗。差距不在於模型。
觀察兩個團隊使用同一個 AI 模型，你會看到兩種完全不同的結果。 第一個團隊向模型下達提示，要求構建一個畫面。輸出接近正確，但不完全對。樣式偏離了 Figma 檔案。狀態管理碰到了不該碰的檔案。建置在本機通過，但在 CI…
大多數團隊嘗試 AI 輔助寫碼，交付的程式碼未能通過 QA，然後放棄。問題不在模型，而在於缺乏讓 AI 輸出值得信賴的防護機制。
大多數嘗試 AI 輔助寫碼的團隊，走的是同一條軌跡。 他們一開始充滿熱情。模型在幾分鐘內生成一項功能，他們交付出去。QA 捕捉到一個錯誤，於是他們交付一個修復。QA 又捕捉到另一個錯誤，這次是在一個本該毫無關聯的 module 裡。那個修復牽涉了十四個檔案，然後 QA 又發現了另外三個問題。…
你有型別檢查、語法檢查和架構規則。但你的確定性堆疊對複雜度、重複和命名災難視而不見。這裡有個零成本的解決方案。
讓我們誠實面對：大多數 AI 程式碼流水線目前的真實面貌是什麼。 你用 Cursor 或 Claude Code 產生程式碼。你執行 ，因為 TypeScript strict mode 能抓出型別不匹配。你執行 ESLint，因為沒人想在拉取請求裡為了分號爭吵。或許你會執行…
AI 程式開發工具擅長生成第一版。真正的工程挑戰從第四版開始——當團隊需要在不破壞其他一切的情況下修改某些東西。
每個 AI 程式開發的展示都遵循相同的弧線。有人對模型下達提示。一個能運作的應用程式就這樣出現了。觀眾印象深刻。 他們確實該如此。速度是真的。能力是真的。有 AI 參與時，第一版確實交付得更快。 問題是，第一版從來都不是困難的部分。 軟體工程的成本不集中在初始創建。它集中在第四、第五、第六次迭代：…
衡量 AI 生成程式碼品質的真正標準，不在於第一天是否能運作，而在於第三十天你能否替換它，而不需要 rewrite 其他所有東西。
大多數關於 AI 生成程式碼品質的討論，都聚焦在生成當下的正確性。輸出能編譯嗎？能通過測試嗎？符合規格嗎？ 這些只是基本門檻。它們無法告訴你真正的成本。 真正的衡量標準是可替換性：當需求改變時，你能以多低的成本刪除這個 module 並在相同的 contract 背後重新實作？ 如果答案是「輕而易舉」，AI…
人工審查不一致。AI 審查更糟。AI 生成 codebase 唯一可擴展的防禦是確定性 enforcement：讓建置失敗的規則，而非被忽略的建議。
對 AI 生成程式碼的標準建議是「仔細審查它」。 這建議正確但在規模化時毫無用處。 開發者在警覺、熟悉領域且沒有時間壓力時，審查 AI 輸出能發現問題。在其他所有情況下——也就是大多數情況——問題會溜過去。 用 AI 審查者抓 AI 生成的問題更不可靠。你在要求一個機率系統驗證另一個機率系統的輸出。失敗模式是相關的。…
當 AI 能從規格產生實作、測試與 contracts，槓桿最高的人類工作就會往上游移動。最需要被仔細審視的東西，其實是規格本身。
如果你已經用 AI 出貨超過幾個星期，你大概很熟悉這種感覺。 你打開一個 PR。程式碼夠乾淨。命名還不錯。測試也有。看起來沒有任何明顯壞掉的地方。但你就是覺得哪裡怪怪的。 也許邊界有點模糊。也許 contract 只是被暗示，卻沒有被明確寫出來。也許 happy path…
如果你想讓 AI-generated code 能在正式環境站得住，光靠 code review 不夠。你需要一套從 type constraints 到 mutation testing 與 runtime containment 的分層安全棧。
AI-generated code 最大的危險，不是它總是錯的。 真正危險的是，它經常「看起來已經對得足夠可以 merge」。 這正是風險所在。明顯有問題的 code 往往會被擋住。真正會進正式環境的是那種看起來合理、能過幾個 happy-path tests、卻悄悄削弱關鍵 boundary 的實作。…
這篇對 Stanford CS146S 的評論認為，它準確看見了 AI coding 的轉向，但真正決定長期品質的仍是 AI architecture：系統是否可替換、可約束、可持續演進。
Stanford 的課程代碼是 ，課名是 The Modern Software Developer，由 Mihail Eric 授課，是一門在 2025 年秋季首次開設的課程。想看課程的官方概覽和 syllabus 細節，可以直接到官方課程網站…
Design by contract、property-based testing、mutation testing、model checking 從來不是壞想法。真正的問題是它們長期需要太多專業判斷才能維持，而 AI 正在改變這筆帳。
軟體工程裡有很多方法，你一讀就會覺得「這本來就該這樣做」。 當然應該用 contracts 明確 function 能接收什麼、必須回傳什麼。當然 tests 不該只寫幾個人工挑選的例子，而應該驗證 properties。當然團隊不該把 coverage 當成品質代理，而應該真的去判斷 tests 能不能抓到…