9 月 23 日的 Rails World，DHH 問台下：還有誰每週仍然手寫不少程式碼？全場大約五隻手。
我看完的第一個反應不是想反駁，是去翻自己的 git 紀錄。因為我也差不多不手寫了，而且比他講的時間點更早就開始往這個方向走。差別在於，我走到一半摔過幾次，現在的做法有一大半是摔出來的。
DHH 說了什麼，反方又說了什麼
DHH 在開場演講宣布，37signals 已經「放下鉛筆」：手寫程式碼在他們公司是例外狀態，「就像在 Sentry 看到一個 bug」，代表該修的是 AI 代理的設定。他把分水嶺定在 2025 年 11 月 24 日 Opus 4.5 推出那天，並說自己 2026 年 8 月一個月寫了 15 萬行，大約是過去月平均的 60 倍。
反方最有力的一段來自 Jared Smith。他抓住 DHH 自己講的 Basecamp 5 故事：每一份修改單看都合理，二、三十份加起來，架構卻像瑞士起司。DHH 的結論是「等更強的模型就好」，Smith 的結論相反：更強的模型只降低單一修改出錯的機率，管不到「誰負責發現整體變差了」。他那句話我很同意：打字從來不是最難的，難的是建立並維持對整個系統的共同理解。
《數位時代》把兩邊整理得很清楚，文末附了出處，我把自己打開確認過的列在最後。
我的工作流怎麼走到今天：五個階段
| 階段 | 時間 | 做法 | 後來為什麼換 |
|---|---|---|---|
| 1. 編輯器裡的 AI | 2024 年 9 月起 | 用 Cursor，把規則寫成規則檔，退場時累積 14 個 | 規則越寫越多，但 AI 只在編輯器裡 |
| 2. 編輯器＋終端機並用 | 2025 年 6 月起 | 文件與審查走編輯器外掛，部署與遠端除錯走終端機，常開三個工作階段 | 兩套介面、兩套習慣 |
| 3. 全部進終端機 | 2026 年 7 月 18 日 | 編輯器全面退場，全部改用 Claude Code，在 Warp 這類 App 型終端機裡做；連看差異都用指令或請代理摘要 | 多包一層 App 的終端機，用起來並沒有比較好 |
| 4. 多席平行 | 2026 年 8–9 月 | 每條線一個代理，有協調的、有執行的；9 月 21 日改用 iTerm2 加 Herdr，席位可以跨機器；一台常開機負責夜間巡檢與排程 | 最多開到 17 個席位，協調成本爆掉 |
| 5. 收攏 | 2026 年 9 月 28 日 | 常駐四席，其餘要用才開；我只對一個入口下指令 | 現在的做法 |
第一階段用了 685 天。第三階段退場的理由很單純：我已經全面改用 Claude Code，在 Warp 終端機裡做事，不再需要編輯器。接著我又發現，多包一層 App 的終端機也沒有比較好，才換成現在 iTerm2 加 Herdr 的多席、跨機器架構。
這幾次換工具，我學到的是同一件事：越直接、中間層越少、越簡潔，人需要介入的成本就越低。
前後比較：我的時間花到哪裡去了
最直接的數字是我放文件與腳本的那個儲存庫：6 月 215 次提交、7 月 130 次、8 月 271 次、9 月 1,841 次，單日最高 234 次。
但我不會拿這個數字去對 DHH 的 60 倍。9 月的提交裡有一大塊是排程自動寫回、交接紀錄，還有為了讓多席運作而修流程本身。產出變多是真的，其中多少有用，要另外算。
真正改變的是我的時間：以前花在寫，現在花在三件事：把需求講清楚、決定要不要放行、驗收結果。
踩過的坑與成本
這部分 DHH 的演講幾乎沒講，我覺得反而最值得寫。
- 額度一週燒完：有一週把最貴的模型開給所有席位，週額度直接用光。真因是連只負責執行的席位也在用最貴的模型。
- 對話越養越肥：量過單一工作階段的紀錄檔長到 105 MB。後來發現，定期交接重開，比換便宜的模型更省。
- 分層不省錢：我試過「思考的用貴模型、執行的用便宜模型」，結果跨席訊息超過 15 則、同一份研判一小時改三版。當時的紀錄寫著：分層不省總量，只是把用量搬到另一個桶子，協調開銷是純增。現在全部統一成同一個模型，只有深度問題才另開子代理。
- 部署卡了 20 分鐘沒人知道：某個網站的自動部署因為檔案權限卡死，重試 20 次都失敗，而且沒有任何告警。
- 連錯瀏覽器：兩台電腦的瀏覽器掛同一個帳號，代理被換到另一台而不自知。
- 多席共用同一份檔案互踩：鎖檔相撞、彼此的改動被對方的提交帶走。
- 錯的結論比慢更貴：紀錄裡有一句我自己都想貼在牆上：錯誤結論的修正成本，是正確結論的好幾倍。
錢的部分：9 月下旬有一週，用量以 API 牌價換算約 1,969 美元。我用的是訂閱方案，實付不是這個數字，但它說明一件事——這不是免費的生產力。
我把人放在哪裡：四個關卡
DHH 說他不讀 Rust，把成品當黑箱驗收。我也不讀每一行，但我沒有把自己從流程裡拿掉，而是留在四個地方。
1. 只有三類事要問我
動到錢、對外發布、不可逆。其他的，代理自己決定、自己做完再回報。這條線畫得越清楚，我被打擾得越少，真正該我決定的也不會被淹沒。
2. 推送要在那一席親口授權
程式碼推上去之前，要在執行的那個席位問我一次，不接受別的席位轉達。聽起來很囉唆，但「誰按下去的」必須是一個講得出名字的人。
3. 正式環境一天只開一個變更窗
同一個 24 小時內，只開一個會改正式環境的時段。平行可以很多條，寫進正式環境的口只有一個。
4. 驗收看真瀏覽器，不看程式碼
我的規則寫得很白：網頁原始碼裡有字，不等於客人看得到。任何上線都要在真的瀏覽器裡看過才算數，需要我登入的頁面就停下來等我。
回應那個問題：誰負責發現整體變差了？
Smith 問的這題，我的答案不是「等更強的模型」，也不是「回去手寫」。
我做了三件事。第一，兩本登記簿：技術債一本、排程一本，任何席位發現的問題都要登記，不准只在對話裡講過就算。第二，常開機每天清晨跑固定巡檢，比對設定有沒有偏離。第三，每個席位收工要寫一份四段的狀態檔：在做什麼、卡在哪、下一步、只有這席知道的事。
但誠實講，這套東西有三個我還沒解決的缺點：
- 最後看整體的人只有我一個，我請假，這個角色就空著
- 整條生產線依賴單一模型供應商，對方調整額度或價格，我只能跟著動
- 9 月有不少工是花在「管理代理」而不是「做產品」上，這個比例還太高
我的結論
方向上我同意 DHH：手寫會變成例外，而且已經是了。
我不同意的是把問題交給下一個模型。Basecamp 5 那塊瑞士起司，我自己也做過好幾塊，每次都不是因為模型不夠強，是因為沒有人被指定去看全貌。
所以在我這裡，真正該被當成「故障訊號」的不是手寫程式碼，是一件事做完了，卻說不出是誰放行的。
常見問題
DHH 說的「放下鉛筆」是什麼意思？
他在 Rails World 2026 開場演講宣布，37signals 把手寫程式碼視為例外狀態，像在錯誤監控系統看到 bug 一樣，代表該調整的是 AI 代理的設定，而不是繼續手寫。
用 AI 寫程式之後，工程師的時間花在哪裡？
以我自己為例，從寫程式碼轉到三件事：把需求講清楚、決定要不要放行、驗收結果。產出量變多，但其中一部分是在維持流程本身。
AI 寫的程式碼沒人逐行讀，出錯誰負責？
模型不會負責。我的做法是保留人工關卡：動錢、對外發布、不可逆的事要問人，推送要有人親口授權，正式環境一天一個變更窗，上線用真瀏覽器驗收。
多開幾個 AI 代理就會比較快嗎？
不一定。我最多同時開到 17 個席位，協調訊息與重工反而變多；後來收攏成四個常駐席位，其餘要用才開。
參考來源
- 數位時代，李先泰，2026-09-30：程式設計迎來「柯達時刻」？Rails 之父宣告放棄手寫程式碼
- DHH，Rails World 2026 開場演講，2026-09-23：YouTube
- DHH，2026-08-09：Endless execution
- Jared Smith，2026-09-24：DHH’s Rails World 2026 Keynote: Pencils Down, Now What
- Joey deVilla，Global Nerdy，2026-09-27：The most confusing funeral I’ve ever experienced
- Shopify Engineering：Migrating Shop app from React Native to native
最後更新：