背景

開發者 Kian Kyars 近期嘗試利用 Claude、Codex 與 Gemini 組成的 AI 代理小隊，在 Rust 環境下協作開發一個類 SQLite 的資料庫引擎。這項實驗的核心在於模擬分散式系統的軟體工程流程，透過 Git、鎖定機制與測試自動化來強制執行代理間的協調，並在短短兩天內產生了超過一百次提交。

社群觀點

這項實驗在 Hacker News 引發了極為兩極的評價，爭論焦點首先集中在「完成度」與「真實性」。許多資深開發者指出，雖然 AI 生成的程式碼在架構上看似合理，但實際上與真正的 SQLite 品質相去甚遠。評論者 comex 深入分析程式碼後發現，該專案缺乏併發處理、B-tree 實作不完整，且在分頁管理上存在低效率的線性搜尋與記憶體複製問題。最關鍵的批評在於測試，SQLite 以其極其嚴苛的測試套件聞名，而此專案僅通過了三個簡單的查詢測試。批評者認為，若無法通過 SQLite 官方的測試套件，稱其為「開發出 SQLite」無異於誤導，甚至有評論者將其諷刺為「幻象作品」（slopulacra），認為這類專案的主要作用是作為行銷噱頭，讓人誤以為 AI 已經具備開發複雜軟體的能力。

然而，也有部分觀點對此持開放態度。支持者認為，這項實驗的價值不在於取代現有的 SQLite，而是在於驗證「代理群體協作」的可能性。即便目前的產出充滿臭蟲且效能低下，但它證明了 AI 能夠在沒有人類干預的情況下，維持一個具有基本邏輯的程式碼庫。針對 Rust 版本的安全性優勢，社群展開了一場關於記憶體安全的辯論。有人主張 Rust 版本能避免 C 語言常見的記憶體漏洞，但隨即遭到反駁，指出 SQLite 官方對測試的執著已使其穩定性超越絕大多數軟體，且 Linux 系統的記憶體管理機制（如 Overcommit）使得單純更換語言並不一定能保證絕對安全。

另一派討論則聚焦於「知識洗白」與「創新性」的倫理問題。反對者認為，由於 SQLite 是開源專案，其原始碼早已存在於 AI 的訓練資料中，這種開發過程本質上只是在進行昂貴的知識檢索與程式碼洗白，而非真正的創造。他們質疑，如果 AI 只是在重寫已存在的東西，那麼其對軟體產業的實質貢獻將非常有限。不過，也有開發者反駁，軟體開發本來就充滿了重複性的模式，若能透過 AI 暴力破解這些繁瑣的基礎建設工作，將能釋放人類工程師去處理更具創造力的問題。

最後，關於協調機制的討論也相當熱烈。數據顯示超過半數的提交紀錄都花費在鎖定與釋放等協調工作上，這讓部分評論者質疑「並行開發」在單一程式碼庫上的效益。他們建議，與其追求開發速度，不如將重點放在如何讓 AI 建立更嚴謹的驗證機制，因為在軟體工程中，驗證正確性往往比撰寫程式碼本身更加困難且耗時。

延伸閱讀

• SQLite 官方關於測試的詳細說明：介紹其如何達成 100% 分支測試覆蓋率。
• TH3 測試套件：SQLite 專為航空級安全設計的專有測試工具。
• SQLite CVE 歷史分析：官方針對安全漏洞報告的回應與澄清。
• Why SQLite Is Written In C：官方解釋為何不選擇 Rust 等安全語言的技術考量。