Gu-log Picks

Satya Nadella 提出「反向資訊悖論」：傳統經濟學擔心賣家為了賣知識而洩漏知識，但 AI 時代反過來了——買家為了用 AI 必須餵進自家機密。他主張企業需要建立「信任邊界」，讓學習成果留在自己手上。

Bun 創辦人 Jarred Sumner 用 Claude Fable 5 把 53 萬行 Zig 程式碼重寫成 Rust，靠的是 64 個 Claude 平行跑 dynamic workflow、對抗式 code review、以及一套「不改流程、只改語言」的機械式移植策略。11 天後測試全過，可檢測的記憶體洩漏全部修掉，binary 小了 20%。

TypeScript 團隊把整個編譯器用 Go 原生重寫，實測大型專案編譯速度快 8 到 12 倍，記憶體用量還更少。VS Code 專案從 125.7 秒變 10.6 秒，編輯器裡從打開檔案到看到第一個錯誤，從 17.5 秒變不到 1.3 秒。

Simon Willison 從 Claude Code 團隊的爐邊對談學到一招：與其給 Fable 詳細規則，不如讓它自己判斷。延伸應用：讓 Fable 自己決定什麼任務該丟給比較省的模型跑。

Anthropic 工程師 trq212 分享用 Claude Fable 5 寫程式的方法論：對他來說，agent coding 的瓶頸開始不只是模型能力，而是使用者能不能在事前、事中、事後找出自己的「未知」。文章整理多個 prompt 範例，也提到可用 HTML artifact 把盲點、原型和計畫視覺化。

Phil Chen 分享他從自己創業到 Helm AI、Scale AI、OpenAI、Google 的六年職涯觀察：當 agent 能解決所有定義清楚的問題，真正值錢的是找問題的能力、最後一哩的執行力，以及那些無法被 loss function 量化的東西。

Geoffrey Litt 在 AI 工程師大會的演講：Agent 越來越會自己驗證，但理解 code 的價值不只在驗證，而是在保持參與能力。他分享解釋型文件、小測驗、微型世界與共享空間，讓人類在 agent 加速時仍跟得上系統。

AI 能處理前端的 80-90%，但剩下的邊角——深度、對前沿特性的敏感度、知道穩健預設什麼時候不是最優——才是技術人的護城河。基礎不是被淘汰，而是變成會複利的資產。

把 Fable 5 當指揮官、Opus 當深度思考手、Sonnet 當苦力、Codex 當平行宇宙工程師——一套在 Claude Code 裡搭起來的多模型編排架構，讓最貴的腦袋只做最關鍵的事。

Mitchell Hashimoto 試著定義「品味」這個越來越常被提起、卻越來越難說清楚的詞：在沒有客觀指標可衡量的地方，持續做出高品質的主觀判斷。有人說品味的結果太好抄了所以不值錢——但這恰恰證明了相反的事：沒有第一個有品味的人先做出來，其他人根本不知道該抄什麼。

打開任何一個 agent skill，裡面滿滿都是「請詳細一點」「請仔細一點」這種看起來很認真的指令。問題是它們根本沒在改變模型行為。Matt Pocock 點出 no-op 的陷阱，還有怎麼一眼分辨「廢指令」跟「真的有用的指令」。

Loop Engineering 這個名字起錯了。真正的活不在 loop，在腳下那塊沒人拍照的地基：把「什麼算對」一層層壓進最便宜的執法官、對齊顆粒度、鋪滿九層傳感網、還清理解債。執行免費了，立法變貴了。

2010 年普林斯頓研究說年收 75,000 美元是快樂天花板；2021 年華頓商學院發現天花板根本不存在。兩派合作後發現：錢對大多數人持續有效，但對最不快樂的那群人在 10 萬美元後就失靈。關鍵在於錢到底是在「刪除焦慮」還是在「餵養自我」。

Sakana 推出 Fugu：一個 API 後面藏一整套 multi-agent 調度系統，主打「不靠單一廠商的 AI 主權」。但一位讀完技術報告的研究員拆台：閉源調度器疊在閉源模型上，能控制的反而更少；而且贏了 benchmark 卻從不報成本。

有人嫌 Ghostty 開機慢一秒「根本不能用」，作者 Mitchell Hashimoto 回了一段教科書級的取捨說明：冷啟動慢不是 bug，是把成本前置去換八小時 session 的順。順便戳破一個工程界的老毛病——大家正在優化的，是不是一個一天只按一次的按鈕？

大公司裡一直有兩個陣營：流程派和成果派。幾十年來他們勉強學會共處，但 AI 徹底打破了這個平衡——成果派看到終於能甩開流程派的機會，流程派則看到 AI 生成的災難正在逼近。

當 CTO 們瘋狂推 AI coding，軟體工程師分裂成兩個階級：擺爛的和職人。擺爛的把 code 往上丟、不讀、不測、不 care；職人扛著 review 重擔，看著品質崩壞，最後也變成擺爛的一員。

一個花了兩年執行所有生產力建議的人，最後發現自己變成「最有紀律的無產出者」。問題不是不夠努力，而是把優化系統本身當成了目標，忘了問「這一切是為了什麼」。

半年前的 Coding Agent 最佳實務大多過期。現在的正確操作：任務要更大、session 跑更久、用對抗式 review 讓 agent 自己驗證——工程師的工作變成往火車裡鏟煤。

每兩小時，Codex 幫一個人寫好一批電子郵件回覆等他審。草稿大多很好，他每次還是改——補一個上週某串對話的決定、因為認識收件人而把語氣放軟、刪掉一個還不想許下的承諾。重點來了：那些改動本身也是 context，而且是大多數自動化每跑完一輪就丟掉的 context。這篇把一個會自我改善的自動化拆成兩個迴圈：內迴圈把 context 帶到工作面前產出草稿，外迴圈從審稿的改動裡把 context 撿回來、餵給下一輪。難的不是看出哪裡被改，是讀懂那個改動到底想說什麼。