當 coding 越來越便宜，我們該如何工程化「共識」？

這篇是討論筆記，不是結論。

一句話版本：當 coding agent 執行得越來越可靠，整條流程裡最不可靠的一段，可能變成人寫給它的 specification；而還沒被工程化的，是 agent 開始之前的理解與共識。

起點是我最近在 harness 上做的事，終點是一堆我還答不出來的問題。中間則是我跟手邊的 coding agent 一路來回攻防的過程。

先記下來。

系統裡最不可靠的那一段，可能換位置了

過去一年，我花了很多力氣在 harness 上：先讓 agent 理解 repository、再規劃、改完跑測試、查 regression、做 code review、失敗了重新規劃。

從零打造、再砍掉一半，這兩篇其實都在處理同一件事：只要願意多付出一些計算、token 和時間，agent 的執行過程確實可以被限制得越來越可靠。

但這也讓我開始注意到一個奇怪的問題。

如果 agent 執行任務已經越來越可靠，那整個系統裡最不可靠的部分，會不會反而變成人類寫給它的 specification？

換句話說，如果我們一開始根本沒有把事情講清楚，那 agent 執行得越好，也可能只是越有效率地把錯的東西做出來。

回頭看我自己的 harness，Stage 1 其實一直有一道「人類輸入 gate」：planner 會列出需要人拍板的問題，問題沒有清空以前，不准開始拆 feature list。

這道 gate 一直都在。

但它也是整套流程裡最沒有被工程化的一環。

Gate 後面的每一步都有 sensor、有 trace、有硬邊界；gate 本身往往只是一個人看一眼，然後說：

可以。

這開始讓我懷疑：我們是不是把大量工程力氣花在了 gate 後面，卻沒有認真處理 gate 本身的可靠性？

「Approved」不等於「我們有共識」

今天多數 coding agent 的工作流程，仍然從一張 GitHub issue 或 Jira ticket 開始。

Issue 裡可能有需求、背景、acceptance criteria、implementation notes、edge cases、過去的討論，然後 agent 讀這些文字開始工作。

這裡隱含了一個很大的假設：

這張 issue 已經準確表達了大家真正想做的事。

現實未必如此。

寫 issue 的人腦中有一個 mental model，變成文字時損失一部分；另一個 engineer 讀完以後，產生自己的版本；agent 再讀一次，又形成第三個版本。

Author's intent
      ↓
Written issue
      ↓
Reviewer's understanding
      ↓
Agent's understanding
      ↓
Implementation

每一層都可能有 information loss。

而我們目前把大量工程力氣花在最後一段，也就是：

Agent's understanding → Implementation

卻比較少問：

Human intent → Shared understanding

這一段到底可靠不可靠？

想像有人丟給你一張很長的 ticket，十幾段文字、一堆 acceptance criteria、幾十條 comments，然後問：

Looks good?

你看了一下，大致理解，回答：

LGTM.

從流程上來說，consensus 已經產生了。

但其實這裡有兩種完全不同的「同意」。

第一種是：

我沒有看到明顯的問題，所以我同意。

第二種是：

我理解這個 change 要把系統從什麼狀態變成什麼狀態，也知道什麼不會變。我確認這就是我們要的。

後者才是我真正關心的東西。

我暫時把它叫作 informed consensus。

這件事以前就重要，但在 coding agent 時代可能更重要。

以前一張模糊的 issue 交給 engineer，他可能花兩天實作，中間不斷回來問問題。現在同樣的 issue 交給 agent，兩分鐘後它可能已經開始修改幾十個檔案。

Implementation 越來越便宜之後，「我們到底有沒有先確認要做什麼」這件事，在整個成本結構裡就會變得越來越顯眼。

第一塊踏板：UML 會不會復興？

我最早想到的是 UML。

原因很簡單：討論 software design 時，我一直覺得 sequence diagram 很有用。

同一段 payment retry 的流程，如果寫成自然語言，可能要好幾段；畫成 sequence diagram，幾秒鐘就能形成 mental model。

UML 過去的問題是生產和維護成本太高。

人要學、人要畫、code 改了以後要記得更新。最後 diagram 和 code 不同步，engineer 開始不相信 diagram，然後又回到：

Just read the code.

AI 改變了這個 cost structure。

未來可能變成：

Human conversation
      ↓
Agent generates diagram
      ↓
Humans review
      ↓
Agreement
      ↓
Coding agent implements

人甚至不一定需要會畫 UML。

Agent 負責產生 representation，人只要看懂並確認：

對，這就是我要的。

所以我一開始覺得，UML 也許會重新成為人和 coding agent 之間很好的 intermediate representation。

但繼續想下去以後，我開始懷疑自己。

我們很容易假設：

圖比文字容易理解。

但這不一定是真的。

UML 本身也是一種語言。

簡單的 sequence diagram 可能很直覺，但複雜的 class diagram、state diagram 一樣需要學習。AI 把「畫 UML 的成本」壓到接近零，不代表「讀懂 UML 的成本」也接近零。

這讓問題轉了一個彎。

我真正想解決的從來不是：

該用 UML 還是自然語言？

而是：

對一個特定的 change，什麼 representation 可以讓相關的人用最低的認知成本，建立足夠正確的共同理解？

UML 只是候選之一。

其他還有 natural language、before/after、given/when/then、examples、state machine、API contract、executable tests。

不同的 change，可能該用完全不同的 representation。

而 AI 的價值也許正是在這裡：我們不需要先決定 representation，AI 可以幫我們選。

Current state 和 change intent 是兩件不同的事

還有一個區別值得先分開。

軟體系統其實需要兩種不同的 representation。

第一種描述：

系統現在是什麼樣子？

這是長期存在、隨著 codebase 演化的 current state model。

另一種描述：

我們準備改變什麼？

這是一張 issue 真正在做的事，我暫時叫它 change model。

Current state
      ↓
Change proposal
      ↓
Human consensus
      ↓
Agent implementation
      ↓
Verification
      ↓
New current state

Change model 不需要永久存在。

它的任務只是讓相關的人確認：

對，這就是我們同意要發生的 change。

然後 agent 執行。

做完以後，target state 成為新的 current state。

這比試圖把整個 codebase 完整 UML 化現實得多。

第二塊踏板：30 秒

如果真正稀缺的是 human attention，那是不是該給 issue 一個 attention budget？

例如：

一個 engineer 應該能在 30 秒內理解一張 issue 的 change intent。

重點不是 30 秒。

30 秒只是一個刻意激進的數字。

重點是第一次把 human attention 當成 engineering constraint。

不是要求人在 30 秒內理解 implementation，也不是理解所有 edge cases，而只是理解：

What is changing?

例如：

Retry payment once on timeout

Order Service       Payment Service
      |                     |
      |------ Pay --------->|
      |<----- Timeout ------|
      |------ Retry ------->|
      |<----- Success ------|
      |-- Complete Order    |

Rules:
  Retry only on timeout
  Maximum retry: 1
  Never retry declined payment

如果相關的人都能快速回答：

我知道你要改什麼，而且我同意。

Agent 才開始工作。

然後開始攻擊自己的想法

30 秒可能製造 illusion of understanding

還是 payment retry。

大家看到：

timeout → retry once

全部點頭。

但一個 engineer 可能馬上問：

什麼叫 timeout？

TCP timeout、HTTP 504、還是 SDK timeout？

如果 payment 其實已經成功，只是 response 丟了呢？

Retry 會不會 double charge？

Payment API 是 idempotent 的嗎？

突然間我們發現，30 秒之所以容易理解，也許只是因為真正困難的資訊被刪掉了。

Compression 可以降低 cognitive load。

但 compression removes information。

如果被刪掉的是 decision-critical information，我們只是讓所有人更快達成一個錯的共識。

所以目標絕對不能是：

把 spec 壓到 30 秒。

真正的問題應該是：

在不損失關鍵決策資訊的前提下，change intent 能壓縮到什麼程度？

有些複雜度根本不能被壓縮

重複的文字、不必要的背景、混亂的結構、歷史 discussion，這些是可以被減少的 accidental cognitive load。

但 authentication、distributed transaction、migration、backward compatibility 本來就複雜。

這是 intrinsic complexity。

AI 可以幫我們減少前者，卻不能假裝後者不存在。

真正值得研究的問題是：

How do we minimize accidental cognitive load without hiding intrinsic complexity?

這已經比「30 秒 issue」嚴格很多。

拆小也不一定是答案

一個 change 無法在 30 秒內理解，很自然會想把它拆成幾個小 change。

每個都很好懂。

但局部都理解，不代表整體被理解。

A → B 看懂了。

B → C 看懂了。

C → D 也看懂了。

最後卻沒有任何一個人理解 A → D 的整體行為。

如果真的存在這種 agreement unit，它大概必須是 hierarchical 的：

          Change narrative
                 │
      ┌──────────┼──────────┐
      ↓          ↓          ↓
   Unit A      Unit B      Unit C

先理解整體 intent，再進入自己需要確認的局部。

Atomic comprehension 不能取代 system-level comprehension。

甚至 shared mental model 可能就是錯的目標

為什麼每個人一定要擁有一樣的 mental model？

Product manager 不需要理解 cache invalidation。

Security engineer 不需要理解 UI animation。

Backend engineer 也不需要知道每一個 product detail。

真正需要的也許不是：

Everyone has the same mental model.

而是：

Everyone has a sufficient and compatible mental model.

這兩個差很多。

AI 甚至可能對同一個 change 產生不同的 view：

                 Change
                   │
        ┌──────────┼──────────┐
        ↓          ↓          ↓
     Product     Backend    Security
       View        View        View
        │          │          │
        └──────────┼──────────┘
                   ↓
          Compatible consensus

PM 看行為。

Backend 看 sequence。

Security 看 trust boundary。

大家看到的東西不一樣，但對關鍵 intent 和 constraints 沒有衝突。

這可能才是真正的 consensus。

最強的反方：既然便宜，先做再看不就好了？

這是我覺得最難接的一個反駁。

Coding 便宜的另一個推論，就是試錯也變便宜。

既然 agent 三分鐘能做出來，何必在做之前折騰 representation 和共識？

讓它先做。

跑起來的行為、測試、demo，甚至 diff，本身就是最誠實的 representation。

不對就丟掉重來。

我想過以後，覺得它有一部分是對的。

對小的、可逆的 change，implementation 本身可能就是最好的 change model。任何 diagram 都比不上一個能點的 demo。

但它沒有解掉問題，只是把問題搬了位置。

第一，你還是要有人看。

看 diff、看 demo、判斷「這是不是我們要的」，一樣需要 human attention。而且對 non-trivial change，看一份幾十個檔案的 diff，可能比看一張好的 change model 更貴。

第二，做出來的東西會產生 anchoring。

一個已經跑起來的 implementation，很容易讓 reviewer 從：

這是不是我們真正要的？

滑向：

這個版本可不可以接受？

先做再看，很容易最後變成先做再同意。

第三，有些 change 根本不能隨便試。

Schema migration、對外 API、計費邏輯、任何有 side effect 的東西，「不對就丟掉」這個前提本身就不成立。

所以繞了一圈，問題還是在：

在做出決定的那個點上，人到底需要投入多少 attention 才夠？

先做再看只是改變了 representation 從哪裡來。

甚至也許最好的 change model，不是事前寫出來的，而是 agent 先產生一版 disposable implementation，再從 diff 和行為反推、壓縮成一個 representation 給人確認。

這條路我還沒試。

但它反而讓我更確定：真正值得研究的不是某一種特定 representation，而是 decision point 前的人類理解成本。

目前走到的地方：Minimum Viable Consensus

暫時給這個東西一個名字：

Minimum Viable Consensus，MVC。

在 coding agent 被允許執行一個 change 以前，相關的人至少需要知道什麼，才能安全地說：

我理解，而且我同意做這件事。

這裡的 minimum 很重要。

它不是 maximum understanding。

不要求所有人理解所有 implementation details。

它找的是 sufficient understanding。

少於這個點，風險太高。

超過這個點，可能只是在浪費稀缺的注意力。

於是 software engineering pipeline 多出了兩個值得被工程化的 stage：

Intent
  ↓
Representation
  ↓
Comprehension
  ↓
Consensus
  ↓
Execution
  ↓
Verification

今天大部分 harness engineering 集中在最後兩個。

Agent 越來越強以後，也許該開始認真處理中間兩個。

這也讓我重新想 AI 在這裡扮演的角色。

我們一直在問 AI 能產生多少 code。

但也許另一個同樣重要的能力是：

AI 能不能把複雜的 software intent，轉成最適合某一個人理解的 representation？

這不是 summarization。

Summary 按長度最佳化。

這裡真正要最佳化的是：

每單位 human attention，可以換到多少 decision quality。

AI 可以讀 customer conversation、requirement、architecture、existing code、past decisions、tests、constraints，然後對 PM 產生一個短的 behavior change，對 backend 產生 sequence diagram，對 security 產生 trust-boundary change。

如果 change 本身太複雜，AI 甚至應該拒絕繼續壓縮：

This change cannot be safely represented within the requested attention budget.

這裡真的需要五分鐘。

這反而是一個好的結果。

當 coding 越來越便宜，什麼會變貴？

過去最昂貴的資源之一，是 engineer 的 implementation time。

一個 feature 可能需要幾個 engineer 做幾天甚至幾週，所以 requirement discussion 花幾個小時，並不顯眼。

但如果 implementation 從三天變成三十分鐘，再從三十分鐘變成三分鐘，specification、review、decision、alignment 和 human attention 在整個成本結構裡所佔的比例就會越來越大。

瓶頸可能會從：

多快能做出來？

逐漸轉成：

我們到底同不同意要做什麼？

我們已經開始用 harness、evaluation、tracing、testing 和 verification，系統性地提高 agent reliability。

下一步，也許該問：

我們能不能同樣系統性地測量和工程化 human consensus？

下一代 harness 不該只管 agent 開始 coding 之後發生的事。

它也許還應該管：

Agent 被允許開始 coding 以前，人到底有沒有達到足夠的理解與共識？

還答不出來的問題

• 對誰、用什麼 representation 才有效？ 同一個 change，sequence diagram 對 backend 有用，對 PM 未必。這件事有沒有可以歸納的規律，還是只能逐案讓 AI 猜？

• 「足夠的理解」怎麼量？ 如果要做實驗，目前我想到的一種方式是 prediction task：看完 representation 後，回答「輸入 X 時系統會怎樣」、「哪個 component 應該改」、「哪個 constraint 不能被破壞」，再跟 ground truth 對照。但這真的足夠代表 understanding 嗎？

• Attention 和 decision quality 的關係長什麼樣？ 15 秒、30 秒、60 秒、2 分鐘、5 分鐘，理解正確率會怎麼變？是否存在一個明顯的 diminishing return point？

• 拒絕壓縮的門檻怎麼定？ AI 說「這個 change 需要五分鐘」的依據是什麼？誰來校準它？

• 先做再看和先同意再做，邊界在哪裡？ 可逆性顯然是一個變數，但可逆性本身又應該怎麼判斷？

• 局部 consensus 和 system-level understanding 怎麼一起維持？ 如果大型 change 被拆成多個 agreement units，誰負責保證整體 narrative 沒有在拆分過程中消失？

這些目前都還沒有答案。

但我越想越覺得，當 coding agent 讓 implementation 越來越便宜以後，真正稀缺的東西可能會慢慢換位置。

不是 code。

而是 human attention。

以及用這份 attention 換來的 informed consensus。