Mainlane由一位工程師和一支AI代理團隊組成。這自然引出一個問題：AI寫的程式碼由誰來檢查？我們的答案是：由另一個沒有參與撰寫的AI審查，再由人來決定是否發布。
流程
- 一個Claude工作階段接下任務並發起拉取請求。
- 另一位審查者在全新的工作階段中啟動。它從未看過程式碼是怎麼寫出來的，所以會像同事一樣閱讀diff，不帶作者的預設立場。
- 審查者把發現的問題分成三級：🔴 必須修正，🟡 建議修正，🟢 有更好。
- 作者工作階段修正問題並逐條回覆，最後附上「驗證（Verification）」段落：列出執行過的指令及其輸出。
- 審查者檢查新的head。循環會一直重複，直到沒有任何問題為止，連🟢也沒有。
有兩條規則確保過程不走樣。對某個問題提出異議時，只能拿出量測結果，例如一個數字、一段指令輸出、一個測試沒能抓到的變異體，而不能只說「沒問題」。此外，五輪之後循環會停下來交由人決定，因此永遠不會無止盡地跑下去。
人的環節
沒有任何代理會執行合併。當審查沒有問題，而且CI在審查者看到的那個commit上剛好通過時，工作階段會寫下「ready to merge（可以合併）」然後等待。只有在人明確同意後才會合併，而且只合併同一個commit。
能抓到什麼
以下是本網站程式碼儲存庫中的幾個真實案例：
- 在為CI加入Lighthouse檢查的拉取請求中，審查者發現一項CSS建置設定指向了錯誤的資料夾，導致版面樣式悄悄從網站上消失。Lighthouse和無障礙檢查工具都沒有發現。它也抓到一個固定的語言橫幅，可能會遮住鍵盤使用者目前聚焦的元素。
- 在資料庫備份還原檢查中，每日測試把還原後的資料拿來跟自己比對，而不是跟匯出的資料比對，就算少了資料列也永遠不會發現。同一次審查還找到一則錯誤訊息，可能把潛在客戶的電子郵件寫進日誌。
- 在導入Content Security Policy時，來自瀏覽器擴充功能的回報會讓「一週無違規」的目標永遠無法達成，而且一旦強制執行該政策，部落格文章中的外部圖片就會無法顯示。
這些都不是什麼罕見的問題，而是週五傍晚疲憊時很容易漏掉的那類問題。
數據
截至2026年10月底，這個循環在8個程式碼儲存庫中運作，已合併385個拉取請求，完成1,069次審查。大部分成本花在工作本身：10月最後一週，約四分之三的token用於實作，用於審查的不到十分之一。
限制
審查者和作者是同一類模型，因此可能有相同的盲點。它無法取代人對重要變更的審查，拉取請求中的文字一律被視為資料，而不是指令。它真正取代的是多數獨立開發者都會略過的一步：讓每一項變更都多一雙眼睛把關。