一位 CEO 宣稱 AI 取代開發者，隨後整個工程社群打開了 DevTools

一位 CEO 宣稱 AI 取代開發者，隨後整個工程社群打開了 DevTools

一個關於 AI、軟體工程，以及「發佈程式碼」與「發佈生產系統」之間差異的故事。

幾天前，一位越南 CEO 的貼文在當地科技社群引發軒然大波。

他的說法相當大膽。

「我每個月付大約 20 美元給 Claude。它已經取代了我們內部軟體的開發者。」

他主張，中小企業不再需要軟體開發者、昂貴的 SaaS 訂閱，或是數個月的開發時間。

只要用自然語言描述需求，AI 就能直接建構出來。

這篇貼文迅速在社群媒體上傳播。

數千人表示認同。

有人視之為軟體開發的未來。

也有人認為這是軟體工程師的終結。

似乎每個人都發表了自己的看法。

然而，幾天後，發生了一件有趣的事。

有幾位工程師成功找到這篇爆紅貼文背後的應用程式。

出於好奇，他們做了工程師最自然會做的事。

他們打開網站。

按下 F12。

打開了 DevTools。

一開始，沒有人想證明誰對誰錯。他們只是想了解這套應用程式是如何建構的。

隨後，第一張截圖出現了。

「等等……這為什麼會暴露在前台？」

幾分鐘後，又出現另一張。

「這個憑證不應該放在這裡。」

接著又是一張。

「管理頁面真的有保護嗎？」

更多工程師加入討論。

有人檢查 JavaScript bundle。

有人監控網路請求。

有人追蹤 API 呼叫。

幾小時內，截圖、程式碼片段與技術分析開始在越南的工程社群中廣泛流傳。

一項發現變成五項。

五項變成二十項。

討論的焦點不再是「AI 是否能生成程式碼」。

而是轉變成一個更有趣的問題：

「可運作的軟體」與「可上線生產的軟體」之間，究竟有什麼差別？

---

第一印象

公平地說，這套應用程式的外觀意外地不錯。

介面乾淨。

有身份驗證功能。

使用者可以登入。

資料可以建立與更新。

如果有人只給我看示範影片，我大概會說：

「哇，AI 真的越來越厲害了。」

老實說，我至今仍這麼認為。

因為接下來發生的事，並不是在證明 AI 很糟糕。

而是在證明：軟體工程遠遠不只是寫程式碼。

---

前五分鐘

經驗豐富的工程師通常最先檢查的不是 UI，而是瀏覽器已經知道的事。

幾分鐘內，幾個問題就變得顯而易見。

敏感的設定值直接暴露在前台。

不應該出現在客戶端程式碼中的憑證，卻可以被存取。

管理功能實際上並沒有授權保護。

在某個案例中，只是用 CSS 隱藏起來。

瀏覽器本來就不應該顯示它。

但沒有人阻止使用者直接導航過去。

有些 API 端點過度信任前端。

多個本該在伺服器端執行的安全檢查，似乎都不存在。

在多處，應用程式假設使用者會誠實行事。

但軟體很少會被誠實的使用者攻擊。

最有趣的是：

這些發現都不需要複雜的黑客技術。

只需要一個瀏覽器。

幾分鐘時間。

以及 DevTools。

---

這些都不是 AI 的 Bug

這正是許多討論走偏的地方。

人們馬上會說：

「看吧？AI 寫的程式碼很糟糕。」

我認為這不是事實。

Claude 並沒有隨機決定暴露機密。

它也沒有故意用 CSS 取代授權機制。

它更不會一早起床就想：

「今天我要忽略安全最佳實踐。」

它只是針對被指派的任務進行最佳化。

如果提示是：

「幫我建立一個管理後台。」

那它就會建立一個管理後台。

而不是一個安全的生產系統。

這是兩個截然不同的要求。

AI 只是做了它被要求做的事。

真正的問題不在 AI。

真正的問題在於：人們誤以為「生成程式碼」就等於「工程化軟體」。

事實並非如此。

---

Demo 成功了，但工程還沒完成

這是我們產業多年來一直難以解釋的事。

許多人以為軟體工程就是寫程式碼。

其實不是。

寫程式碼只是工作的一小部分。

真正的工程發生在看不見的層級。

是使用者從來不會注意到的東西。

例如：

• 身份驗證
• 授權機制
• 機密管理
• 速率限制
• 稽核日誌
• 監控
• 備份策略
• 災難復原
• 資料庫遷移
• 基礎架構
• 威脅建模
• 高負載下的效能
• 合規性
• 安全審查

這些都不會出現在產品 Demo 中。

這些也不會讓新創公司的發佈影片看起來更酷。

然而，正是這些東西決定了軟體能否在生產環境中存活。

---

AI 改變了成本曲線

這其實是最令人興奮的部分。

五年前，要建構一個 MVP 需要一支團隊。

而今天呢？

一位創辦人搭配 AI，就能在一個週末打造出令人驚豔的東西。

這非常了不起。

老實說，我很喜歡這一點。

更多人可以驗證想法。

更多新創公司可以進行實驗。

更多企業可以自動化重複性工作。

AI 大幅降低了建立軟體的成本。

這絕對是件好事。

但降低建立軟體的成本，並不會消除對工程的需求。

它只是改變了工程創造價值的所在之處。

---

這份工作從來不只是寫程式碼

這大概是我在網路上看到最大的誤解。

人們以為開發者拿薪水是為了打字。

不是這樣的。

我們拿薪水是為了降低不確定性。

我們拿薪水是為了降低風險。

任何人都可以生成程式碼。

而經驗能幫助回答以下問題：

• 如果有人繞過前端，會發生什麼事？
• 使用者是否能存取其他客戶的資料？
• 如果這項服務離線了怎麼辦？
• 我們如何在不中斷服務的情況下輪換機密？
• 這套架構在百萬使用者規模下是否仍能運作？
• 部署失敗後，我們如何恢復？
• 當生產環境在凌晨 2 點發生問題時，我們需要哪些遙測資料？

這些問題很少出現在提示詞裡。

但它們每天都會在生產環境中出現。

---

Vibe Coding 不是敵人

事實上，我每天都在使用 AI。

• Claude
• GPT
• Gemini
• Cursor
• GitHub Copilot

它們讓我大幅提升速度。

AI 可以寫 boilerplate。

AI 可以解釋不熟悉的程式碼。

AI 可以生成測試。

AI 可以審查 pull request。

AI 幫助我在數小時內完成原型，而不需要花費數天。

這是我用過最好的生產力工具之一。

但我不會把「加速」與「專業能力」混為一談。

把一輛 F1 賽車交給剛拿到駕照的人，並不會造就一位 F1 車手。

它只會造就一位更快的初學者。

AI 的情況也是如此。

---

這裡到底發生了什麼？

諷刺的是，這個故事的重點並不在 CEO。

也不在 Claude。

甚至不在安全漏洞。

它揭露了更深層的問題。

多年來，許多人——包括我們自己的產業——都誤把軟體工程等同於寫程式碼。

AI 打破了這個幻覺。

寫程式碼的成本每月都在下降。

但工程判斷力卻沒有。

如果說有什麼變化，那就是 AI 讓工程判斷力變得更加珍貴。

因為現在任何人都可以生成數千行程式碼。

困難的部分，是判斷這數千行程式碼是否應該上線生產。

---

我的看法

我認為 AI 並沒有取代軟體工程師。

我認為 AI 取代的是我們過去誤以為是「這份工作」的那一部分——

也就是打字寫程式碼。

真正的工作一直都是：

• 理解系統。
• 管理複雜度。
• 為失敗進行設計。
• 保護使用者。
• 做出良好的工程決策。

諷刺的是，AI 讓這些技能比以往更加有價值。

因為當任何人都能生成程式碼時……

最困難的部分不再是寫軟體。

而是判斷那個軟體是否值得被部署。

---

最後的想法

那篇爆紅貼文有一點並沒有錯。

AI 已經從根本上改變了軟體開發。

它降低了門檻。

它賦權給創辦人。

它讓個別開發者的生產力大幅提升。

這值得慶祝。

但工程社群的回應也提醒我們一件同樣重要的事。

「在 Demo 中令人印象深刻的軟體」與「能在生產環境中存活的軟體」，有著巨大的差別。

前者證明了一個想法。

後者則贏得了信任。

而信任，一直以來都是最難工程化的東西。

或許這個故事最大的啟示，不是 AI 會不會取代開發者。

而是 AI 終於迫使我們回答一個我們產業多年來一直迴避的問題：

軟體工程師到底在做什麼？

而也許，這是我們第一次能給出比「我們寫程式碼」更好的答案。

---

你怎麼看？

AI 是否改變了成為軟體工程師的意義？

還是它只是揭示了軟體工程原本就一直存在的本質？