當 AI 寫完所有程式碼

Anthropic 的 Claude Code 負責人 Boris Cherny 最近在 Lenny's Podcast 丟出一個震撼彈：他已經超過三個月沒有手動編輯過任何一行程式碼，每天靠 Claude Code 產出 10 到 30 個 PR。他把這件事比喻成印刷術的發明——一項曾經由少數人掌握的技能，正在被徹底民主化。

這段話我聽了好幾遍。不是因為數字驚人，而是因為他描述的狀態，跟我過去幾個月的體驗高度吻合。

寫程式已經不是瓶頸了

Boris 說了一句很直接的話：「Coding is largely solved.」

身為一個在醫療資訊領域打滾多年的人，我對這句話的感受很深。過去我花大量時間在處理 Legacy 系統的 migration、寫 FHIR API adapter、搞 Kafka event bus 的串接。這些工作的瓶頸從來不是「不會寫」，而是「要處理的細節太多、太瑣碎」。

現在有了 AI coding 工具，這些瑣碎的部分被大幅壓縮了。我可以把更多時間放在真正重要的事：系統該怎麼設計、資料流該怎麼走、介面該怎麼跟臨床流程對齊。

從 Software Engineer 到 Builder

Boris 預測「軟體工程師」這個職稱會消失，取而代之的是「Builder」。他描述 Anthropic 團隊的現況：PM 寫程式、設計師寫程式、財務寫程式、資料科學家也寫程式。角色之間有 50% 的重疊。

這跟我一直在推動的事不謀而合。在醫院裡，資訊室的編制永遠不夠。我們不可能為每個需求都排一個工程師。但如果護理師能用 AI 工具自己建一個排班輔助工具呢？如果臨床研究員能自己串接 FHIR API 拉資料做分析呢？

這正是我說的 Omakase Smart Hospital 的核心理念之一——不是把所有事情都丟給資訊室，而是讓每個人都有能力成為 Builder，用技術解決自己遇到的問題。AI coding 工具讓這件事第一次變得真的可行。

真正的競爭力在哪裡

Boris 的訪談裡有一個觀點特別值得注意：真正的競爭優勢不在寫程式的速度，而在於需求拆解、清晰定義與正確驗證。

這在醫療場域尤其明顯。一個寫得很快但需求理解錯誤的系統，上線後就是災難。我見過太多案例：廠商交付的系統功能齊全，但完全不符合臨床實際流程。問題不是出在程式碼品質，而是出在「沒有真正理解需求」。

AI 可以幫你寫程式，但它沒辦法幫你理解一個急診護理站的真實工作流程。知道要做什麼，比知道怎麼做更重要。

印刷術的隱喻

Boris 借用了一個 15 世紀抄寫員的故事：當印刷術出現，抄寫員發現自己真正喜歡的不是抄寫本身，而是插圖和裝訂。

這個隱喻很精準。回頭看我自己的工作，我真正享受的從來不是敲鍵盤寫 code。我享受的是：站在白板前畫架構圖、跟臨床團隊討論痛點、設計一個讓護理師操作更順的介面、看到系統上線後真的解決了問題。

AI coding 工具把我從瑣碎的實作細節中解放出來，讓我能花更多時間做這些真正有價值的事。這不是取代，是解放。

給想要開始的人

根據我自己的經驗，整理幾個實踐方向：

先讓自己大量使用：不要一開始就想著 ROI 和成本最佳化。給自己足夠的空間實驗，找到最適合自己工作流程的方式
從小專案開始，但要是真的專案：不要只拿來寫 todo app。拿一個你真的需要解決的問題，用 AI 工具從頭到尾做一次
擁抱通才角色：不要侷限自己是「後端工程師」或「前端工程師」。AI 工具讓跨域變得更容易，善用這個優勢
把省下的時間投資在理解需求：寫程式變快了，但理解問題沒有捷徑。把省下來的時間拿去跟使用者聊天、觀察實際操作流程

寫在最後

Boris 說他從未像今天這樣享受寫程式。我完全同意。不是因為 AI 讓寫程式變簡單了，而是因為它讓我能專注在真正讓我興奮的部分——設計系統、解決問題、為醫療現場創造價值。

工程師的價值從來不是打字速度。當 AI 接管了打字的部分，剩下的才是我們真正的專業。