我可以在不到 30 秒內產生一套完整的認證流程，包括資料庫結構、API 路由和單元測試。
我可以只用一個提示詞，把一個凌亂的元件重構成乾淨的 React Hooks。
我可以請 AI 解釋一個複雜的正規表示式，它會逐行拆解給我看。
那為什麼我上一次那個「簡單」功能，還是花了三週才上線？
如果寫程式現在幾乎是免費的，為什麼打造軟體還是感覺貴得驚人？
30 秒 Pull Request 的悖論
上個月，我在做一個通常只要幾天的功能。我打開 Cursor（或你偏好的 AI 工具），輸入一段詳細的提示詞，然後看著程式碼在螢幕上逐漸成形。
它很漂亮。乾淨。格式化得很好。
我覺得自己像個 10 倍工程師。那天下午我就開了一個 Pull Request，對自己的「產能」感到非常自豪。
然後真正的工作才開始。
我的隊友花了兩天才審查完。不是因為程式碼有錯，而是因為 AI 在快取邏輯裡引入了一個很細微的邊界情況，我們一開始都沒看懂。
等我們終於部署後，它又把一個 AI 根本不知道存在的舊系統弄壞了。
接下來的一週，我們忙著除錯、回滾，還把那份「完美」的 AI 產生程式碼重寫一遍，讓它符合我們真實、混亂的正式環境。
那時我才突然意識到一件不太舒服的事：
寫程式從來都不是最貴的部分。它一直都是最便宜的部分。
軟體工程中的傑文斯悖論
在經濟學裡，有一個概念叫做傑文斯悖論（Jevons Paradox）。它指出，當技術進步提升了某種資源的使用效率時，該資源的總消耗量反而可能增加，而不是下降。
AI 讓寫程式變便宜了。那會發生什麼事？我們只會要求更多程式碼。
以前寫一個功能要一週，我們就交付一個功能。現在寫程式只要一小時，管理層就會在同一週內要求五個功能。
但軟體工程的瓶頸從來都不是打字速度。也不是語法。真正的瓶頸是脈絡所帶來的認知負荷。
AI 不知道你公司三年前做了哪些架構決策。它不知道為什麼那個微服務特別脆弱。它也不知道那位兩年前離職的工程師，腦中曾經保留著哪些商業邏輯。
那成本到底跑去哪裡了？它轉移到我們很少衡量的三個地方：
1. 審查與信任成本
讀程式碼遠比寫程式碼難得多。人寫的程式碼，你可以直接問他：「你為什麼這樣寫？」但 AI 寫的程式碼，你得先逆向工程它的邏輯，才能放心相信它。現在我們花在審查程式碼上的時間，已經比過去花在寫程式碼上的時間還多。
2. 脈絡債務
AI 是個很厲害的短跑選手，但不是好建築師。它可以完美地建立一個函式，卻不理解那個函式會如何破壞你儲存庫裡另外 5 萬行程式碼。AI 程式碼的「整合成本」高得驚人。
3. 維護帳單
產生程式碼很便宜，維護生成式程式碼卻很昂貴。AI 常常會寫出技術上正確、但風格上很怪的程式碼。它會建立一些人類看不懂的抽象層。而六個月後，總會有人得去讀它。
我們實際該怎麼修正這件事
如果程式碼很便宜，我們就不能再把最佳化重點放在打字速度上。我們必須開始最佳化決策能力。
1. 把瓶頸移到設計。
不要叫 AI「做出這個功能」。改成請它「提出三種架構方案」。把省下來的時間用在判斷哪一種最適合你的特定情境。
2. 保護你的審查容量。
你的資深工程師現在就是瓶頸。如果 AI 產生了 1,000 行程式碼，資深工程師的腦袋就是那段程式碼能不能進到正式環境之間的唯一防線。要替他們爭取更多審查時間。
3. 重點放在「刪除」，而不是「撰寫」。
AI 最好的用途不是新增程式碼，而是刪除舊程式碼。用它來整理混亂的架構、撰寫缺少的測試、重構舊系統。用速度來降低你的維護負擔。
令人不舒服的真相
AI 沒有讓軟體工程變簡單。
它只是把工作從「寫程式碼」變成了「編輯程式碼」。
而編輯，需要比寫作更深入地理解整個系統。
如果你不懂 AI 幫你產生的程式碼，那段程式碼就不屬於你。是程式碼擁有了你。而你正在累積的技術債，終究是要還的。
寫程式碼現在已經成了一種商品。真正的價值在於：你是否知道該做什麼、它如何融入整體架構，以及如何確保它安全。
你不需要再成為更快的程式設計師。你需要成為更好的系統思考者。
我現在很好奇，因為我知道我不是唯一感受到這種轉變的人。
你是否也注意到，AI 讓你打字變快了，但你的功能上線時間還是一樣長？你們團隊目前最大的瓶頸在哪裡？
是審查？測試？還是架構？
歡迎在下方留言。我們一起來想想，新的「10 倍工程師」到底應該長什麼樣子。
原文出處：https://dev.to/harsh2644/ai-made-coding-cheaper-so-why-is-building-software-still-so-expensive-59m
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
