我用 Fable 5 在不寫程式碼的情況下，打造了一個完整端到端的全端應用程式。然後我發現了一些嚇到我的東西。

我當軟體工程師已經好幾年了。最近大家都在談論 Fable 5 有多強大，所以我想親自確認。
我做了一個實驗。
我用 Fable 5 建了一個全端網頁應用程式。沒有傳統的編碼。我描述我想要的功能、檢視產生出來的程式碼，然後讓 AI 負責實作。
老實說，第一印象很驚人。
在很短的時間內，我就得到了看起來像真正產品的東西。介面很精緻。驗證能正常運作。資料庫也已連上。主要功能都有在。如果我把它給別人看，卻不說明是怎麼做出來的，他們大概不會猜到其中大多是由 AI 生成的。
我記得自己心裡想：「這也太瘋了。也許我們比我想像得更接近了。」
接著我就像在審查任何真正的上線系統那樣，開始檢視程式碼。
就在那時，興奮感開始消退。
這個應用看起來已經完成了，但我越往更深處看，發現的問題就越多。
有些小問題。有些則是未來可能會變成嚴重問題的事情。
有安全性顧慮。某些 API 對使用者輸入的信任太過度。沒有適當的速率限制。沒有針對假帳號與垃圾訊息的保護機制。有些資料庫查詢在使用者少的時候看起來完全沒問題，但資料量一大就會變成噩夢。
我發現了 N+1 查詢問題、缺少索引、效能瓶頸、在使用者請求期間執行耗時操作（而不是在背景執行），以及在沒有適當遷移（migrations）的情況下直接修改資料庫的變更。
最怪的是，整個系統看起來都沒有壞。它真的能用。
你可以建立帳號。你可以登入。你可以一路點過各個功能。你甚至能完成付款流程。
這就是讓人覺得有意思的地方。
很多人用 AI 做出來的東西，並不是那種一眼就能看出明顯壞掉的應用。他們推出的是看起來已完成、但底下其實藏著問題的應用。
漂亮的 UI 不會拯救一個壞掉的後端。
在上線之前，我會確保你真的有測過：
• 登入與密碼重設
• 真實的信用卡付款（不是只有測試模式）
• 在真實網域上啟用 SSL
• 分開開發與上線（production）的環境
• API 金鑰沒有在任何地方被公開
• 上線資料庫備份確實能正常運作
安全性問題是另一種通常會到太晚才浮現的東西。很多應用在規模小的時候不會被濫用。他們是在開始被注意到之後才被濫用。
像這些：
• Email 驗證
• 速率限制
• 輸入驗證
• 基本的防機器人機制
可能就差在：能不能順利上線，或是醒來時發現已被成千上萬個假帳號攻擊。
效能也是另一個陷阱。當你只有自己一個使用者時，所有東西都感覺很快。問題會在真正的使用者出現後才冒出來。突然之間，你會遇到慢的資料庫查詢、載入上千筆記錄的頁面、昂貴的工作阻塞請求，以及完全不知道是什麼在失敗，因為沒有任何監控。
分頁、資料庫索引、背景任務與錯誤監控，不是你成功之後才新增的東西。這些才是你在開始成長時能活下來的關鍵。
我從這次最重要的教訓之一是：不要讓 AI 直接修改你的上線資料庫結構（schema）。
使用遷移（migrations）。
遷移只是一個描述資料庫變更的小檔案，例如新增一個欄位或建立一張表。它會依序執行、可以被追蹤，並讓你的開發與上線環境保持一致。它在一開始看起來像是額外工作，但它能避免之後一堆痛苦的問題。
有趣的是，這個實驗反而讓我對 AI 寫程式更樂觀。
Fable 5 很強大。它幫我省下了大量時間。
但「生成一個應用程式」跟「打造一個上線等級的系統」之間是有差別的。
AI 能以驚人的速度寫出程式碼。
但它不會自動知道那些來自多年面對真實使用者、安全性問題、擴充（scaling）議題，以及上線失敗所做出的決策。
我一直在把我發現的所有事情記錄下來，因為我覺得很多人現在正在建置並上線由 AI 生成的應用，卻沒有意識到這些問題是存在的。
這個週末，我打算和我在 Google 工作的朋友一起舉辦一場免費的即時 Zoom 講座。我們會實際帶你看那個應用、展示我們找到的問題、解釋為什麼這些問題重要，並且一起討論在把它交給真實使用者之前我們會怎麼修。你如果有興趣，私訊我，我會把 Zoom 講座的資訊寄給你。
總的來說，最讓我驚訝的部分並不是 AI 做錯了。是這個應用在我開始往更深處看之前，竟然看起來如此令人信服。
我很好奇：如果你做過「氛圍編碼（vibe-coded）」的應用，你在上線之後第一個發現的、出乎意料的問題是什麼？