AI 倍增器：為何技術專業比以往任何時候都更重要

軟體產業中關於人工智慧的主流論述，往往在兩個極端之間擺盪：一種是「vibe-coding」的烏托邦願景，認為任何人只要透過幾個提示詞就能開發出應用程式；另一種則是恐懼人類開發者很快就會被淘汰的烏托邦式擔憂。然而，仔細觀察這些工具的實際使用方式，會發現一個不同的現實。

AI 並不是開發者的替代品，而是一個力量倍增器。LLM 的效能並非恆定不變——它是一個變數，會根據使用者的技術熟練度而進行縮放。

「Vibe-Coder」的悖論

目前有一種日益增長的「vibe-coding」趨勢，即幾乎沒有正式開發經驗的人利用 AI 來生成 MVP (Minimum Viable Products)。對許多人來說，最初的體驗是令人陶醉的。他們可以在幾分鐘內產出一個可運作的介面或基本功能，這導致了一種認為進入門檻的「技術障礙」已經消失的錯覺。

然而，這往往會導致一個關鍵的瓶頸。由於缺乏軟體架構的基礎理解，使用者經常發現自己陷入了「與幽靈爭論」的困境。因為 LLM 生成程式碼是為了滿足即時、孤立的提示詞，而不是從整體角度思考應用程式的長期結構，因此它們很容易讓開發者陷入困境。

正如一位開發者在社群討論中所提到的，在這些「vibe-coding」期間生成的程式碼看起來可能很正確，且在當下可以運作，但卻是「瞬間變成維護上的死胡同」。其結果是一個脆弱的系統，單個 bug 可能導致長達三小時的提示詞循環，而這本該是開發者在知道該去原始碼哪裡尋找答案時，只需三十秒就能解決的問題。

專家的優勢：AI 如同鋼鐵人裝甲

相反地，對於高技能開發者而言，AI 扮演著巨大的生產力放大器。當一位領域專家——理解記憶體管理、佈局引擎或複雜狀態同步的人——使用 LLM 時，其結果是具變革性的。

以 Matt Perry 的例子為例，他是幾款知名動畫函式庫的創作者。透過利用 AI，Perry 在單個季度內關閉了 160 個 issues，（超過了 60 個的目標），並在一個下午內完成了一個複雜函式庫的大規模重構。這並不是因為 AI 比開發者更「強」，而是因為開發者確切地知道要問什麼、如何驗證輸出結果，以及如何將程式碼整合進一個複雜的架構中。

這種關係類似於鋼鐵人的裝甲：技術提供了驚人的力量，但它需要一位擁有技能與判斷力的飛行員來有效地引導這股力量。如果沒有飛行員，裝甲就只是一堆金屬。

新的護城河：架構與判斷力

如果 AI 可以撰寫語法，那麼專業開發者的「護城河」還剩下什麼？答案在於工程學的高階技能：

• 架構願景： 決定「要」建立什麼，以及「如何」建構結構，使其能維持多年的可維護性，而不僅僅是幾天。
• 技術判斷力： 了解哪種技術適合該任務，並理解特定實作方式的安全性影響。
• 驗證與除錯： 能夠閱讀 AI 生成的程式碼，並發現 LLM 可能會自信地堅持其正確性的細微邏輯錯誤。
• 複雜問題分解： 將龐大且模糊的業務需求分解為一系列精確的技術提示詞，讓 AI 能夠實際執行。

正如 Simon Willison 指出的，建立像安全的 iframe sandbox 這樣的系統，需要對瀏覽器安全模型與平台演進的深厚知識——這些知識是「vibe-coder」無法單純透過提示詞就創造出來的。

AI 時代的學習曲線

最迫切的擔憂之一是下一代開發者將如何學習。如果 AI 處理了程式碼撰寫的「摩擦力」，初級開發者是否會失去掙扎——進而學習基礎知識——的機會？

存在一種風險，即 AI 帶來的即時滿足感可能會削弱成為專家所需的毅力。然而，這也是一個機會：對於那些有毅力深入鑽研的人來說，AI 可以充當個人化的研究助手，加速通往專業知識的道路。關鍵在於使用 AI 來詢問「這是如何運作的？」而不是僅僅詢問「修復這個」。

結論

AI 正在改變軟體工程師的價值主張。撰寫語法已成為一種商品化服務，但設計工程系統的能力正變得越來越有價值。對於那些專注於深層技術專業的人來說，AI 不是威脅——它是他們有史以來獲得過最強大的工具。