軟體開發的終結？應對 AI 轉型浪潮
大型語言模型 (LLMs) 的興起在工程社群中引發了兩極化的辯論：軟體開發作為一種職業正在走向消亡，還是僅僅是在演進？非程式設計師透過提示詞 (prompt) 就能在幾分鐘內獲得一個功能完備的應用程式，這讓一些人擔心未來程式設計會變成一種商品化——一種「速食」工作，隨著 API 成本取代開發者薪資，薪資將會大幅下降。
雖然這種焦慮感顯而易見，但仔細觀察交付生產等級軟體的現實情況後會發現，開發者的「消亡」其實是對軟體工程本質的誤解。資深從業者達成的共識是：雖然「寫程式 (coding)」正在商品化，但「工程 (engineering)」正變得比以往任何時候都更有價值。
寫程式與工程之間的區別
業界最持久的誤解之一是認為軟體開發主要是關於寫程式碼或精通特定語言的語法。然而，正如許多資深人士所指出的，寫程式碼的行為本身鮮少是整個流程中最困難的部分。
問題解決 vs. 語法
寫程式碼是解決問題的工具，而不是問題本身。真正的挑戰在於確定要實作什麼、定義功能如何互動，以及根據技術與業務限制做出關鍵的權衡。
"Actually writing code was never the difficult part for the majority of software created... the really hard part was figuring out what to implement in the first place."
當語法的進入門檻降低時，焦點就會轉移。開發者的價值不再在於記住函式庫功能的特定參數，而是在於他們架構系統以高效解決現實世界問題的能力。
"v0.0.1" 的陷阱
「能運作」的原型與可以擴展的產品之間存在著巨大的鴻溝。LLMs 在生成初始草案——有些人稱之為 "v0.0.1"——方面表現卓越，但它們在處理生產等級軟體的嚴格要求時往往顯得吃力：安全性、擴展性、邊緣案例處理以及長期可維護性。
正如一位貢獻者所提到的，AI 生成的應用程式可能對少數人有效，但它缺乏根據客戶回饋進行迭代的靈活性，也缺乏處理百萬用戶的穩健性。將一個專案從基於提示詞的草案轉向可行的商業模式所需的引導，仍然是一項深刻的人類技能。
經濟轉型：樣板程式碼 vs. 價值
從經濟角度來看，軟體的「商品化」已經在發生，但僅限於特定類型的工作：樣板程式碼 (boilerplate)。
"Pretender" 的興起
「程式碼猴子 (code monkeys)」——那些依賴詳細描述來產出標準 CRUD 應用程式的人——與理解底層工藝的工程師之間，正在產生日益嚴重的分歧。對於那些主要價值在於撰寫樣板程式碼的人來說，威脅是真實存在的。如果一項任務可以使用 LLM 在一天內完成，投資者和公司將不太可能為這種特定的技能組支付溢價。
提高門檻
矛盾的是，AI 可能實際上會提高對「有意義的軟體」的標準。當生產基礎軟體的成本降至接近於零時，市場將充斥著低質量的「垃圾內容 (slop)"。為了脫穎而出，開發者必須向價值鏈的上游移動，專注於高度關鍵的系統、複雜的領域邏輯以及能取代產業的解決方案。
人類因素：協調與領域專業知識
在企業環境中，寫程式碼的技術行為通常是交付流程中最簡單的部分。真正的核心工作涉及：
- 領域理解 (Domain Understanding): 深入理解業務問題與使用者的痛點。
- 跨職能協調 (Cross-functional Coordination): 與其他團隊合作、管理利害關係人並組織開發路線圖 (roadmap)。
- 系統架構 (System Architecture): 確保系統的不同部分能夠可靠且安全地進行通訊。
這些「高階」任務目前仍超出了 LLMs 的能力範圍。開發者的角色正在轉向技術產品經理或系統架構師，利用 AI 來加速實作階段。
"Vibe Coding" 時代的風險
儘管存在樂觀情緒，但對於 AI 對專業成長的影響，仍存在合理的擔憂。一些開發者報告了一種向 "vibe coding" 轉向的趨勢——不斷輸入提示詞直到某個東西能運作，卻不深入理解 why 它能運作。
這在學習過程中造成了一個危險的真空。當開發者被要求使用 AI "ASAP" 交付任務時，他們可能會跳過閱讀文件與從基本原理進行除錯 (debugging) 的掙扎過程——而這正是建立工程直覺的過程。對於下一代開發者來說，挑戰將是如何在即時滿足的時代中，避免其基本技能的萎縮。
結論：前行的道路
軟體開發並未消亡；它正在蛻皮。就像從打字機轉向文字處理器一樣，「專門的打字員」時代已經結束了。雖然進入門檻降低了，但卓越的標準卻從未如此之高。現代開發者的轉型方向並非逃離這個產業，而是停止將自己定義為「程式設計師 (coder)"，並開始將自己定義為「問題解決者 (problem solver)"。