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