PlanetScale 使用 Bugbot 確保正式環境的高可靠性

PlanetScale 為客戶管理雲端資料庫工作負載,承載其最敏感的資料。可靠性就是產品本身,因此每一次推送到正式環境的程式碼變更都必須毫無瑕疵。隨著各式代理讓程式碼生成變得低成本又快速,程式碼審查成了軟體開發生命週期中的新瓶頸。
為了確保正確性,並能有信心將程式碼部署到正式環境,PlanetScale 導入 Bugbot 作為專門的代理審查層。如今,大約 80% 的 Bugbot 評論都會在合併前被處理,防止問題進入正式環境,並為 PlanetScale 節省了相當於兩名全職工程師的程式碼審查人力。
Agents 將 SDLC 中的瓶頸往後移動到下游環節
為了維持產品的可靠性,PlanetScale 的工程團隊對程式碼審查設定了毫不妥協的高標準。PlanetScale 軟體工程師 Fatih Arslan 表示:「可靠性是我們產品的核心。每一次部署到 production 的變更都必須完美無瑕。」
隨著負責寫程式的 AI 代理成為開發工作流程的核心,瓶頸從程式碼產生階段後移到了程式碼審查階段。Arslan 解釋:「程式碼本身已經變得很廉價。現在的瓶頸在於你的程式碼是否正確,以及你是否真正理解它在做什麼。」
程式碼產出量快速增加,但人工審查的能力卻維持不變。這樣的失衡為產品品質帶來壓力。為了跟上腳步,PlanetScale 估計必須安排兩位工程師專職負責程式碼審查。這樣的取捨會降低工程團隊投入產品開發的可用資源,同時在代理採用持續擴大的情況下,仍無法真正解決長期的可靠性挑戰。
我們意識到自己需要 Bugbot 的代理式審查來補足既有流程。否則,要在確信品質與正確性的情況下,將程式碼部署到 production,會變得非常困難。
使用 Bugbot 消除生產環境停機
Bugbot 在其他代理審查工具中脫穎而出,因為它能在 PlanetScale 龐大且複雜的程式碼庫,以及大量由代理產生的程式碼中,偵測出人類審查者因複雜度而遺漏的問題。
有了 Bugbot,工程師能在開發流程更早期就攔截並修復可能導致生產環境停機的錯誤。
Bugbot 跟其他工具不同。它會偵測到身為人類審查者的我,完全不會想到要去檢查的問題。這讓我大開眼界。
與著重於機械正確性的靜態分析器(static analyzer)和 linter 不同,Bugbot 會揭露更深層的語意與邏輯問題,例如:
- 狀態同步缺口,導致系統被過早標記為已完成
- 邏輯流程變更,使關鍵程式碼路徑無法被執行
- 非同步控制器互動,無法正確收斂
- 邊界情況,可能在各個生產資料庫上觸發重新啟動
Bugbot 一直能找出生產環境中可能造成顯著停機時間的錯誤,而這些錯誤對人類來說非常難以發現。
PlanetScale 也發現,只是提示一個最先進模型來審查程式碼,並不能穩定找出 Bugbot 所辨識到的最關鍵問題。Arslan 表示:「當我使用推理模型請它審查分支時,它找不到這些問題。真正造成差異的是 Bugbot 所使用的專門設計的執行框架,以及 Bugbot 本身的構建方式。」
衡量 Bugbot 審查品質
PlanetScale 使用一個簡單的指標來評估 Bugbot:「解決率」(resolution rate),用來衡量在合併程式碼時,被解決的 Bugbot 所識別問題所佔的比例。
現在,每個月在超過 2,000 個 PR(拉取請求)中,約有 80% 的 Bugbot 評論會被工程師處理。Arslan 表示:「Bugbot 的評論品質一流,而且會隨著 Bugbot 取得更多脈絡持續提升。」
Bugbot 的訊號與雜訊比非常高。當 Bugbot 在一個 PR 上留言時,我們就知道它指出的是必須修復的問題。
Bugbot 現在已深度整合進 PlanetScale 的工作流程中,讓工程師能有信心,無論是人工撰寫或由代理產生的程式碼,都能安全地部署到正式環境。Arslan 說:「我愛 Bugbot。這就是我的座右銘。」
PlanetScale 現在可以在不犧牲品質的前提下,更快速地發布軟體,同時工程師能專注於解決複雜的基礎設施問題,而不是手動審查每一行由代理產生的程式碼。
如果我把 Bugbot 從我們工程團隊拿掉,他們肯定會造反。
如果你也希望透過代理來簡化程式碼審查並強化產品可靠性,請聯絡我們的團隊,開始試用 Cursor。