Originally published at devopsdiary.blog. Post R24 in "The Quiet Years" series.

這篇文章的草稿標題從四月就躺在我的發布日曆上：「我 60 天內建了 24 個倉庫」。每隔幾週我看一眼，那個數字又錯了。24 變成 30，然後是 41。60 天拉長成五個月。我一直沒有寫它，結果這成了我最好的編輯決定，因為在某個時刻，故事不再是關於數量。

這個數字確實存在，記錄在此。AIEOS（我在幾週前介紹的框架）現在有 41 個倉庫：一個 15 層的軟體交付生命週期模型、一個多代理程式架構、一個瀏覽器主控台、一個名為 Sherpa 的 CLI 指南、13 個工具配接器，以及一個能讓任務無人值守執行的控制平面。每個倉庫都在 CI 下執行。配接器產生已簽署的 Sigstore 證明。編排核心達到 100% 程式碼覆蓋率，在 Windows 和 Linux 上都有 452 個測試通過。

但值得問我的數字是另一個：零。這是 7 月 1 日我稽核時，配接器符合性通過的次數，在兩個月的綠色勾勾之後。這兩個數字之間的差距教會我的東西比 41 還多。

三月在奧馬哈是適合建造的天氣

天色灰暗，氣溫 34 度，沒別的事可做。

一月是九次提交，試探想法。二月是搭架子。三月是 358 次提交，跨越 24 個倉庫，其中 22 個在 1 號還不存在。到 4 月 9 日，所有八個管線層都已建好。當年有 580 多個 GitHub 貢獻，幾乎都在那段時間內完成。我從事軟體開發 30 年，從未以這種速度交付任何東西。沒有人能用手做到。

誠實的機制是：我幾乎沒寫程式碼。我寫規則、模板、提示和驗證器，然後讓模型根據它們生成，每個成品在下一個建立之前都會凍結。因此當人們問起 AI 輔助開發是否真的能達到大家吹噓的速度時，我可以從另一端回答。是真的。這對我來說從來不是問題。

問題是我三年來一直在問其他團隊的：你怎麼知道它們真的有效？

兩個月的綠色，零次真正通過

7 月 1 日，我去驗證一個據說已完成的配接器，發現管線中有東西引起我的注意。簽署步驟被跳過了。沒有紅色。只是被跳過。

把這條線索拉到所有 13 個配接器上，畫面就崩解了。每個符合性作業都在 continue-on-error: true 下執行，這項設定會強制步驟無論實際發生什麼都回報成功。簽署步驟被設定為必須真正通過才執行，結果在每個配接器的最新執行中都被跳過了。這樣的閘門只有在條件為假時才會跳過。符合性從未通過。一次也沒有。在任何配接器上。從來沒有。我在自己的文件裡描述的吃狗食迴圈根本不存在，而且什麼都不會告訴我。

根本原因幾乎是普通到可笑。有一個配接器的 CI 作業從未安裝 pytest，所以配接器沒有東西可以執行，四個條件全數失敗。另外 11 個讀取的輸入鍵，測試架構從未傳送。KeyError，在做任何工作之前，每次執行都發生，從四月底開始。

稽核後 12 天，我發布了一篇文章，採用 Sonar 的「驗證債務」一詞，用來描述代理程式產出與實際驗證之間的差距。我想記錄下來，我在撰寫這個定義時，正背負著兩個月的驗證債務。

修復從移除遮罩開始。在整個修復過程中，單一價值最高的變更是刪除一行 YAML：現在真正的通過才會簽署，真正的失敗才會中斷建置，而且是大聲中斷。接著是測試架構重新設計，讓每個測試套件宣告自己的輸入合約，並為需要容器映像或即時端點來證明自己的配接器提供真實的固定裝置。到 7 月 5 日，所有 13 個配接器都能從真正的通過產生已簽署的符合性證明。

BEFORE JULY 1 (masked)

  conformance fails
        |
        v
  continue-on-error: true
        |
        +--> step reports "success" --> green checkmark
        |
        '--> signing step (gated on a genuine pass):
             SKIPPED, every run. No attestation, ever.


AFTER (unmasked)

  conformance fails  --> build breaks, loudly
  conformance passes --> signed attestation uploaded

Enter fullscreen mode Exit fullscreen mode

一個 YAML 鍵，就是證據與裝飾之間的差別。被跳過的簽署步驟是管線中唯一誠實的訊號。

現在綠色有意義了。

框架不斷抓住它的作者

v1.3 在七月中發布時，我很喜歡其中的一個聲明：三個驅動程式（Sherpa 用於引導式工作階段、主控台用於點擊操作、「暗黑工廠」用於無人值守執行）共享一個引擎。然後我用真實模型在迴圈中執行第一次吃狗食，通過的執行也否證了這個聲明。主控台需要一個流程檔，而這個檔在框架中除了主控台自己的測試固定裝置之外根本不存在。它從未載入過真實的套件。三個驅動程式共享一個引擎只有兩個是真的，而我自己的驗證執行是我知道這件事的唯一原因。

同一次執行，發現了更糟的問題。執行 freeze-before-promote（框架的第二誡）這個函式有一整套測試，卻沒有任何生產呼叫者。測試得很徹底。從未被呼叫過。這個不變性仍然成立，但只是因為一個不相關的錯誤碰巧阻擋了相同的路徑。如果「安全屬性是由另一個缺陷維持的」這句話沒有讓你感到不安，請再慢慢讀一次。

同一週我在 CI 中加入了 Windows 執行器。它在開始存在的 45 秒後，就因為編碼差距而失敗，這導致測試套件第一次完全正確的 Windows 執行：435 個測試，沒有任何環境輔助。接下來兩天內關閉了十個差距，每個都是先用失敗的測試證明關閉，而不是在提交訊息中聲稱已關閉。追蹤它們的登記檔包含名稱、日期和證據，而不是形容詞。

這個速度真正買到什麼

五月時我寫道代理程式占工作的 20%，平台占另外 80%。我寫的時候是針對別人的代理程式。這也適用於我的，而我特別建構平台端，就是為了讓那 80% 不會是臨時拼湊的。

當人們問起五個月全速 AI 輔助建置是什麼感覺時，這就是我現在給的答案。生成是便宜的部分，便宜到倉庫數量不再有趣。綠色勾勾是某人設定的宣告。證據是經過試圖否證它而仍然存活下來的東西，而這兩者之間的距離，就是一個未經審查的 YAML 鍵。而一個不會在自己身上運行的治理系統，就是一份簡報。我的系統在七月抓到它自己的作者四次（被遮罩的符合性、幻影驅動程式、未執行的不變性、編碼錯誤），每一次抓到都讓人尷尬了大約一小時，之後就成為永久的負荷。

過時的標題把數量當成成就。五個月後，數量是組織中最無趣的成品。我真正想給你看的是 7 月 1 日的稽核，它指責我自己的勾勾在說謊，以及後來讓說謊在結構上變得困難的管線變更。AI 很樂意為你建立 41 個倉庫。但你能不能信任它們，仍然是你的工作。

Todd Linnertz is a Senior Solutions Engineer with thirty years of enterprise engineering experience. He's the creator of AIEOS, an open-source AI governance system for software delivery teams. Find him at devopsdiary.blog and github.com/wtlinnertz.