為什麼人類跟不上 AI 寫程式的速度——專訪 Sonar 執行長 Tariq Shaukat

Sonar 執行長 Tariq Shaukat 主張，AI 讓程式碼產出變得充裕，但「信心」反而稀缺；代理式軟體工廠（agentic software factory）必須靠工程設計來交付可驗證的品質，而不是放任它自我檢查。整場演講大部分篇幅在系統性診斷當前 AI 治理為何失靈——包括人在迴路（human in the loop）、LLM 評審，以及代理在大規模程式碼庫上的表現——接著才帶出 Sonar 的四要素「程式碼信心公式」，以及 Sonar Vortex 與 SonarQube 兩項產品的客戶實績。

Shaukat 是以一家程式碼驗證公司負責人的身分發言，因此他把驗證定位為核心瓶頸，同時也是自身的商業立場。整場演講建立在一個豐田生產體系的類比、五項他明確點名的代理式開發限制，以及一連串引用研究（METR、PayPal、Meta，以及 Sonar 自家的開發者調查）之上，讀者可用來對照檢視自己的 AI 匯入計畫。

程式碼產量暴增，發布次數卻幾乎不動

Shaukat 的核心論點是：軟體交付的瓶頸已經翻轉。他引用 2026 年 9 月發表、關於開發生命週期中非同步代理的研究指出，撰寫的程式碼行數增加 2,450%、提交次數增加 240%，但發布次數只成長 30%。瓶頸已從「產出程式碼」轉移到「有信心地把程式碼送上線」。

他預告 Sonar 將於 2026 年 11 月發布的「程式碼現況」開發者調查：受訪開發者中 5% 表示目前已在執行代理式軟體工廠，34% 預期一年內會跟進，金融服務業則達 39%。這場演講的目的，是要論證打造這類工廠需要刻意的工程設計，而不是把代理硬接上既有的流程就算了。

「程式碼充裕，信心稀缺。」

豐田的工廠原則早已落實在軟體業——代理卻破壞了它們

Shaukat 把現代軟體實務追溯到豐田生產體系。他回顧 1980 年代：美國車品質不差，但鈑金件就是對不齊，Lexus 甚至拍了一支廣告，讓鋼珠沿著車身接縫滾過。他說，隨之而來的轉變，是從「先衝產量、有問題再修」變成「一次做對、不重工、讓客戶滿意」。

他列出他認為至今仍適用的原則，並指出敏捷、Kanban、SRE 的錯誤預算（error budget）與持續整合，全都源自這套思維：

他的論點是：代理對這些原則形成壓力，而不是取代它們。Shaukat 引用薩提亞·納德拉在 X 上的一則貼文——他是在演講前那個週末寫簡報時讀到的——文中呼籲「以工程方法處理圍堵與治理，建立在強健的決定性系統設計、人為控制與可靠作業程式之上」。Shaukat 說這段話讓他很有共鳴，因為代理式工廠需要的是把信心「設計進去」，而不是事後再檢驗。

五項限制，擊破「人在迴路」這道防線

Shaukat 最具體的貢獻，是條列出當前 AI 治理實務為何失靈。每一項都有具名的研究或資料佐證。

1. 人在迴路無法規模化。 他問過的每一家公司都說自己的 AI 治理有納入人工把關。但程式碼產出增加 2,450%、發布只增加 30%，人工審查根本跟不上。更糟的是，演講前約兩個月（約 2026 年 8 月）的一份研究發現：AI 答對時，人類有 93% 的機率同意；AI 答錯時，人類仍有五分之四的機率照單全收。他稱之為「認知投降」（cognitive surrender）。

2. 代理難以駕馭大型程式碼庫。 在一項程式碼翻譯研究中，代理在 1 萬行程式碼時準確率達 91%，但到了 5 萬行，準確率就腰斬。另一項研究發現，在同一個大型程式碼庫上完成相同任務所需的 Token 數差距達 30 倍（不是 30%），因為代理得耗費大量 Token 在摸索程式碼結構。他的比喻：從洛杉磯開車到紐約，若從 White Plains 出發很快；若從 Albuquerque 出發，又慢又貴。

3. 誤差會複利累積。 METR 發表於官網的研究，衡量代理能否完成人類需要若干小時的任務。最新的 Claude Mythos 預覽版能處理人類需 16 小時的任務——但準確率只有 50%。準確率到 80% 時，曲線就明顯趨平。他的算術是：單步準確率 95%，經過 20 步後，端到端準確率只剩 36%。

4. LLM 是追求獎勵、不可靠的評審。 PayPal AI 研究實驗室 2026 年 10 月發表的論文發現，在「完全相同的重複實驗」中，有 7–17% 的判定會改變，比例視模型與情境而定。Meta 的研究則發現，一句簡單的質疑（「你確定嗎？」）就能讓 LLM 的答案翻轉 7–34%。同一個 AI 評審問兩次，可能得到兩個答案。

5. 從漏洞到被利用的時間趨近於零。 Shaukat 認為這點不言自明，未多加闡述：攻擊者的動作比防禦者來得快，因此防護必須設計進工廠本身。

程式碼信心公式：四個因子相乘

Sonar 的框架把信心視為乘積而非加總：意圖 × 引導軌 × 驗證 × 證據。任一因子為零，信心就是零——例如什麼都做對了，卻拿不出可稽核的證明。

flowchart TD
    A["清晰明確的意圖"] --> E["對交付成果的信心"]
    B["引導軌，而非護欄"] --> E
    C["獨立且徹底的驗證"] --> E
    D["可稽核、可重複的證據"] --> E
    A -->|"因子為零"| Z["信心為零"]
    B -->|"因子為零"| Z
    C -->|"因子為零"| Z
    D -->|"因子為零"| Z

他刻意區分「護欄」（guard rail）與「引導軌」（guide rail）：護欄是防止車子衝出路面，引導軌則是讓車子留在路面上。他說，代理需要的是小幅度的導正，讓它保持在軌道上，而不是硬性阻擋。

Sonar 產品證明：導正與驗證帶來可量化的效益

Shaukat 把兩項 Sonar 產品對應到公式，並報告客戶實績。

Sonar Vortex 提供意圖與引導軌，在代理迴路內執行驗證。在大型複雜程式碼庫的長時間任務上，他報告 Token 成本降低 36%——因為代理被放在「White Plains」，離答案很近，不必耗費 Token 重新摸索地圖——提交階段的問題數則減少 92%。

SonarQube 是驗證層，Shaukat 稱之為公司的起點（「我們一開始就是一家驗證公司」）。其做法是決定性的混合方法：能用 CPU 就用 CPU，需要 GPU 才用 GPU，再結合代理式的混合方法。在一項超過 1,000 名客戶的調查中，相較於非使用者，SonarQube 使用者回報：

證據，才是讓人晚上睡得著的原因

第四個因子「證據」，Shaukat 說這才是讓一座能運作的工廠變成「站得住腳」的工廠的關鍵。通過品質關卡、產出一致、可稽核、可重複的證明，主管才有辦法向高階經營層、客戶、股東與董事會說明工廠運作正常。他點名證據可能必須滿足的標準：內部控制與營運中的 IT 一般控制（IT general controls），以及車用軟體的 MISRA 等，族繁不及備載。

「產出證據，才是讓你晚上睡得著的原因。」

值得觀察的重點

這場演講本質上是一位廠商執行長的主張：在代理式開發中，稀缺資源是驗證而非生成——這個立場恰好對 Sonar 的產品線有利，而且客戶統計數字來自 Sonar 對自家使用者的調查，並非獨立基準。他引用的外部研究（METR 的準確率曲線、PayPal 的評審變異論文、Meta 的質疑翻轉發現）是比較可移植的證據，值得直接找原文來讀。兩個值得追蹤的資料點：Sonar 2026 年 11 月調查中，代理式軟體工廠採用率從 5% 成長到 34% 的預測是否成真；以及隨著驗證工具成熟，30% 的發布成長率能否追上 2,450% 的程式碼成長率。尚未化解的張力在於：Shaukat 自己的公式仰賴人類給出清晰的意圖——而「認知投降」研究顯示，當 AI 出錯時，正是這群人的判斷力會失準。