會跑、能用，跟能不能維護，原來是三件完全不同的事。

最近我遇到兩個很有意思的例子。

兩個都是 HR。

其中一個甚至不是 HR 科班出身。

她以前學的是烹飪，後來半路轉到 HR。

照以前的職涯分類來看，她跟「軟體開發」這四個字，大概隔了三個部門、兩棟辦公大樓，再加一條高速公路。

結果最近她靠 AI 做了什麼？

做了一套可以讓公司業務練習談判技巧的系統。

又做了公司網站。

然後連基本的打卡、差勤系統都開始自己做。

我第一次聽到的時候，腦中的反應其實是：

現在轉職的跨度是不是有點太大？

以前從廚師轉 HR 已經算跨領域。

現在：

廚藝 → HR → Software Developer。

而且中間還不用去資策會。

---

但另外一個案例，就沒有這麼勵志了。

同樣也是用 AI 做系統。

畫面打開。

有表格。

有按鈕。

可以新增。

可以修改。

甚至 Demo 起來還滿像那麼一回事。

大家第一眼：

「欸，可以耶。」

然後 IT 開始看。

五分鐘後沉默。

再看一下 Database。

沉默得更久。

資料結構亂七八糟。

同樣的資料在不同地方存了好幾份。

欄位用途前後不一致。

一些邏輯寫在前端。

一些寫在後端。

還有一些……

可能只有 AI 知道為什麼放在那裡。

最後 IT 的表情大概就是：

「你要我修……還是你要我重寫？」

這兩個例子放在一起，我反而覺得非常有代表性。

因為它告訴我們：

AI 的確正在把 Software Creation 民主化。

但民主化之後，新的問題也才真正開始。

---

AI 已經證明：不會寫程式，也真的可以做出程式

這件事情現在已經不太需要爭論。

2026 年 CHI 有一篇很有意思的研究，研究者調查 85 人、訪談 31 位 hackathon 參與者與 8 位實務工作者，觀察技術與非技術使用者如何利用 GenAI 建立軟體。

結果發現，現在的雲端 AI 開發環境確實可以讓沒有技術背景的人快速做出高擬真的 Prototype。研究甚至特別使用了「throw-away prototype」這個概念：有些東西的價值本來就不是成為大型正式系統，而是讓你快速把想法變成可以真的操作的東西。(From Throw-Away to Takeaway: How GenAI and Vibe Coding Accelerate Prototyping Across Technical Skill Levels)

另一項 2025 年研究直接找非程式設計者用 AI 建 Web App，多數參與者都能在合理時間內完成基本應用。作者認為，AI-assisted end-user coding 已經有可能成為 Low-code / No-code 之外的新型 End-User Development。(Feasibility of AI-Assisted Programming for End-User Development)

所以第一位 HR 的故事，其實完全符合這個趨勢。

問題已經不再是：

「她會不會 JavaScript？」

而變成：

「她能不能把自己想解決的問題說清楚？」

這個變化非常大。

---

過去寫程式的第一道牆，是 Syntax

以前一個 HR 想做差勤管理系統。

第一件事情不是想：

「差勤應該怎麼管理？」

而是：

「我不會寫程式。」

於是結束。

需求根本還沒開始討論，就死在技術門檻前面。

AI 把這道牆拆掉了。

現在可以直接跟 Agent 說：

「我要一個員工打卡功能，可以記錄上下班時間，主管可以看異常紀錄。」

AI：

「好的。」

然後開始生 Database。

生 API。

生畫面。

生 Login。

以前需要好幾種技能才能跨過去的地方，現在一句自然語言就可以開始。

這也是為什麼 IEEE Computer 在 2025 年討論 Citizen Development 時認為，Generative AI 正進一步降低非專業開發者建立 Business Applications 的門檻。(Citizen Development, Low-Code/No-Code Platforms, and the Evolution of Generative AI in Software Development)

但是——

第一道牆拆掉，不代表後面的牆都不存在。

---

因為「做出來」其實只是軟體工程的第一關

我現在愈來愈覺得，AI Coding 最容易讓人產生的一個錯覺是：

畫面可以動 = 系統做好了。

不是。

至少可以把軟體分成五個層次：

第一層：做得出來

按鈕按下去有反應。

第二層：真的能用

使用者完成得了工作。

第三層：資料是對的

Database、流程、權限與 business logic 沒有互相打架。

第四層：別人維護得了

半年後另一個人接手，不需要先進行數位考古。

第五層：公司敢負責

Security、Backup、Audit、Privacy、Availability 都有人知道發生什麼事情。

AI 現在非常擅長把：

0 → 1

變得非常容易。

甚至可以把：

1 → 2

也做得很好。

問題通常出現在：

2 → 3 → 4 → 5。

---

這就是為什麼第二個案例「看起來可以用」

這很合理。

因為使用者在 Vibe Coding 時的 Feedback Loop 通常是：

「我要這個功能。」

AI 做。

使用者按一下。

不能用。

跟 AI 說：

「這裡壞了。」

AI 改。

好了。

下一個功能。

這其實是一個非常有效率的：

Visible Behavior Optimization。

你一直在優化：

我看得到的東西能不能工作。

但底下有一大堆使用者平常看不到的東西：

Data Model。

Architecture。

Dependency。

Error Handling。

Migration。

Permission。

Transaction。

Logging。

Testing。

這些東西平常完全不會跳出來跟你說：

「嗨，我現在設計得很爛喔。」

它們通常會等半年。

等系統真的開始有人依賴。

再一起出來。

---

研究真的已經看到這個問題

2025 年一篇研究直接把它稱為 Vibe Coding 的 flow-debt trade-off。

AI 讓開發流程變得非常順暢，因此人很容易一直：

Prompt → Generate → Run → Continue。

但速度越快，背後可能越容易累積：

• architecture inconsistency
• security vulnerability
• maintenance overhead
• 缺乏設計理由

也就是我們熟悉的：

Technical Debt，技術債。 (Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use)

更有意思的是，2026 年一項大規模研究分析了 6,275 個 GitHub repositories、304,362 個經驗證的 AI-authored commits。

研究者找到 484,606 個由 AI changes 引入的問題，其中約 89% 屬於 code smells；而被追蹤的 AI 引入問題中，大約 24.2% 一直到最新版 repository 都還存在。(Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use)

所以 AI 不是一定寫出爛 Code。

但問題在於：

它寫 Code 的速度，可能比人理解 Code 品質的速度快很多。

這就是麻煩開始的地方。

---

最有趣的是 Gartner 今年甚至直接點名這件事

2026 年 Gartner 有一篇研究的標題非常不客氣：

“Vibe Coding to Replace Management Tools Creates Technical Debt, Not Cost Savings.”

直接翻譯大概是：

「你以為自己省了軟體費，其實只是改成欠技術債。」

Gartner 的建議主要針對 Infrastructure / IT Operations 的正式管理工具，他們並不建議企業用隨手 Vibe Coding 出來的東西去取代成熟的核心 Management Tools。(Vibe Coding to Replace Management Tools Creates Technical Debt, Not Cost Savings)

這跟我前面談 Micro Apps 並不矛盾。

反而剛好把界線畫得更清楚：

小、低風險、短生命週期的工具，可以非常適合 AI 自建。

但：

重要、長期、跨部門、高風險的系統，就不能只問「現在跑不跑得動」。

---

第一個 HR 為什麼可能成功，第二個卻讓 IT 搖頭？

我覺得這裡才是真正值得研究的地方。

差異可能根本不是：

誰比較會 Prompt。

而是另一組能力。

第一個人做業務談判訓練時，她可能不需要先理解 Kubernetes。

她真正需要理解的是：

業務在什麼情境下會卡住？

客戶會怎麼殺價？

什麼叫一個好的談判回應？

這是 Domain Problem。

AI 幫她處理 implementation。

如果範圍夠小、使用者就在旁邊、每天都能測，她可以快速：

做 → 用 → 發現問題 → 修改。

這就是 Citizen Development 最強的地方：

做系統的人，就是離問題最近的人。

---

第二種情況則很可能不同。

當系統開始有很多 Entity：

員工。

部門。

角色。

權限。

假別。

班別。

紀錄。

審核。

歷史資料。

這時候真正需要的已經不只是「功能描述能力」。

而是：

Modeling。

例如一個很簡單的問題：

「一個員工屬於一個部門。」

今天可能成立。

那員工轉調呢？

歷史記錄跟著改嗎？

還是要保留當時的 Department？

主管可以管理哪些員工？

代理主管呢？

跨部門專案呢？

到了這裡，問題就不是 AI 會不會 SQL。

問題是：

使用者有沒有意識到這些問題存在。

---

所以 AI 並沒有消滅專業，只是把專業往後移了

Microsoft Research 對 Vibe Coding 的實證研究有一個我很喜歡的結論。

AI 沒有消滅 programming expertise。

它只是重新分配了專業的位置。

以前大量專業花在：

「怎麼把這段 Code 寫出來？」

現在越來越多專業花在：

Context management、快速判斷 AI 產出的 Code，以及知道什麼時候不能再交給 AI。 (Vibe coding: programming through conversation with artificial intelligence)

這句話非常重要。

所以未來可能真的不需要每個做 internal app 的人都知道：

for loop 怎麼寫。

但有些人還是必須知道：

這個資料模型會不會害死我們。

AI 降低了：

Coding Literacy

的必要門檻。

但沒有消滅：

System Literacy。

甚至我覺得它反而會讓後者變得更重要。

---

這會是 HR 很有意思的一個新能力問題

因為這兩個案例偏偏都發生在 HR。

以前我們談 HR Digital Competency，可能包含：

Excel。

HRIS。

Data Analytics。

Power BI。

現在開始出現一個很奇怪的新階段：

HR 自己開始建立：

Training App。

Recruitment Tool。

Interview Simulator。

Attendance System。

Internal Workflow。

網站。

AI Agent。

甚至根本沒有 IT Project。

這跟最近企業裡另一個趨勢其實很一致。

Financial Times 這幾天才談到，AI 正讓員工大量跨越原本的職務邊界：廣告人開始做視覺、一般員工開始處理以前由其他專業角色負責的工作，工作之間的邊界正在變得模糊。(AI is ushering in an era of mass toe-treading at work)

所以未來 HR 的 JD 裡出現：

「具備基本應用程式建立能力」

可能沒有我們現在想像中那麼荒謬。

甚至他根本不需要會 Coding。

---

但 HR 恰好也是不能亂來的地方

這裡就要講一個很大的但是。

如果今天 HR 做的是：

業務談判練習工具。

裡面全部是假資料。

壞掉最多就是大家今天沒辦法練。

我會非常鼓勵：

做。

但是如果是：

差勤系統。

那就不太一樣。

因為裡面開始有：

員工姓名。

出勤時間。

請假。

主管關係。

甚至位置。

這就開始進入真正的 Personal Data。

功能「簡單」，不代表風險「低」。

IEEE 對 GenAI Citizen Development 的討論也特別強調：隨著更多非 IT 員工可以自己建立程式，governance、security、role-based access、testing 與 production review 反而變得更重要。(Citizen Development, Low-Code/No-Code Platforms, and the Evolution of Generative AI in Software Development)

這也是 Citizen Developer 最容易產生的錯覺：

「這只是一個小系統。」

從功能來看很小。

但：

小系統也可以存很大的秘密。

---

這很容易演變成下一代 Shadow IT

以前 Shadow IT 是：

某個部門偷偷買 Dropbox。

自己架 NAS。

用一個 IT 不知道的 SaaS。

現在開始變成：

部門自己生一套 Software。

甚至 IT 根本不知道它存在。

研究開始把類似現象稱為 Shadow User Innovation：員工利用 GenAI 自己建立解法，可能帶來很有價值的 bottom-up innovation，但如果完全脫離企業治理，也會造成新的 learning blind spot 與 control problem。(Shadow user innovation: governing covert generative-AI use for dynamic-capability renewal)

另外針對 Shadow AI 的研究也發現，正式 governance 往往追不上員工實際使用 AI 的速度，形成所謂的 governance drift；而 HR、Legal 這類高風險職能尤其值得注意。(From Shadow It to Shadow AI–Threats, Risks and Opportunities for Organizations)

所以企業如果用的方法只是：

「禁止員工自己開發。」

我猜最後的結果通常是：

他們還是會做。

只是你不知道。

---

所以 IT 未來真正重要的角色，可能不是「幫你寫」

這是我看到這兩個案例後最大的感覺。

以前：

HR 有需求。

找 IT。

IT 排需求。

做。

未來：

HR 有需求。

跟 AI 做。

那 IT 幹嘛？

我反而覺得 IT 會變得更重要。

只是 IT 從：

Developer

往：

Guardrail Provider

移動。

公司可以告訴 Citizen Developer：

你可以自己做。

但是我們提供：

指定 Deployment Environment。

公司帳號登入。

標準 Database。

Secret Management。

Backup。

Logging。

Security Scan。

版本控制。

以及幾條非常清楚的規則：

什麼可以自己上。

什麼需要 IT Review。

什麼根本不能自己上。

這會比「所有需求全部回 IT 排 Queue」合理很多。

---

我甚至會把 AI Citizen Development 分成三個區

Green Zone

放心做。

例如：

個人工作工具。

假資料 Prototype。

短期活動工具。

內部小型計算器。

Training Simulation。

壞掉也沒有重大損失。

---

Yellow Zone

可以自己做，但要進治理。

例如：

部門多人共同使用。

需要公司登入。

有內部營運資料。

會影響 Workflow。

預計使用半年以上。

這類工具至少要：

Version Control。

Backup。

Documentation。

Security Check。

IT 可接手。

---

Red Zone

不要自己 Vibe 到 Production。

例如：

Payroll。

正式 HR 個資。

Payment。

財務。

客戶敏感資料。

核心身份權限。

醫療。

Mission-critical systems。

因為到了這個階段：

工程能力不是拿來把畫面做漂亮。

而是用來避免你三年後上新聞。

---

企業真正要培養的，可能是一種新的「AI 系統素養」

所以我現在反而不太喜歡把這種人單純叫：

Citizen Developer。

因為 Developer 聽起來好像重點還是在寫 Code。

未來真正要教給一般員工的，可能是：

AI System Literacy。

至少知道：

資料應該怎麼分。

誰應該看得到什麼。

哪些資料不能亂存。

哪些功能需要留下 Audit Trail。

什麼叫 Backup。

為什麼 Production 跟 Demo 不一樣。

什麼時候應該停下來找工程師。

這些可能比教：

「Python 怎麼寫迴圈」

實際得多。

---

最近連大廠都開始往這個方向走

這件事也不是只有員工自己偷玩。

就在這幾天，Slack 推出新的 Surfaces 功能，使用者可以直接透過自然語言，在 Slack 中生成互動式 Dashboard、Report、Poll、Microsite 等工具，而不需要先離開聊天介面去使用傳統開發工具。(Slack can now vibe-code interactive charts and reports inside chats)

這其實代表軟體業自己也正在接受一個新的產品假設：

未來使用者不只「使用功能」，而是會即時「生成自己需要的功能」。

以前 Software Vendor 決定：

「你可以做什麼。」

未來可能是 Platform 提供 Guardrails，

然後使用者決定：

「我今天需要什麼 Software。」

---

最後，回到我看到的這兩個 HR

第一個案例讓我非常興奮。

因為以前一個人的 idea 可能永遠只是：

「如果公司有這個工具就好了。」

現在她真的可以把它做出來。

而且她過去讀什麼科系，開始沒那麼重要。

這是一種非常強的能力民主化。

第二個案例則讓我警覺。

因為：

能生出 Software，跟能理解 Software，正在變成兩件不同的事情。

AI 把前者變得越來越便宜。

後者反而開始變得越來越珍貴。

GitLab 2026 年的企業調查其實已經看到這種張力：78% 受訪組織表示 AI 讓 Code 產出速度提高，但 73% 擔心 AI-generated code 的 maintainability，82% 擔心它形成企業還沒有準備好管理的新型 Technical Debt。(GitLab Research Reveals Organizations Are Generating AI Code Faster Than They Can Control It)

也就是：

Code 不是不夠了。

現在可能是 Code 太多了。

---

AI 時代真正的門檻，從「會不會做」移到了「知不知道自己在做什麼」

以前如果你不會寫程式，

你做不出爛系統。

當然。

你也做不出好系統。

AI 把這個限制拿掉了。

現在每個人都有機會做出非常棒的工具。

同時，每個人也有機會用兩天時間，

做出一個連 IT 都不知道該從哪裡開始救的東西。

這不是 AI 的缺點。

反而是每一次技術民主化都會出現的結果。

攝影變容易之後，不代表每張照片都變好看。

出版變容易之後，不代表每篇文章都值得讀。

現在輪到 Software。

所以接下來我們真正該問的可能不再是：

「員工可不可以用 AI 自己做軟體？」

這個問題大概很快就沒有意義。

真正重要的是：

「當所有人都可以做軟體之後，我們要怎麼讓好的創意快速長出來，同時又不要讓公司長滿沒有人敢碰的系統？」

第一個問題叫 Innovation。

第二個問題叫 Engineering。

而 AI 很有趣的地方就在這裡：

它讓第一個問題變容易了。

於是，

第二個問題終於變得非常明顯。