四十八個德瑞克

70%問題：關於AI協助編程的現實真相

derekhsu

全文翻譯自 The 70% problem: Hard truths about AI-assisted coding

在深入研究AI輔助開發的這幾年中，我發現了一個引人深思的現象。儘管工程師們表示使用AI後生產力大幅提升，但我們日常使用的軟體似乎並沒有明顯變得更好。這是為什麼呢？

我想我知道原因，而這個答案揭示了一些我們必須正視的軟體開發基本真相。讓我分享我所學到的。

AI 開發人員實際如何使用AI

我觀察到團隊運用AI進行開發時有兩種明顯的模式。讓我們稱之為「啟動者」和「迭代者」。這兩種模式都在幫助工程師（甚至非技術人員）縮短從構想到實現（或最小可行產品）的差距。

啟動者：從零到最小可行產品

像Bolt、v0和截圖轉程式碼AI等工具正在徹底改變我們建立新專案的方式。這些團隊通常會：

結果令人印象深刻。我最近看到一位獨立開發者使用Bolt，在極短的時間內就將Figma設計轉換成一個可運作的網頁應用程式。雖然還不足以投入生產環境，但已經足以獲得最初步的使用者回饋。

迭代者：日常開發

第二類開發者在日常開發工作流程中使用像Cursor、Cline、Copilot和WindSurf這樣的工具。這種方式雖然不那麼引人注目，但可能帶來更深遠的變革。這些開發者會：

但這裡有一個問題：雖然這兩種方法都能大幅加快開發速度，但它們都帶有一些不易察覺的隱藏成本。

「AI速度」背後的隱藏成本

當你看著資深工程師使用像Cursor或Copilot這樣的AI工具時，看起來就像魔法一般。他們能在幾分鐘內搭建完整功能，包含測試和文件。但仔細觀察，你會發現一個關鍵：他們並不是單純接受AI的建議。他們始終在：

換句話說，他們正在運用多年來辛苦累積的工程智慧來調整和約束AI的輸出。AI雖然加速了他們的實作過程，但正是他們的專業確保了程式碼的可維護性。

初級工程師經常忽略這些關鍵步驟。他們較容易直接接受AI的輸出，導致我所謂的「紙牌屋程式碼」－ 表面看起來完整，但在實際環境的壓力下就會崩潰。

知識悖論

我發現了一個最違反直覺的現象：AI工具對有經驗的開發者的幫助比對新手更大。這似乎不合常理 － AI不是應該讓編程更加民主化嗎？

事實上，AI就像是團隊中一位非常積極的初級開發者。他們能快速寫出程式碼，但需要持續的監督和修正。你懂得越多，就越能有效地引導他們。

這就產生了我所謂的「知識悖論」：

我觀察到資深工程師使用AI來：

同時，初級工程師常常：

70%問題：AI學習曲線的悖論

最近有一則推文完美捕捉到我在實務上觀察到的現象：非工程師在使用AI編程時會遇到一道令人沮喪的障礙。他們能夠驚人地快速完成70%的進度，但最後30%卻變成了一場投入報酬遞減的練習。

這個「70%問題」揭示了AI輔助開發現況的一個關鍵現象。一開始的進展感覺像魔法一般 － 你只需描述你想要什麼，像v0或Bolt這樣的AI工具就能生成一個看起來令人印象深刻的可用原型。但接著現實就浮現了。

倒退兩步的模式

接下來通常會發生一個可預見的模式：

學習悖論繼續

這裡有個更深層的問題：讓非工程師也能使用AI編程工具的特性 － 即代為處理複雜性的能力 － 實際上可能會阻礙學習。當程式碼只是「憑空出現」，而你不理解其背後的原理時：

這種情況造成了一種依賴性，你需要不斷地回去請教AI來修復問題，而不是培養自己解決問題的專業能力。

知識落差

我看過最成功的非工程師在使用AI編程工具時都採用混合方式：

  1. 使用AI進行快速原型設計
  2. 花時間理解生成的程式碼如何運作
  3. 在使用AI的同時學習基本的程式設計概念
  4. 逐步建立知識基礎
  5. 將AI作為學習工具，而不僅僅是程式碼產生器

但這需要耐心和投入 － 恰恰與許多人最初使用AI工具時所期望達到的目標相反。

對未來的影響

這個「70%問題」顯示目前的AI編程工具最適合被視為：

但它們還不是人們所期待的編程民主化解決方案。最後的30% － 也就是使軟體達到可上線、可維護和穩健性的部分 － 仍然需要真正的工程知識。

好消息是，隨著工具的改進，這個差距可能會逐漸縮小。但目前而言，最務實的做法是將AI用於加速學習，而不是完全取代學習。

實用模式：什麼方法真正有效

在觀察了數十個團隊後，以下是我發現持續有效的方法：

1. 「AI初稿」模式

2. 「持續對話」模式

3. 「信任但驗證」模式

展望未來：AI的真正潛力？

儘管面臨這些挑戰，我仍然對AI在軟體開發中的角色保持樂觀。關鍵在於理解它真正擅長的領域：

  1. 加速已知項目AI擅長協助我們實作已經理解的模式。這就像擁有一位無限耐心且打字飛快的配對程式設計師。
  2. 探索可能性AI非常適合快速建立原型和探索不同的方法。這就像擁有一個可以讓我們迅速測試概念的沙盒環境。
  3. 自動化例行工作AI大幅減少在樣板程式碼和例行編碼任務上所花費的時間，讓我們能專注於有趣的問題。

這對你來說意味著什麼？

如果你剛開始使用AI輔助開發，以下是我的建議：

  1. 從小處著手
    • 在獨立且明確定義的任務中使用AI
    • 審查每一行生成的程式碼
    • 逐步建立更大的功能
  2. 保持模組化
    • 將所有內容拆分為小型且專注的檔案
    • 維護組件之間清晰的介面
    • 記錄你的模組邊界
  3. 相信你的經驗
    • 使用AI來加速而非取代你的判斷
    • 對感覺不對勁的生成程式碼提出質疑
    • 維持你的工程標準

主動式軟體工程的崛起

AI輔助開發的格局正在朝著2025年劇烈轉變。儘管當前的工具已經改變了我們的原型設計和迭代方式，我相信我們正處於一個更重大轉變的邊緣：主動式軟體工程的崛起。

我所謂的「主動式」是什麼意思？這些系統不只是回應提示，還能以越來越自主的方式規劃、執行並反覆改進解決方案。

如果你有興趣深入了解代理人工智慧，包括我對Cursor/Cline/v0/Bolt的看法，歡迎觀看我上方的JSNation演講。

我們已經看到這種演進的早期跡象：

從回應者到協作者

目前的工具大多只是等待我們的指令。但看看較新的功能，像是Anthropic的Claude電腦使用功能，或是Cline自動啟動瀏覽器和執行測試的能力。這些不只是華麗的自動完成功能而已 – 它們確實能理解任務並主動解決問題。

想想除錯過程：這些代理不只是提供修復建議，它們還能：

多模態的未來

下一代工具可能不只是處理程式碼而已 – 它們可以無縫整合：

這種多模態能力意味著它們可以像人類一樣理解和處理軟體 – 從整體著手，而不僅僅停留在程式碼層面。

自主但受指引

我從使用這些工具中獲得的關鍵洞見是：未來並非關於AI取代開發人員 – 而是關於AI如何成為一個越來越有能力的協作夥伴，既能主動採取行動，同時也尊重人類的指導和專業知識。

2025年最有效率的團隊可能是那些學會以下事項的團隊：

以英語為首的開發環境

正如 Andrej Karpathy 所說：

「英語正在成為最炙手可熱的新程式語言。」

這是我們與開發工具互動方式的根本轉變。清晰思考和精確使用自然語言的能力，正變得與傳統編程技能同等重要。

這種朝向主動式開發的轉變將要求我們提升以下技能：

軟體開發重返工藝時代？

儘管AI讓軟體開發變得比以往更加容易和快速，我們卻正面臨失去一個關鍵要素的風險 – 創造真正精緻、消費者級品質體驗的藝術。

示範品質陷阱

這已經成為一種模式：團隊使用AI快速建立令人印象深刻的展示版本。在理想路徑上運作完美無瑕。投資者和社群網路都被驚豔到了。但當真實用戶開始四處點擊時？一切就開始崩潰了。

我親身經歷過這些：

這些不只是P2級別的錯誤 – 這些是讓軟體從被人們勉強接受到被人們喜愛的關鍵差異。

精雕細琢的失落藝術

打造真正自助式的軟體 – 讓使用者永遠不需要聯繫支援人員的那種 – 需要一種不同的思維模式：

這種對細節的關注（或許）無法由AI生成。它來自於同理心、經驗，以及對工藝的深切關懷。

個人化軟體的復興

我相信我們即將迎來個人化軟體開發的復興。隨著市場被AI生成的最小可行產品所淹沒，那些由以下特質的開發者所打造的產品將會脫穎而出：

諷刺的是什麼？AI工具實際上可能促成這場復興。透過處理例行性的編碼任務，它們讓開發者能夠專注於最重要的事 – 創造真正服務並讓用戶感到喜悅的軟體。

結論重點

AI並沒有讓我們的軟體產生顯著的改善，因為軟體品質（或許）從來就不是主要受限於編碼速度。軟體開發中的困難部分 – 理解需求、設計可維護的系統、處理邊緣案例、確保安全性和效能 – 仍然需要人類的判斷。

AI確實讓我們能夠更快地進行迭代和實驗，透過更快速的探索潛在地帶來更好的解決方案。但這必須建立在我們維持工程紀律，並將AI視為工具而非取代良好軟體實踐的前提下。請記住：目標不是更快地寫更多程式碼，而是建立更好的軟體。明智地使用AI可以幫助我們達成這個目標。但究竟什麼是「更好」以及如何達成，仍然取決於我們自己。

您在AI輔助開發方面有什麼經驗？我很想在評論區聽聽您的故事和見解。

Exit mobile version