pgrust 專案的價值與對 AI 生成軟體的偏見
Michael Malis 開發的 pgrust（Rust 重寫版 Postgres）常被社群誤認為低品質的 AI 生成專案。然而，Dan Luu 指出，Malis 在測試過程中發現了 Postgres 原始碼中的多個真實錯誤，包括導致 SP-GiST 運算失敗的數值錯誤、JSONPath 結果錯誤的格式快取錯誤、pgcrypto 後續操作失敗的錯誤，以及字典載入器中的多個記憶體安全錯誤。
這些發現表明，即使 pgrust 最終未能成功取代 Postgres，其嚴謹的測試過程已對 Postgres 產生持久的改進貢獻。Luu 強調，雖然多數重寫專案確實品質低落，但開發者不應因普遍的低品質印象而放棄嘗試高野心專案，因為只要經過合理的測試與基準比較，這些專案可以達到足夠使用的品質標準。
AI 能力躍進如何改變個人工具開發的成本結構
Luu 以自身經驗說明，當使用 OpenAI 最新 SOTA 模型（如 GPT-5.6 Sol 或 GPT-6 Astra）時，原本受限於 Ripgrep、Rust 編譯速度及系統呼叫開銷的瓶頸變得可被突破。他僅花費數小時便開發出比通用庫更快的自訂 Regex 引擎、加速 Rust 冷啟動編譯的工具，以及針對特定工作負載優化的 ripgrep 分支。
過去對於不熟悉正規表示式或編譯器原理的人來說，達到「僅供自用」品質的這類工具可能需要一年以上時間。現在，這些任務的時間成本降至個位數小時。然而，若要達到「可用產品」或「開源專案」的品質標準，仍需額外的大量工作。這顯示 AI 大幅降低了原型開發門檻，但未消除工程化所需的嚴謹性。
從棋類 AI 到複雜軟體實作：模型理解力的質變
Luu 回顧自己使用 GPT-5.1/5.2 開發超人類水準棋類 AI 的經驗，當時需花費約 20 小時進行大量人工引導與修正，因為模型對相關技術的理解錯誤頻繁。相比之下，近期 Fable 5.1 和 Opus 5.5 等模型展現出對棋類 AI 論文與程式碼庫更好的理解能力，使得開發者 Gabriel Cangussu 能以更少時間開發出更強大的 AI。
在軟體實作測試中，GPT-6 Astra 在實作 zstd 壓縮演算法時，能在所有條件下（包括使用 TDD 等降低效能的條件）以超過 99% 的成功率通過註冊測試，且成本僅約 1 美元。這與 GPT-5.6 Sol 無法有效處理 IMAP RFC 或 Pandoc 等多格式轉換任務形成對比。然而，Luu 指出，隨著模型能一次性完成更多任務，開發者轉向更具野心的專案，導致「模型能有效驗證」與「模型能實作」之間的差距擴大，而非實現了軟體開發的完全自動化。
反方觀點：多數開發者應降低野心以避免技術債
專家 Yossi Kreinin 提出不同看法，認為對多數人而言，使用 AI 時應「降低野心」。他指出，許多問題缺乏明確的通過/失敗標準，且人們難以推理大型黑箱系統內部邏輯。這類似於微服務架構，雖然少數人能善用，但多數人可能因無法有效管理而導致失敗。
Kreinin 警告，若管理者盲目追求「軟體不應慢」並強制使用 AI 優化隨機部分，可能產生過度擬合特定測試案例、難以泛化且維護困難的混亂程式碼。Luu 承認此觀點有一定道理，特別是在缺乏清晰規格或自我驗證機制的情況下。但他認為，若能建立某種自我檢查系統（如一致性檢查或模糊測試），即使非專家也能以較低成本處理複雜問題。
社群回饋與實際應用限制
社群評論指出，在專業開發者圈子之外，軟體品質普遍低落，例如家用熱泵設備存在大量未記錄功能與硬編碼值。另有觀點認為，團隊協作中的協調成本與意識形態摩擦可能抵消個人使用 AI 帶來的效率增益，甚至導致開發流程倒退。
也有開發者分享成功案例，如 Peter Geoghegan 使用 Fable 模型實作符合嚴格 pgindent 規範的 Neovim Lua 函數，避免了 CI 失敗與維護負擔。這顯示在特定、明確且個人化的工具需求上，AI 能有效解決傳統方法難以處理的細節問題。然而，這些案例多為「僅供自用」或高度客製化場景，未必適用於通用軟體開發流程。
