關於 AI 生成程式碼的辯論已從理論預測轉向實際實作經驗分享。 Flask 創始人 Armin Ronacher 最近分享了他建構正式系統的經驗，其中 AI 生成了約90%的程式碼，引發了關於 AI 輔助開發現狀和限制的激烈討論。
正式環境現實 vs. 炒作
Ronacher 的專案涉及建構一個4萬行基於 Go 的電子郵件服務，包含 REST API 和自訂 SDK 生成器。雖然他達到了90% AI 生成的里程碑，但開發者社群的回應揭示了更細緻的情況。實作過程需要持續監督、架構監管，以及對每一行程式碼的仔細審查——基本上是將 AI 視為一位開發者所形容的「需要經驗豐富指導的程式碼猴子」。
社群反對過度簡化的指標，有些人指出僅以程式碼量來衡量成功完全錯失重點。將 AI 生成程式碼與垃圾郵件相比的比較，突顯了軟體開發中品質勝過數量的擔憂。
專案規格（ Ronacher 的實作）
- 程式語言：Go 語言，依賴套件極少
- API：相容 OpenAPI 的 REST API
- 核心功能：電子郵件收發服務
- 產生的元件：Python 和 TypeScript SDK
- 總行數：約 40,000 行（Go、YAML、Pulumi、SDK 程式碼）
- AI 貢獻度：約 90% 的程式碼量
- 使用工具：針對不同任務使用 Claude Code 和 Codex
複雜場景中出現的技術限制
實際測試揭示了 AI 在處理複雜開發工作流程時的重大能力缺口。社群成員報告， AI 在處理涉及多種技術、容器化、安全協定和部署管道的正式級配置時遇到困難。需要協調 TypeScript 配置、資料庫連接、 SSL 憑證、 CI/CD 管道和安全措施的任務，往往超出目前 AI 的能力範圍。
然而，支持者指出，這些複雜場景不應該嘗試作為單一提示來處理。關鍵在於將複雜任務分解為可管理的塊狀，類似於人類開發者透過漸進式提交和拉取請求來處理大型專案的方式。
TypeScript：一種為 JavaScript 添加類型安全的程式語言 CI/CD：持續整合/持續部署 - 自動化軟體開發實務
AI 的優勢與限制
AI 擅長的領域：
- 原始 SQL 生成和資料庫遷移
- OpenAPI 規格建立
- 基礎設施建置（ AWS 、 Pulumi ）
- 樣板和腳手架程式碼
- 測試基礎設施建置
- 快速原型開發和實驗
AI 面臨困難的領域：
- 執行緒和並發處理（ goroutines ）
- 系統架構決策
- 流量限制實作細節
- 錯誤處理最佳實務
- 安全性考量
- 複雜的多服務配置
新手開發者的學習曲線挑戰
討論中出現的一個重要擔憂，集中在 AI 程式碼生成如何影響開發者教育和技能發展。傳統上，程式設計師透過撰寫程式碼、接受回饋，並逐步提升技能來學習。新的模式期望初級開發者在同時學習程式設計基礎的情況下，審查和管理 AI 生成的程式碼。
這創造了潛在的技能落差，新程式設計師可能在沒有發展出架構系統、除錯複雜問題或做出關鍵技術決策所需深度理解的情況下，變得依賴 AI 。社群擔心會出現一代能夠有效提示 AI 但缺乏基礎知識來批判性評估結果的開發者。
特定使用案例中的實際效益
儘管有限制，開發者在某些領域報告了真正的生產力提升。基礎設施設置、樣板程式碼生成、 SQL 查詢撰寫和快速原型製作顯示出最大的潛力。以前需要數天研究和實作的任務，現在可以在 AI 協助下數小時內完成。
該技術特別擅長處理繁瑣但理解透徹的任務，如資料庫遷移、 API 腳手架和配置檔案生成。開發者欣賞能夠快速實驗不同方法的能力，實現更多迭代設計流程和架構探索。
結論
90% AI 生成程式碼的里程碑既代表成就也是警示故事。雖然該技術在特定情境下展現了令人印象深刻的能力，但社群共識表明，經驗豐富的人類監督對於正式系統仍然至關重要。未來可能涉及 AI 作為強大的開發加速器，而非熟練工程判斷的替代品。
AI 生成程式碼的成功似乎很大程度上取決於開發者提供適當架構指導、維持程式碼品質標準，以及識別何時應該拒絕 AI 建議的能力。隨著技術持續演進，挑戰將是確保生產力提升不會以系統可靠性或開發者技能發展為代價。
參考資料：90%