Weekly Issue 第 16 期：Anduril 的 MVP
近期嘗試降低 AI 相關選文，主要是因為我在閱讀時，不容易判斷內容是正確還是錯誤。本次選的「AI Evals 大辯論」在這點上就做得很棒，正反意見並陳，讓讀者知道自己哪些論點也有人支持，哪些論點具有爭議。
🗞️ 熱門新聞
The Amusement Park for Engineers
原本看是 Anduril 嘀咕幾聲（我對國防工業沒興趣），但看到一半覺得太讚了，推薦所有做產品的人閱讀。
這句話開始點亮我的眼睛：「那座臨時搭建的塔，是我們自掏腰包、為了驗證可行性而做的，幫助攔截了近一千磅的大麻，並導致數十起毒品走私逮捕 」
業界都說要做 MVP，但到底什麼是 viable？沒有 viable 的 MVP 只能稱為 prototype 而已。合作的 PM 有次說的傳神：「別人要樣品屋，但我們只有沒屋頂的牆壁。」
這篇雖然沒有講到 agile，卻做到 agile 的目標。從產品開發到組建 core team 到設定 OKR，能學習的點真的太多。
AI Evals 大辯論: 從 Claude Code 訪談引發的反思
有點晚才看到，這篇關於 evals 的整理好讚。
我只有在 side project 使用 evals，因為「通用的 evals 像『faithfulness』或『helpfulness』是沒用的，你的 evals 必須與用戶問題對齊。 」而對齊這件事不好做，我們當時的產品仍在找 market fit，還沒辦法進行。
這場討論另一個 insight 是，有些人認為 online test 更有意義，這也跟我的經驗類似，以前原廠曾經問我是如何評估 AI 成效，我們當時的方式是，在 AI 上放個 again 的按鈕，如果這按鈕常按，代表使用者可能不是很滿意 AI 的產出。
✨ 科技觀點
年末評核，用決策與結果換 30% 加薪
昨天跟朋友聊天，他提到最近受主管倚重，我有點訝異：「可是你們的方向不是每個星期都在改嗎？這樣你怎麼有辦法做出成績說服主管？」
某部分原因跟這篇主題很像：「數據不等於價值，洞察才是。」我們後來討論，關鍵應該是，雖然方向一直改，可是我朋友都能交出一些 PoC 來驗證方向，讓管理層能進一步下決策，雖然我有點半開玩笑說：「就像是你請 AI 幫你規劃行程久了，就會信賴他。」
我還是覺得不太健康，沒有 outcome 支撐的信賴，放在工作環境還是有點勉強。
Software Design: Tidy First?
現在才發現 Kent Beck 有 Substack 專欄，而且是從 2021 年開始持續到現在。
「到底 Substack 哪點吸引他？Hashnode 更符合開發者的生態呀。」抱著這樣的好奇，翻到這句話：「當我看到一位新訂閱者時，我想要交付一些有價值的內容。 」
接著又翻到另一篇：「我正在面對那些四十歲、甚至五十歲時的恐懼。我有幫手——商業教練、行銷教練，還有 SubStack 的協助。」
字裡行間透露的沮喪讓人驚訝，我想每個人都需要一些存在的理由，而「創作被某些人需要」可以扮演這個角色。
Vibe-Coded Product Success Stories Ain't What They Look
我對 Vibe Coding 還是保有一定距離（應該說，對不熟悉的東西，都保有距離，這是我的壞習慣）。這篇講到幾個我在意的點。
「別小看粉絲群的力量。2000 年代，Joel Spolsky 所涉足的任何事物幾乎都能變成黃金。StackOverflow？有。Trello？有。為什麼？他有忠實的粉絲群 」
在創作者經濟，這是個常見的現象，有時我們在談 Vibe Coding，談的不是產品設計（例如哪些設計能拉高 MAU），而是在看別人演出。前幾天談到開發者行銷跟普通行銷的差別，也許這也是個例證。
What is developer marketing?
看完這篇，忍不住想：開發者行銷跟普通行銷，關注的可能是不同重點。
依照這篇的講法，開發者行銷在於找出「AHA Moment」，然後將它傳達給使用者，宏觀角度來講，這跟 Product Lead Growth 是同樣意思，幫助使用者理解你的產品，然後用它來驅動成長。
而常見的行銷比較像是 Marketing Lead Growth，用廣告跟故事來跟使用者溝通，這當然也能驅動成長，但跟 PLG 是不同道路了。
📌 工程實務
The quality of AI-assisted software depends on unit of work management
這篇算是用 LLM 開發 AI Agent 的一種建模原則：「用 User Story 當成 AI Agent 的邊界。」
挺有趣的，這意味著，你需要很多的 AI Agent（類似於，你需要很多的 API 來完成 User Story），而這些 Agent 間也存在明確的邊界，甚至可能在給 LLM 的 System Prompt 中，會明確說明只有哪些問題是可接受的。
說有趣是因為我不太確定這是不是有效的範式，看原文，作者他們也還在實驗中。
'Make invalid states unrepresentable' considered harmful
「然而，許多大型科技公司——包括我曾任職的兩間公司 GitHub 與 Zendesk——刻意選擇不使用外鍵約束。 」
有點爭議的話題，但內容很有意思：到底約束應該要設計得多嚴格呢？
我曾經設計過內容管理系統，當時嚴格依照狀態機，每個狀態都有對應的動作。如果沒有對應動作，就不能切換。結果遇到原本設計時沒想到的情境，然後要重新設計。
如果用 DDD 建模，理想情況下，領域模型會跟應用程式的模型相匹配，DDD 有項原則是領域的變動引導軟體變動，而不是反過來，但當領域變動很頻繁時，開發成本就會變高（當然，那種情況高的也不只是開發成本了）。
知道 GitHub 跟 Zendesk 沒有嚴格使用 FK，會讓我在不設 FK 時安心一點。
Interface 不是有開就好：從一個 PR 來看抽象化的重要性
很常聽人說依賴反轉，但具體要如何實施？這篇講的就很詳細。
Robert Martin 講 Clean Arch，也是講究抽象行為，獨立實作。依賴反轉的困難點是，如果不知道背後邏輯如何運作，很容易會被實作帶走，導致抽象出來的東西無法套用在其他場景。
就像 PM 要多看產品，了解不同的實作，才能知道它們間該如何抽象。
How I influence tech company politics as a staff software engineer
看了 Goedecke 關於工程師在職場政治的文，跟經驗大致相同，儘管我從來都不喜歡職場政治。
大致上他建議，你應該把工作包裝成管理層的目標，而且最好積極看待這件事，畢竟「無論你做不做，某項計畫都會被支持。但如果你不參與，你就無法掌控那個計畫會是什麼。」
但同樣來自經驗的是，沒有深層理解的、單純包裝的工程計畫，很容易在面臨逆風時陣亡，跟投資股票的經驗類似。要尋求的是合適的投資人，而不是單純想賺政治資本的人。
我以前的主管常常稱呼 GM 為 Investor，後來覺得這個稱呼超貼切。