通訊鴻溝：為什麼資深開發者難以闡述其價值

在步調極快的軟體開發世界中，定義產品的人與構建產品的人之間存在著一種反覆出現的摩擦。對於產品經理或 CEO 而言，主要的敵人是不確定性：使用者會想要這個嗎？這個功能是否有市場？ 對於資深開發者而言，主要的敵人是複雜度：這個新功能會讓系統變得難以維護嗎？它會引入導致付費客戶服務中斷的 bug 嗎？

這種錯位不僅僅是技術上的分歧；它是一種溝通失敗。當資深開發者試圖保護系統免於臃腫時，他們通常使用「技術債」和「可維護性」的語言，而業務端則在使用「上市速度」和「市場驗證」的語言。

業務的兩個迴圈

要理解為什麼會發生這種溝通斷層，我們可以將業務視為透過兩個同時運行的迴圈來運作：

1. 不確定性迴圈（速度）

這個迴圈由行銷人員、銷售團隊和產品經理驅動。他們的目標是盡快學習。他們將一個想法推向市場，收集回饋，然後進行迭代。在這個迴圈中，速度是唯一重要的指標，因為你交付得越快，減少不確定性的速度就越快。

2. 穩定性迴圈（規模）

這是資深開發者所處的迴圈。一旦產品有了付費客戶，目標就會轉向服務的保證。優先事項是保持系統的可理解性、可除錯性和穩定性。在這個迴圈中，每一行新代碼都是一個潛在的負債。

當這兩個迴圈碰撞時，資深開發者往往顯得像是一個「阻礙者」。他們對新功能的需求做出回應時，會對複雜度和維護成本提出警告。然而，正如文案撰寫者可能會觀察到的，你無法用自己的問題來解釋掉別人的問題。業務端並不擔心複雜度；他們擔心的是不確定性。

彌合鴻溝：使用業務的語言進行溝通

如果業務端想要減少不確定性，資深開發者的專業知識應該被框架化為達成該目標的工具。資深開發者擁有的最有價價值的技能並非編寫複雜代碼的能力，而是避免編寫代碼的能力。

與其根據技術複雜度反對某個功能，資深開發者可以提供一條通往相同答案的更具資源性的路徑。例如：

• 與其建立完整的分析套件： 「我們能否先從一個圖表和一個指標開始，看看這是否真的是一種趨勢？」
• 與其開發一個新功能模組： 「我們能否先在現有的 UI 中放一個按鈕，看看是否有人會點擊它？」

資深開發者的「神奇句式」是：「我們能否嘗試一些更快的方法？」

這句話承認了業務端對速度的需求，同時允許開發者發揮其在減少和重用方面的專業知識。它將開發者從守門人轉變為加速器。

AI 因素：加速器還是破壞穩定性的因素？

AI agent 的興起加劇了這種緊張關係。AI 是「不確定性迴圈」中不可或缺的工具；它能以以往不可能的速度生成原型和功能。然而，AI 對「穩定性迴圈」而言是個「徹頭徹尾的破壞者」。它能產生「氛圍代碼」（vibe code）——看起來正確且短期內功能正常，但缺乏連貫的心理模型，使得幾乎無法進行除錯或擴展。

正如一位社群成員所指出的，AI 允許「火箭速度」開發，但它經常將這些火箭綁在一個搖晃的基礎之上。危險在於業務端可能會將生成的速度誤認為是進度的速度，忽略了系統中無人真正理解的長期成本。

建議的解決方案：速度與規模的分離

為了管理這種情況，有人建議將系統解耦為兩個版本：

1. 速度版本： 一個快速原型的環境，AI agent、初級開發者和產品經理可以在其中進行瘋狂的迭代，以尋找產品市場契合度（product-market fit）。這裡的目標不是穩定性，而是學習。
2. 規模版本： 一個由資深開發者設計的、後續的穩定化版本。一旦功能在「速度版本」中得到驗證，它就會被經過刻意的重新工程化，以實現穩定性、可擴展性和可理解性。

透過明確地將「嘔吐草稿」（快速原型）與「編輯後的稿件」（正式生產系統）分開，公司可以滿足快速實驗的需求，而不犧牲平台的長期健康狀況。

反對觀點與細微差別

雖然「避免複雜度」的準則是我司 seniority 的標誌，但社群提出了幾項重要的注意事項：

• 情境因人而異： 為醫療設備構建韌體（firmware）的資深開發者，無法承擔與構建 CRUD SaaS app 的開發者相同的「快速行動並打破一切」的方法。對於不同領域，「可接受的複雜度」的定義各不相同。

• 激勵機制問題： 通常，對複雜度的追求並非源於不確定性，，而是源於內部政治。有些領導者可能想要複雜的架構，因為它們對投資者看起來很吸引人，無論實際效用如何。

• 學習差距： 如果「速度版本」完全由 AI 和初級開發者處理，存在一種風險，即下一代開發者將永遠無法學習如何構建穩定、可擴展的系統。專業知識並非僅僅是一組事實，而是一種透過長期維護複雜系統的掙扎而建立的「世界模型」。

最終，資深開發者角色正在從編寫者轉變為編輯者。在一個 AI 生成代碼的無限量產時代，最關鍵的技能不再是產出，而是辨別什麼是必要的、什麼是穩定的，以及什麼是值得保留的。