重點:AI 是放大器:你架構清楚就被加速,系統理解不夠就讓問題擴散更快。工程師的價值沒降低,只是換了形狀。
最近跟幾個工程師朋友聊天,話題都繞不開同一件事:
「AI 會不會取代我們?」
我的答案可能會讓你不太舒服。
如果你只知道用 AI 工具加速,被取代是遲早的事。
AI 加速不了的東西,比你想像中多
我自己也在摸 Agentic Coding 工具,Claude Code、Codex、Antigravity 這些。用了一陣子之後我發現一件很有趣的事。
以前寫 code 慢,慢在打字、查文件、debug。這些 AI 都能幫你加速,沒問題。
但有些東西加速不了:
- 你對系統架構的理解程度,AI 加速不了
- 你拆解需求的能力,AI 加速不了
- 你判斷「這裡該不該動」的經驗值,AI 加速不了
AI 做的事情是放大,不是魔法
- 你本來架構就想得清楚,AI 幫你更快地把想法落地——放大優勢
- 你本來對系統理解就不夠,AI 幫你更快地把問題擴散到整個 codebase——放大劣勢
就這樣。沒有魔法。
我自己就踩過這個坑
過年的時候我重建了整套 Claude Code 的開發環境,研究了一輪之後才發現,我之前根本沒搞懂 context 怎麼管理、任務怎麼拆、指令在哪個層次該給。
我以為我在用 AI,結果我只是在讓 AI 用比較快的速度幫我犯錯。當 context 被壓縮後,部份指令丟失會造成 AI 開始變得智障,寫出一些明顯有問題且違反規則的程式碼。
結果一個 bug 反覆的修,怎樣也修不好,火大自己跳進去看 code 找 bug,直接修掉。
但這個是 AI 的問題嗎?
是,也不是。
是我造成 AI 以這樣的方式在寫 code。
正常一個活的工程師被我這樣搞他,給他超長的上下文規則 + 需求,叫他 24 小時不睡全部搞定——不拿鍵盤丟我肯定不是正常人。
當我搞懂架構之後,很少會有違反指令的時候,就算有,也會被另一個負責檢核的 Sub-Agent 找到然後修正,生產力確實跳了一個台階。
但那個台階不是 AI 給我的,是我自己補上了原本缺的那塊理解。
「能不能上線」和「能不能持續上線」是兩個完全不同的問題
所以當有人跟我說「我學了 vibe coding,是不是可以直接上 production」的時候,我都會問一句:
你打算讓它活多久?
- 前者考驗的是速度。AI 在這件事上已經贏了,沒有懸念
- 後者考驗的是你對系統的理解、對變化的預判、對技術債的嗅覺
這些東西,AI 目前幫不了你,你得自己累積。
一個全新的 side project,vibe coding 上去跑,完全沒問題,應該的。
但你公司那套養活幾十個人甚至上百人的系統?就算是你老闆不懂,你也應該慎重一點不要害他 😅
AI 時代對工程師的要求不是降低了,是換了一個形狀
絕大多數的工程師花 80% 時間寫 code 與除錯、20% 時間理解需求與設計架構。
現在 AI 把寫 code 與除錯的時間壓縮掉了,剩下那 20% 突然變成 80%。
而那該死的 20% 才是真正區分資深跟資淺的實力。
以前你也許可以靠「寫得快」混得還不錯。可是現在大家都很快啊,比的是誰想得更清楚。
一個問題留給你
如果你也在用 AI 工具開發,不管是 Claude Code、Cursor、Codex 還是什麼都好——問自己一個問題:
你是在「用 AI 加速」,還是在「用 AI 加速犯錯」?