如果AI程式設計的真正關鍵是老套而無聊的做法呢？
文章認為，AI輔助軟體開發的關鍵並非更好的規格說明或工具，而是古老的小批次與快速反饋迴圈實踐。資料顯示，更快的程式碼生成導致設計、測試和審查環節出現瓶頸，反而使交付變慢、釋出更不穩定。真正的槓桿在於縮小批次、縮短反饋週期。
文章情報
要點
- AI程式碼生成加速了編寫，但產生了設計、測試、審查等環節的瓶頸。
- 來自DORA、CircleCI和Faros的資料表明，階段門控流程導致交付更慢、更不穩定。
- 解決之道是減小批次大小、縮短反饋迴圈。
- 作者將這種老舊做法戲稱為“反饋最大化”。
為什麼重要
這條新聞值得關注，因為AI程式碼生成加速了編寫，但產生了設計、測試、審查等環節的瓶頸。
技術影響
可能影響模型選型、推理成本、產品能力和評測基準。
在AI輔助軟體開發的討論中，眾說紛紜：有人認為關鍵在於更好的規格說明，有人強調更優的計劃，架構師推崇更好的架構，產品經理看重更佳的產品管理，測試自動化人員堅稱更好的測試套件，靜態分析工具的銷售者則鼓吹更自動化的程式碼審查。然而，本文作者指出，這些觀點都忽略了真正的核心——古老而“無聊”的小批次工作與快速反饋迴圈。
資料揭示了真相。DevOps Research & Assessment（DORA）組織對數千個團隊的資料分析顯示，AI生成的程式碼雖更快地創造出來，卻在等待使用者反饋、設計決策、測試、審查和合併到釋出分支的佇列中滯留。CircleCI對數百萬CI工作流的分析得出了相同結論：開發者分支上程式碼生成加快，但後續環節的等待導致整體交付變慢、釋出穩定性下降。Faros公司的資料也印證了這一趨勢。
問題根源始終未變：階段門控式的開發流程試圖以大批次變更處理設計、測試、審查、重構、合併和釋出。無論是更好的規格、架構、自動化，還是產品管理、型別檢查、領域驅動設計或團隊拓撲，都無法從根本上解決這個問題——它們固然有價值，但影響力遠不及批次大小和反饋迴圈這兩個槓桿。
作者坦言，自己恰好專攻小批次與快速反饋的開發實踐，而資料再次將他引向這個結論。他甚至戲謔地提議，若覺得“小步快跑”太過老套，不妨稱之為“反饋最大化”（feedbackmaxxing）。總之，AI程式碼生成加速了編寫速度，但出人意料的是，真正的瓶頸恰恰出現在這些傳統環節，而解決之道卻是一些被忽視的古老智慧。