全文翻譯自 The 70% problem: Hard truths about AI-assisted coding
在深入研究AI輔助開發的這幾年中，我發現了一個引人深思的現象。儘管工程師們表示使用AI後生產力大幅提升，但我們日常使用的軟體似乎並沒有明顯變得更好。這是為什麼呢？
我想我知道原因，而這個答案揭示了一些我們必須正視的軟體開發基本真相。讓我分享我所學到的。
AI 開發人員實際如何使用AI
我觀察到團隊運用AI進行開發時有兩種明顯的模式。讓我們稱之為「啟動者」和「迭代者」。這兩種模式都在幫助工程師（甚至非技術人員）縮短從構想到實現（或最小可行產品）的差距。
啟動者：從零到最小可行產品
像Bolt、v0和截圖轉程式碼AI等工具正在徹底改變我們建立新專案的方式。這些團隊通常會：
- 從設計或概念草圖開始
- 使用AI生成完整的初始程式碼
- 在數小時或數天內完成原型，而不是花費數週
- 專注於快速驗證和迭代
結果令人印象深刻。我最近看到一位獨立開發者使用Bolt，在極短的時間內就將Figma設計轉換成一個可運作的網頁應用程式。雖然還不足以投入生產環境，但已經足以獲得最初步的使用者回饋。
迭代者：日常開發
第二類開發者在日常開發工作流程中使用像Cursor、Cline、Copilot和WindSurf這樣的工具。這種方式雖然不那麼引人注目，但可能帶來更深遠的變革。這些開發者會：
- 使用AI來完成程式碼和獲取建議
- 運用AI處理複雜的重構任務
- 生成測試和文件
- 將AI作為解決問題的「配對程式設計師」
但這裡有一個問題：雖然這兩種方法都能大幅加快開發速度，但它們都帶有一些不易察覺的隱藏成本。
「AI速度」背後的隱藏成本
當你看著資深工程師使用像Cursor或Copilot這樣的AI工具時，看起來就像魔法一般。他們能在幾分鐘內搭建完整功能，包含測試和文件。但仔細觀察，你會發現一個關鍵：他們並不是單純接受AI的建議。他們始終在：
- 將生成的程式碼重構為更小、更專注的模組
- 補充AI遺漏的邊界情況處理
- 加強型別定義和介面
- 質疑架構決策
- 添加全面的錯誤處理
換句話說，他們正在運用多年來辛苦累積的工程智慧來調整和約束AI的輸出。AI雖然加速了他們的實作過程，但正是他們的專業確保了程式碼的可維護性。
初級工程師經常忽略這些關鍵步驟。他們較容易直接接受AI的輸出，導致我所謂的「紙牌屋程式碼」－ 表面看起來完整，但在實際環境的壓力下就會崩潰。
知識悖論
我發現了一個最違反直覺的現象：AI工具對有經驗的開發者的幫助比對新手更大。這似乎不合常理 － AI不是應該讓編程更加民主化嗎？
事實上，AI就像是團隊中一位非常積極的初級開發者。他們能快速寫出程式碼，但需要持續的監督和修正。你懂得越多，就越能有效地引導他們。
這就產生了我所謂的「知識悖論」：
- 資深工程師使用AI來加速他們已經會做的事情
- 初級工程師嘗試使用AI來學習該做什麼
- 兩者的結果有顯著差異
我觀察到資深工程師使用AI來：
- 快速製作他們已經理解的概念原型
- 生成基礎實作後進行改良
- 探索已知問題的替代解決方案
- 自動化例行性的編碼任務
同時，初級工程師常常：
- 接受不正確或過時的解決方案
- 忽略關鍵的安全性和效能考量
- 難以對AI生成的程式碼進行除錯
- 建立他們並不完全理解的脆弱系統