最近公司在推行 Claude Code，趁著周末的下午也抽空訂閱試用了一下。順便下周開工時說一下我的體驗順便給部門裡的 TPM 與工程師們一點壓力。

結果比我預期還要震撼。感覺是 Cursor Agent 模式的更進化更準確版本。

我一邊用 Claude Code，一邊讓 ChatGPT 和 Cursor 教我怎麼用，前後不到兩個小時，就把一個有前後端的網頁版熱錢包用 Spring Boot 生出來了。

而且這兩個小時裡，還不是全都在寫功能。我其實還花了一些時間在處理比較「人類時代」的事情，像是抓 JDK、安裝 Maven、設定環境變數。這一段目前看起來還沒有完全自動化，所以我還是手動裝了一輪。

當然，第一次生出來的程式不是一鍵就能跑。

實際上，剛開始跑起來還是有錯。我猜一部分原因是我沒有先把規則、結構、慣例定義得夠清楚，所以 AI 一開始雖然很快，但不夠穩。不過有趣的是，後來也幾乎不用我真的下去改 code，而是讓 AI 讀錯誤、修錯誤、再重跑，最後把它自己生出來的問題一個個補起來。

那種感覺很奇妙。

以前我當工程師的時候，對 IDE 快捷鍵很熟，TDD、重構、抽 method、切 service、調整 package structure，很多樂趣都在那個過程裡。你會一邊寫，一邊思考這段程式應該怎麼依據功能需求長大、縮小、拆分，哪些責任該留在 service，哪些該往 domain 或 adapter 挪，整個寫程式的過程，其實很像是在雕一個會呼吸的東西。

但現在的 coding 體感，好像正在換一種樣子。

你不再一定是那個逐行敲 code 的人。

反而更像是一個 PM，在指揮一位非常熟練、很聽話、反應極快的工程師。

或者像是在 pair programming，只是你成了那個幾乎只出一張嘴的人。

目前還是要靠我把字打出來。但我認真覺得，接下來更快的協作方式，很可能不是打字，而是直接用說的。再往後一點，甚至不排除是更直接的腦機介面。到那個時候，軟體開發的核心能力，可能不再只是「會不會寫」，而是：

你能不能清楚定義需求、拆解問題、建立規則、判斷品質、引導 AI 持續收斂。

這件事也讓我重新思考一個問題：

未來的軟體部門，真的還需要像現在這樣的人力規模嗎？

也許很多情境下，答案會是不用。

一個真正懂軟體工程的人，搭配足夠成熟的 AI 工具，生產力可能真的會逐漸接近過去一整個團隊。

這不代表軟體工程專業不重要。

剛好相反。

因為當 AI 越來越會寫，真正有價值的會變成那些「知道怎麼讓系統長對、切對、修對、收斂對」的人。

工具正在改變，角色也正在改變。

寫程式這件事，也許沒有消失，只是從「親手施工」慢慢變成了「高密度設計與指揮」。

而這個轉變，可能比很多人想像得還快。