「只會說不」工程師的興衰：ZIRP 現象

在軟體工程的層級制度中，存在著一種獨特的原型： 「只會說不」的工程師。這種工程師通常出現在資深（senior）或參謀（staff）級別，扮演著技術守門人的角色。他們的主要功能是放慢進度、阻擋會引入不必要複雜性的功能，並秉持著「每一行程式碼都是負債」的哲學，確保程式碼庫保持盡可能精簡。

多年來，這個角色不僅被容忍，甚至受到讚賞。然而，隨著經濟環境轉變，以及 AI 生成的程式碼充斥著儲存庫，這種「只會說不」的工程師發現自己正與新的企業現實產生衝突。要理解其中的原因，我們必須超越目前的 AI 熱潮，去檢視最初催生出這個角色的宏觀經濟力量：ZIRP 時代。

ZIRP 時代：工程界的遊樂場

ZIRP，即零利率政策（Zero Interest Rate Policy），描述的是 2008 年至 2022 年間的時期，當時近乎零的利率讓科技公司能夠以廉價取得資本。在那個時期，激勵機制是「不惜一切代價追求成長」。公司規模從數十人擴張到數千名工程師，通常資助那些與即時營收關係不大的低風險、高回報專案。

在這種環境下，「只會說不」的工程師成為了關鍵的安全閥。隨著大批工程師被賦予實驗權限——這往往導致像是「拔毛」（yak shaving）般的行為，例如遷移到自製的資料庫或無止盡的技術重構——公司需要一種方式來防止系統在自身野心的重量下崩塌。

擁有一位主要價值在於說「不」的資深工程師，具有以下幾種用途：

• 風險緩解： 它能防止不具生產力或過度野心的工程師影響到業務關鍵系統。
• 人才品牌化： 在招聘狂潮中，透過維持極高技術門檻的聲譽，有助於公司吸引頂尖人才。
• 管理緩衝： 管理層通常會聽從這些工程師，將他們的「不」作為擋箭牌，以避免做出困難的產品決策。

大規模重新校準

當利率上升時，經濟計算立即發生了變化。 「針對成長而成長」的時代結束了，公司被迫將實際營收置於比為了提升股價而增加的人力成本之上。這導致了廣泛的裁員，以及對營運專注度的急劇提升。

突然之間，曾經作為程式碼庫頂端掠食者的「只會說不」工程師，發現自己迷失了方向。在一個公司正拼命追求新功能以求生存的世界裡，阻擋與放慢進度的文化不再被視為美德，而被視為瓶頸。

曾經隱含支持守門人的管理層，現在正積極地否決他們的決定。壓力已從「確保這件事很完美」轉向了「找個方法說可以」。先前因維持高標準而獲得高度評價的工程師，現在卻被告知要成為「團隊合作者」。

AI 的複雜化因素

雖然轉變是經濟性的，但大型語言模型（LLMs）的興起為心理與專業壓力增添了一層。 「只會說不」的工程師現在正面臨 AI 生成程式碼的巨浪。更具挑釁性的是，這些程式碼有時是由管理層和副總裁（VPs）提出的，他們利用 AI 來繞過傳統的工程審查流程。

諷刺的是，如果 ZIRP 時代持續下去，LLMs 會讓「只會說不」的工程師變得比以往任何時候都更有力，因為他們將成為抵禦抵禦平庸庸 AI 程式碼洪流的唯一防線。然而，目前的 AI 工具正被證明對於當前快速節奏、實驗性的環境是「足夠好」的的。程式碼可能沒那麼乾淨，但它交付速度更快，且在一個公司正快速轉型的市場中，速度往往比長期的純粹性更重要。

反對觀點：守門人是否仍有必要？

並非所有人都認為「只會說不」原型 de 僅是廉價資金的產物。有些人認為，當資源稀缺時，能力說「不」比以往任何時候都更重要。

「在 LLMs 時代，對那些容易實作但無法增加價值的糟糕功能說「不」的能力，比以往任何時候都更重要，」一位批評者指出。

其他人則建議，這個角色已經演變了。這裡的關鍵在於「純粹」與「非純粹」工程的區別。純粹工程——例如開發編譯器、執行環境（runtimes）或核心基礎設施——仍需要高標準的品質與更緩慢、更深思熟慮的步調。而非純粹工程——例如面向客戶的功能與快速原型開發——則需要「只會說yes」的心態來達成產品與市場契合度（product-market fit）。

在新時代生存

對於那些認同守門人原型的工程師，未來的路徑需要身份的轉變。單純阻礙進度的「大師」正在成為一種負債。為了保持價值， 「只會說說不」的工程師必須轉型為「先思考一下再說」的工程師——不僅僅是阻擋一個提案，而是提供一個可行且複雜度較低的替代方案。

正如一位讀者深刻地分享，許多人正處於十字路口：要麼降低標準以博取管理層的青睞，要麼冒險留在一個被認為是阻礙主義者的泡沫中。現實是，技術守門人的角色在許多方面上，都取決於一個非常特定且奇特的經濟窗口期。隨著該窗口期關閉，產業正朝向一個模型，即辨別力是受歡迎的，但速度是強制性的。