Rsync 之爭：Vibe Coding 與核心基礎設施的脆弱性

開源社群目前正陷入一場激烈的辯論，起因是有人在 rsync（Unix 生態系統中最普及且最受信任的工具之一）的 GitHub issue 中提出了質疑。這場爭議的核心在於「vibe coding」的概念——即使用大型語言模型（LLMs）根據一般意圖而非嚴謹的手動規範來生成大量程式碼的做法——以及這種做法是否應該存在於作為全球基礎設施基石的軟體之中。

衝突的核心是一個 GitHub issue（Issue #929），指責維護者讓 AI「vibe fuck up」了軟體。這引發了立即的反彈，並在 Hacker News 上激發了關於遺留系統中 AI 的倫理、開源維護的負擔，以及軟體退化（regression）本質的更廣泛討論。

反對在核心工具中使用 AI 的理由

對於許多開發者來說，rsync 代表了一類不應受實驗性方法論影響的軟體。由於它被用於關鍵的備份和系統遷移，單次退化的成本可能是災難性的。主要的論點是，對於一個已經「勝出」的工具——意即它是產業標準且運作可靠——沒有理由用 AI 生成的程式碼來進行豪賭。

批評者指出，變更的數量龐大是一個警訊。一位評論者指出驚人的變動量（churn），暗示在短時間內修改了數千行程式碼，這對於一個成熟的專案來說是不尋常的。

"You have a rock solid piece of software used by an infinite amount of people and other services. It works fine, does its job... Why do we need AI here?"

此外，對於那些將舊語法替換為新語法（例如在 JavaScript 環境中將 var 替換為 let，或 C 語言中類似的風格轉變）而沒有增加功能價值的「現代化」提交（commits），也存在著深層的挫折感，因為這些變更往往會掩蓋實際的錯誤，並讓 git bisect 變得極其困難。

維護者的困境

相反地，社群中有很大一部分人為維護者辯護，強調了管理遺留開源專案的艱辛現實。許多這類工具是由少數志願者維護的，他們多年來一直尋求幫助，但很少得到廣泛社群的響應。從這個角度來看，使用 AI 來處理「瑣事」或擴展測試套件，被視為維護者的必要生存策略，而非懶惰。

有些人認為，憤怒是放錯了對象，應該關注於程式碼的「審查」（review）而非程式碼的「來源」。如果引入了錯誤，失敗在於 QA 流程或缺乏同儕審查，無論最初的補丁（patch）是由人類還是 AI 編寫的。

"If the code is good, bug free, and easily understood, who the f*ck cares? If a maintainer just accepts any code, without review or control, humans, just as well as 'AI:s' can submit crappy code."

「Vibe Coding」現象

此事件讓「vibe coding」一詞成為焦點。它描述了一種從傳統工程——每一行程式碼都經過推理——轉向迭代提示（prompting）的過程，開發者與 AI 「vibe」直到輸出結果看起來可行。雖然這可以加速原型設計，但社群正在質疑其在記憶體安全和邊緣案例處理至關重要的低階 C 語言程式碼中的可行性。

討論中提出了對新 GitHub 元數據的建議，例如使用「AI-generated code」標籤來警告使用者關於與「vibe」貢獻相關的潛可能風險。

替代方案與未來的路徑

隨著部分人的信任動搖，社群中對替代方案的興趣也隨之回升。OpenRsync 被頻繁提及，作為那些希望避免受 AI 影響版本的工具的避風港。

最終，rsync 之爭為 AI 時代提供了一個警示故事。它突顯了根本性的緊張關係：想要現代化並維護陳舊但必要的程式碼庫，與維持運行網路的工具之絕對可靠性要求之間存在衝突。這究竟是暫時性的恐慌，還是我們對二進位檔信任方式的系統性轉變，仍有待觀察，但批評者之間的共識很明確：當涉及到作業系統的核心工具時，「vibe」並不能取代規範。