Tenex 如何打造 AI 原生軟體開發生命週期：為財星兩千大企業加速 AI 轉型

去年，Alex Lieberman 和他的共同創辦人向我們解釋了 Tenex 的獨特策略：根據 AI 工程師交付的工作成果而非投入的工時來支付薪酬。如果 AI 讓工程師工作更快，按時薪計費反而會讓他們為相同的工作賺得更少，而 Tenex 希望激勵機制能反向運作。

在 AIE New York 活動上，Alex 與 CJ Hess 回來討論如何將這個理念擴展到整個工程組織。我們也提出了一個自己的實驗「Kill My SaaS」，要求開發者取代一個每年報價 43,000 美元的會議講者管理工具。這兩個故事都引出相同的問題：當開發成本變得更低時，我們該如何評估一份好工作的價值？

Tenex 仍然將「故事點數」（story points）作為工程師薪酬的重要組成部分。Alex 表示，人們擔心的失敗模式，例如虛報估算或為了累積點數而交付劣質程式碼，並未成為最大的問題。Tenex 的 AI 策略師負責客戶留存與成長，這促使他們會拒絕不符合客戶需求的工作。

更困難的問題是如何獎勵那些無法明確歸類為任務的工作，例如理解客戶問題、設計架構，或決定最初應該開發什麼。CJ 描述隨著模型越來越好，他花在直接編碼的時間減少了，而更多時間用於將客戶情境轉化為模型可用的形式。一個以交付任務為核心的薪酬系統，也必須為這類工作預留空間。

Alex 表示，Tenex 已成長至 75 人，客戶分佈在財星兩千大企業和中型市場公司之間。該公司最初是一家以 AI 驅動的開發工作室，但現在客戶越來越多地尋求整個公司的 AI 轉型協助。

CJ 介紹了 Tenex 的 MetaHarness，這是一個圍繞工作而建立的共享技能集、專案文件和命令列介面（CLI）。計畫和決策與程式碼一同提交到 Git 中。當一個代理（agent）回頭處理某項任務時，它不僅能讀取已建置的內容，還能理解團隊為何選擇那樣建置。

Tenex 自己的 AI 原生 SDLC 文章將這個概念展示為一個專案記錄，人類和代理都依此工作，並能查看 Linear、GitHub 和客戶更新。

有用的區別在於，讓代理更快地編寫程式碼，與讓周邊工作（如計畫、驗收標準、決策和證據）變得清晰可讀。Tenex 的文章也指出其成本：過多的結構對於一個小型專案團隊來說可能過於繁瑣。

我們的「Kill My SaaS」專題收到了 72 份提交，旨在取代我們的講者管理軟體。由人類評審選出的獲勝團隊，在 AI 評審的排行榜上僅排名第 19。這提醒我們，檢查軟體是否符合一系列情境與判斷人們是否想使用它，是兩種不同的工作。

我將這個專案作為一個公司選擇自行開發軟體的真實案例向 Alex 提出。他的反駁是：市場定位越高，替換既有系統的成本和風險就越大。即使是較小的工具，也需要有人維護。所節省的成本是否足以證明持續投入維護是合理的？

我的回答是，好處不僅僅是帳單上的數字。我們的團隊長期以來一直使用一個平庸的產品。如果我們擁有工作流程，就能為講者和營運人員改進它，並在幾分鐘內進行迭代，而不是等待供應商數月。這種潛力必須與 Alex 所描述的維護成本進行權衡。

Alex 對垂直領域的 AI 產品普遍持悲觀態度：如果每家企業都期望獲得獨一無二的解決方案，那麼如何以軟體利潤來交付？而且隨著前沿模型的改進，有多少底層任務會被通用工具所吸收？

我則以 Harvey 和 OpenEvidence 等例子反駁。即使底層模型對所有人開放，特定領域的數據、專業介面、整合和使用者習慣仍然很重要。Bloomberg 是一個很好的比較：交易員可以在其他地方獲取市場數據，但其終端機將數據、工作流程、通訊和既有習慣整合在一起。

CJ 區分了兩種垂直產品：一種是主要功能由代理執行任務的產品，另一種是改進該任務實際工作流程的工具。這引出了一個比「垂直 AI」是贏是輸更有趣的問題：哪些產品會成為人們長期工作的地方，而哪些又會成為他們已經使用的代理的一個功能？