別替 AI agent
蓋工廠
Garry Tan 用 54 萬行 Rails 得到一個反直覺結論：真正重要的不是更大的 app，而是把工作方法整理成可測試、可重用的 skill。
SCROLL
Garry Tan 用 54 萬行 Rails 得到一個反直覺結論：真正重要的不是更大的 app，而是把工作方法整理成可測試、可重用的 skill。
Garry Tan 今年 1 月重新開始寫程式，做了一個叫 Garry's List 的 Rails app。規模很大：超過 54 萬行，包含 app 程式碼和一整套測試。
照 2013 年的工程直覺，這很值得驕傲。程式碼很多，測試很多，功能真的做出來了。但他的反省是：那 54 萬行不是最重要的成果。真正有價值的是開發過程中長出來的工作方法，也就是 GStack。
GStack 是他和 agent 一起工作的設定。它後來開源，三個月內拿到約 10.5 萬個 GitHub stars。原本的 app 是產品，開發方法只是副產品；最後真正有複利的是副產品。
Garry 說自己像一個從 2013 年穿越到 2026 年的 Web 2.0 工程師。工具已經換了，但腦中的地圖沒換。以前的信念是：能力等於程式碼。要做更多事，就寫更多 code。
有了 Codex、Claude Code 這類工具後，這個舊信念會變得更危險。因為它真的能讓你更快寫出更多 code，所以陷阱不會像陷阱。app 會 ship，測試會跑，PR 會合併，你會覺得自己超級有效率。
問題是，你可能只是用 2026 年的引擎，開往 2013 年的目的地。速度變快，方向沒有變。
他的結論不是「不要寫 code」。而是不要把 agent 當成一個需要被無數程式碼監管的低信任工人。當模型已經能理解意圖、寫出可用程式碼、自己修正很多錯誤時，過度控制會變成成本。
過去幾年，大家把 LLM call 當成昂貴資源。模型貴，程式碼便宜，所以工程師寫很多程式碼來節省模型呼叫。先過濾、先驗證、先排程、先重試，能少叫一次模型就少叫一次。
Garry 認為這個經濟已經反轉。模型越來越便宜，也越來越強。當模型可以直接理解任務、寫最少必要程式碼、處理例外狀況時，繼續寫一大堆程式碼去照顧模型，就像替一個高能力員工蓋一條低信任產線。
這就是他說的 just-in-time software。不是先蓋一座巨大系統，而是先把意圖講清楚，讓 agent 寫出完成任務真正需要的最小程式碼。
Garry 強調，他說的 markdown 不是臨時 prompt。Prompt 是一次性的，打完就消失。Skill 是可版本控管、可重用、可測試的工作單位。
一個 skill pack 裡面不只是一段文字。它包含工作意圖、判斷準則、必要的少量程式碼、程式碼測試、LLM eval、整合測試，以及一個 resolver，讓 agent 在相關情境下自動選到這個 skill。
他舉的例子是黑客松評審。85 個 submission，要看 repo、看 demo 影片、研究參賽者、評分、排序，最後找出最值得注意的 5 個 app。照舊做法，這可能是一個完整軟體專案。
他的做法是把 Google Drive 丟給 agent，讓 agent 分析 repo 品質、截圖 demo、看每個人背景、評估畫面和產品，最後排出名次。第一次做完之後，他把流程 skillify，變成之後任何黑客松 spreadsheet 都能重跑的 tarball。
這個例子說明轉變在哪裡。以前工程師會先想：我要寫爬蟲、影片處理、評分 pipeline、研究模組、排名系統。現在更好的問題是：這件事能不能被 agent 做一次，然後把工作方法封裝成 skill？
Garry 最激進的說法是 tokenmaxxing：不要再把 token 當成要省到極致的成本。如果你是新創公司，願意多花 token 讓 agent 長時間跑、做更深的研究、反覆測試，可能等於提前使用幾年後才會普及的工作方式。
這句話不代表所有團隊都該無限制燒錢。比較務實的解讀是：不要用舊成本結構做今天的工程決策。當模型能力和價格都快速改善，省 token 省到最後，可能只是讓團隊留在舊方法裡。
這是整篇最實用的落點：工程師的價值不再只是把需求翻成更多程式碼，而是判斷哪些工作該變成 skill、哪些地方需要 deterministic code、哪些地方應該讓 agent 自己處理。
當 intent 可以直接變成可測試、可重用的系統，工程師最稀缺的能力就不再是寫更多 code。
稀缺的是清楚知道什麼值得做，以及什麼不該被做成一座工廠。
選完之後，分享你的觀點
喜歡這種分析嗎？
從 AI agent、穩定幣到平台策略，用台灣讀者看得懂的語言，把複雜的產業變局說清楚。目前已有超過 2 萬位讀者訂閱。
免費訂閱區塊勢 →也可以直接付費支持，解鎖每週完整文章