[AI 衝擊] AI如何重塑軟體開發

 [AI 衝擊] AI如何重塑軟體開發

摘要：AI生成程式碼的能力，可能改變審查、測試、分工與介面設計，讓開發重心轉向需求和系統。

內容:

AI正在改變軟體開發的方式。當程式碼可以大量、快速地生成，過去圍繞「人寫程式碼」建立的工作流程，也可能需要重新思考。以下是對未來軟體開發的十項觀察與推測。

第一，程式碼審查可能從逐行檢查轉向系統審查。 AI生成程式碼的速度可能超過人類審查的能力。若仍依照現行方式，透過PR逐行閱讀、尋找錯誤，審查者恐怕難以在合理時間內完成工作。未來人類可能更著重確認系統組成、架構與整體行為是否合理，而不是檢查每一行程式碼。

第二，單元測試的重要性可能下降。 如果AI能在每次迭代時大幅改寫實作，針對個別程式碼單元建立的測試，也可能隨之頻繁失效。這就像整棟樓可能重新建造，再反覆檢查原本的單塊磚頭，價值便不如從整體驗證。未來專案或許會更依賴介面測試、整合測試與系統測試，而減少保留單元測試。

第三，程式設計師的重心將從寫程式碼移開。 當AI負責產生大部分程式碼，開發者的價值將更集中在程式碼以外：釐清業務問題、判斷如何用軟體解決問題、理解系統的實現方式、規劃軟體發布，以及收集使用者回饋並持續改進產品。

第四，bug的來源可能改變。 如果AI能處理許多實作細節，未來常見的問題可能不再只是程式碼寫錯，而是需求本身有誤、描述不夠精確，或提出需求的人沒有說清楚真正想解決的問題。

第五，開源對品質的獨特優勢可能減弱。 過去支持開源的一項理由是：只要有足夠多人檢視程式碼，錯誤就更容易被發現。這個道理仍然成立；但若AI也能協助檢查未開源的程式碼，公開原始碼便不再是取得大量檢查能力的唯一途徑。

第六，敏捷開發的方法可能受到挑戰。 當開發速度越來越取決於AI生成與修改軟體的能力，部分既有的敏捷流程可能失去原本的作用。在這種構想下，團隊需要做的，是把釐清後的工單交給AI執行，再驗證結果是否符合需求。

第七，專案分工可能重新組合。 傳統專案團隊通常由專案經理、設計師與工程人員分別承擔不同職責。有了AI協助，一個人可能跨越多種角色，同時規劃需求、設計方案並推進實作，原有的三元分工也可能因此改變。

第八，「好程式碼」的標準可能改寫。 過去，好程式碼通常意味著人類容易閱讀、理解、重構與維護。但如果人不再直接閱讀或修改大部分程式碼，這套以人類維護效率為核心的標準，就可能不再適用於所有情境。

第九，程式碼風格規範與linter的角色可能縮小。 每行是否超過80個字元、如何換行、使用tab還是空格縮排，這些規範主要是為了讓人類更容易閱讀與協作。如果程式碼的主要產生者和處理者都是AI，這類風格要求的必要性也可能被重新評估。

第十，固定的使用者介面可能不再那麼重要。 一方面，未來部分軟體介面可能主要供AI使用，而AI更需要API，不一定需要精緻的視覺畫面。另一方面，當介面也能快速生成，使用者或許不必再透過選單、設定頁、儀表板和篩選器，逐步告訴軟體自己想做什麼；只要以語言說明需求，AI就能即時生成符合當下任務的介面。

這些變化仍是對未來的推測，但它們指向同一個方向：當生成程式碼不再是最耗時的環節，軟體開發的核心能力，可能轉向提出正確問題、清楚表達需求，以及驗證整個系統是否真正解決了問題。