在人類歷史的絕大部分時間裡，我們一直透過程式碼審查來評估程式碼品質：有人會閱讀你寫的內容，並確保它乾淨、深思熟慮、快速、易於理解，而且測試表現良好。但對 Agent 來說，這種方法難以擴展；程式碼數量太多，沒有任何人能全部讀完。因此，越來越多的品質檢查必須發生在 Agent 周圍的框架（harness）、環境和作業系統中。我仍然會閱讀和審查程式碼，但對於自己在哪些地方願意以約束作為檢查手段，我會非常謹慎。
軟體品質現在取決於你為 Agent 設定的約束。
Guillermo 的清單是一個很好的測試，可以判斷你是否負擔得起略過閱讀。請注意，每一個「是」其實都在說明風險有多低——沒有使用者、拋棄式程式碼、原型。一旦風險提高，就必須有東西來閱讀程式碼。如果不是你在每次 diff 上親自查閱，那就必須靠約束來把關。
約束透過對 Agent 的提案施加測試和確定性的限制，來定義系統允許做什麼。正是透過設定和維護這些約束，我們才能建立可靠地交付高品質生產級軟體的迴圈，即使 Agent 每天產生數十萬甚至數百萬個變更也是如此。
我們把這些約束稱為品質門檻（quality gates），它們有許多形式。
它們包括傳統的單元測試、屬性測試和驗收測試。還包括突變測試（mutation testing），也就是我們產生程式碼的變體，用同一組測試去執行，以確保不會有人偷偷引入我們沒發現的錯誤。它們也包含程式碼品質的指標，例如圈複雜度和行長度，有助於讓程式碼保持可讀性。
兩個人可能對是否要閱讀程式碼意見相左，但仍然對機制達成共識。Guillermo 會閱讀程式碼。Bob 完全不讀。兩者描述的都是一套考驗關卡——差別只在於裡面是否坐著一個真人（我不認同 Bob 的其他觀點）。
約束在系統接受哪些提案並套用為程式碼變更方面，也扮演著重要角色。當一個變更提案從執行 Agent 的直譯器移動到 Agent 控制器，再進入正式環境時，我們已經對它做了足夠的檢查，足以確信它可以安全上線，而且變更的影響範圍完全在 Agent 的職責範圍內。
Agent 可以提出任何提案。你的約束決定一個提案是否夠安全、正確、範圍適切、有價值，值得你和你的團隊將它上線。
這個模型提供了很多東西，但也遺漏了許多部分，而這些遺漏值得我們今天好好思考。其中一個問題是自主性（autonomy）；Agent 可能很善於執行它們的意圖，但在資訊不足，或它們想做的事情含糊不清時，就可能失敗。這既適用於任務本身，也適用於框架、環境和其他元件如何將任務參數化。
人類無法交付優秀程式碼的許多原因，也同樣會發生在 Agent 身上：脆弱的環境在腳本驅動的壓力下撐不住、非確定性的建置、缺少權限，以及薄弱的測試。這促使我們打造一個更好的環境，它能給 Agent 值得信賴的回饋、允許低傷害的失敗模式，並讓我們更容易逐步累積成功。
我們追求的環境，是讓 Agent 可以做真正的工作、獲得它可以信賴的回饋，並且在失敗時不會造成太大傷害。
另一個重要問題是信任。我們不能不加思索地把意圖交給某個系統——即使它像現代 Agent 一樣聰明且強健——卻不檢查它的正確性。我們以信任為出發點，但信任必須是靠努力贏得的。
有些約束在工作開始之前就先塑造了它。有些約束在 Agent 工作時提供回饋。還有一些約束則決定它的輸出究竟能不能跨越正式環境的邊界。
有許多方式可以規劃我們如何在系統周圍建立驗證結構。
根據我的經驗，為你的約束準備一套更廣泛、但經過刻意挑選的檢查會很有幫助，而不是只依賴單元測試。概念是每個檢查都有獨特的職責，範圍可以從型別安全和效能，一直到後期的安全掃描。人們也可以定義自己的約束，包括 ESLint 這類 lint 工具可以強制執行的架構規則。許多這類工具都有內建的掛鉤（hooks），可以在出問題時把 Agent 或真人拉進來。
就目前而言，有用的 Agent 輸出與劣質內容之間的差異，仍然很大程度取決於操作這個迴圈的團隊的功力。
AI 為我們帶來了大量的程式碼生成和速度，但這也意味著人類要審查每一個變更變得更加困難。你必須有意識地決定人類的注意力要放在哪裡。如果你在一個以機器速度運作的系統中放入人工檢查，別驚訝那會影響生產力。人類的注意力是稀缺且有價值的，所以我們應該主動把它引導到那些最細微、最需要我們判斷力的問題上。下游的人類只應該在約束的自動化護欄失效時才被拉進來。
未來人類的「程式碼審查」將會非常不同
正確性是一個重要的面向，但你可能也在乎其他面向，例如可維護性、效能、安全性、效率和易理解性。就像正確性可以分解為許多訊號類型，品質的其他面向也是如此。雖然我們設定了多少約束很重要，但更重要的是這些約束是否夠嚴格，足以達到我們對品質和上線就緒度的標準。
軟體品質不是單一指標。把它想成是一組訊號的集合，每個訊號對你和你的團隊的重要性各不相同。
背壓（back-pressure）可以透過許多工具來實現：編譯器拒絕無效程式碼、測試失敗、安全政策阻止不良做法、CI 拒絕部署。理想情況下，它應該存在於整個迴圈中，而不是在全部工作結束時才做一次審查。
Dex Horthy 對同一個迴圈所繪製的圖，出自《為什麼軟體工廠會失敗》（Why Software Factories Fail）。綠色方框代表他的論點：現階段人工審查應該重新回到迴圈中，而不是被迴圈取代。
約束和背壓讓 Agent 能在壞作品變成問題之前就抓住它
如果變更的數量超過我們工具能處理的範圍，導致我們無法套用約束，會發生什麼事？我們最後會建立一個佇列，並依賴一個以人類速度運作的驗證系統。為了擴展，我們希望在整個過程中盡可能把更多工作推入驗證迴圈，而不是等到最後。如果我們能在自動化檢查的範圍內擴展，就能提高整個交付系統的速度和吞吐量。如果驗證迴圈沒有多餘空間了，我們就需要做以下幾件事之一。
首先，我們可以擴展驗證系統，建立更多容量來約束和推回進來的變更。其次，我們可以降低 Agent 產生新變更的速度，讓驗證系統能趕上工作量。第三，我們可以降低品質標準，讓驗證系統不會像原本那樣強力推回。從擴展的角度來看，我們需要準備好做所有這些事情。同時，我們也應該充分認識到：在某些方向上解除約束，實際上可能讓我們完成更多工作。也許我們可以提供成群結隊的 Agent 開發者或自動化軟體工廠來產生變更，而不必等待我們逐一審查，藉此提高 Agent 產生變更的速度。
而在某些地方，我們可能想給它們更多自由，只要我們在其他地方保持更嚴格的約束。透過在我們最在乎的地方提供更嚴格的約束，我們可以在不犧牲品質的情況下最大化吞吐量。在這些決策中有很多選項。最明顯的是，我們必須在不同面向的品質之間取捨。正如我們所強調的，安全性非常重要，但我們也一直在「交付安全性」和「按時交付產品」之間取捨。這是一個從「創新導向」到「品質導向」的光譜。我們必須在這條光譜上做出選擇，決定自己想要的定位。
我們希望把環境和系統的清晰回饋傳回給我們的 Agent 或團隊，這樣人們就能專注於品味、意圖和架構等更主觀的考量。如果我們能幫助人類保持在約束的安全範圍內，就能避免他們費盡心力去弄清楚哪裡出了問題。
軟體品質不僅僅是正確性。軟體品質也意味著可維護性、良好的效能、安全性、效率，以及易於理解。所有幫助我們達到這些標準並保持生產流暢的約束，都會在我們的交付管線中產生背壓。
我們需要做出深思熟慮的決定：在哪裡施加嚴格的約束，在哪裡移除或放寬它們。在這些約束能同時服務這兩個目標的地方，施加嚴格的約束。如果它們無法服務其中任何一個目標，就不要支持它們。準備好視情況提高或降低標準。請記住，軟體系統中不同位置的這些約束，正是讓軟體品質得以被強制執行的關鍵。
我們應該在能最好地服務這個雙重目的的地方施加嚴格約束，並考慮移除或放寬那些無法良好服務任何一個目的的約束。我們也應該準備好視需要調高或調低品質標準。實際上，正是我們軟體系統中各個位置的這些約束，讓品質真正有了強制力。在許多情況下，我們可以透過部署新工具或強化現有的工具，來創造更多背壓和更多約束。所有這些都可以用來推回大多數的變更請求。我們希望在整個管線中建立它們。
我們不想等到管線的末端，讓 CI 系統只是告訴我們：不修好問題就不允許部署。我們希望盡可能早地使用這些訊號，透過每一條可能的途徑。這個系統中最終極的約束，是我們加諸於自身的約束：為建立和操作這個系統所做的決定與行動負責。但就像所有其他約束一樣，我們需要深思熟慮地權衡：我們希望自己的判斷在多大程度上發揮約束作用、施加背壓，並作為最終檢查。
品質就在我們為 Agent 設定的約束之中。所以當你在思考自己應用程式的品質時，以這個問題陳述為起點，提出一份屬於你自己的、由約束驅動的計畫。
說到品質，Agent 正在撰寫你的程式碼。Sonar 為你提供品質門檻，讓程式碼可以順利上線。它對每次 commit 執行同樣的完整檢查：深度的跨檔案分析、一份風險分布地圖，以及一個讓每個人和每個 Agent 都達到同一標準的品質門檻。
這篇文章被評為 100% 真人撰寫，由 Pangram 4 評定。
