這陣子和工程師朋友聊天，聊一聊，大家總會不約而同地問同一個問題：「現在 IDE 已經聰明成這樣了，我們會不會真的要失業啊？」
老實說，我自己不一定知道，我自己對未來的發展是不太樂觀。我覺得早晚會有一天不需要自己寫代碼。到那時候，工程師要幹嘛？我也不知道。
console.log 的打字機了。它現在更像是...嗯，怎麼形容呢？有點像是一個很會執行任務的全能助手——你告訴它要做什麼，它就真的會幫你做完（雖然偶爾還是會給你挖坑啦）。從「手刻每一行」到「指揮 AI 幫你做事」
還記得嗎？幾年前我們每天有超過一半的時間都在處理那些瑣碎的細節：查語法、解 TypeScript Error、寫那些無聊到爆的單元測試 Boilerplate...
現在嘛，這些事情基本上都被 Cursor 接手了。我一開始其實有點不習慣（畢竟手刻了這麼多年），但用久了就回不去了。
1. 你的 IDE 現在有「全局觀」 (Context Awareness)
2026 年這波 AI IDE 最讓我驚訝的，是它們理解 Context 的能力真的有夠強。
拿 Cursor 來說，它現在不只是看「你打開的那幾個檔案」，而是會去索引你整個專案。對，包含那些你三個月前寫的註解、你的 Git History、甚至是你藏在 docs 資料夾裡的那份設計文件。第一次看到它挖出我自己都忘記的舊 code 時，我整個嚇到。
- 以前的 Copilot：你打
const Button = ...，它幫你補完一個按鈕。就這樣。 - 現在的 AI Agent：你可以直接跟它說：「欸，我要在 Settings 頁面加一個深色模式開關，麻煩參考一下我們現有的 ThemeProvider，順便幫我把相關的 Context 重構一下。」
然後它就真的會：
- 找到
ThemeProvider.tsx - 修改 Context 定義
- 在
SettingsPage.tsx加上開關 UI - 甚至連 migration script 都幫你寫好了
這帶來的改變不只是「不用切換視窗」而已，更深層的是認知負載 (Cognitive Load) 的釋放。
以前寫 Code，腦袋裡要同時裝著業務邏輯（Business Logic）和實作細節（Implementation Details）。現在，你可以把那一半「怎麼實作」的記憶體清空，專注在「邏輯對不對」。
這其實滿危險的，因為你很容易會忘記底層是怎麼運作的。所以我現在會強迫自己去讀它生成的 code，而不是直接按 Accept。但不可否認，那種「只要想著架構，細節自動填滿」的心流感（Flow），真的會讓人上癮。
2. GitHub Copilot Workspace：從 Issue 到 PR 的一條龍
GitHub 的 Copilot Workspace 更誇張，它現在直接把自己定位成「AI 軟體工程師」了。
我前陣子試用了一下，工作流大概是這樣：
- 你在 GitHub 開個 Issue：「修復登入頁面在 iPhone 上的跑版問題」
- Copilot Workspace 會自己去讀你的 code、重現環境、然後跟你說：「我覺得問題在這裡，我打算這樣修」
- 它會自動改好幾個檔案，還會在雲端跑測試（這點我覺得滿貼心的）
- 改完之後發 PR 給你，你就當個 Reviewer 就好
說實話，第一次看到它自己發 PR 過來的時候，我有種「所以我是不是可以去喝咖啡了」的感覺。當然啦，它給的解法也不是每次都完美，有時候還是需要你去微調，但已經幫你省掉 70-80% 的苦工了。
「AI 協助開發者」的新職能要求
那問題來了：我們會失業嗎？
呃...我覺得答案是「不會，但工作內容會變很多」。
我最近有在看一些大廠的職缺（Netflix、Airbnb 那些），發現他們開始出現一個新關鍵字：AI-Augmented Engineer（AI 增強型工程師）。
簡單來說，現在市場對「能手刻紅黑樹」的需求確實降低了，但對以下這些能力的要求反而變高了：
1. 系統設計的品味
AI 最大的問題是：它給你的通常是「統計學上的平均值」，也就是最平庸的標準答案。
當你叫它「設計一個 User 設定檔」，它會給你一個標準的 CRUD。這沒錯，但不一定適合你的場景。也許你的系統讀取量是寫入的一千倍，比起標準的 3NF 資料庫設計，你更需要的是 Read-Heavy 的 NoSQL 架構，或是激進的 Caching 策略。
如果你自己沒有這種「品味」和對 Trade-off 的判斷力，你的產品就會變成一堆「跑得動但沒特色（而且可能很慢）」的平庸代碼堆砌。千萬別讓 AI 的「方便」扼殺了你對效能和架構的堅持。
2. 對抗「看起來很對」的幻覺
AI 寫的 Code 通常有一個特點：變數命名完美、縮排整齊、註解詳細，看起來就是個 Senior 寫的。
這就是最危險的地方。當你看到一段很漂亮的 code，你的大腦會本能地降低戒心，然後順手按個 Approve。
這幾個月我強迫自己養成新習慣：把 AI 當成一個剛來報到、很有自信但偶爾會腦補的實習生。 你必須預設它「可能漏了什麼」，去檢查那些 Edge Case、Error Handling，還有資安漏洞。千萬別被那一層漂亮的「皮」給騙了。
3. 與 AI 的對話能力
很多人覺得 Prompt Engineering 就是要背一堆咒語。錯了。
真正的 Prompt Engineering 是溝通的能力。你不需要一次就給出完美的指令（因為你通常也還沒想清楚）。
重點在於迭代：
- 先給個大概的想法：「幫我設計一個登入元件」。
- 看它給什麼廢物，然後修正：「不要用原本的 fetch，改用我們專案裡的 api client」。
- 再修正：「密碼規則太鬆了，加強一下」。
這不是在「下指令」，而是在Code Review AI 的產出並引導它修正。這種來回對話、收斂收斂再收斂的過程，才是與 AI 協作的精髓。
工作內容變了，但你還是主導者
說實話，現在寫 Code 的感覺跟以前真的很不一樣。
以前我們每一行都要自己想、自己刻，雖然有成就感，但也真的很耗時間。現在有 AI 幫忙處理那些重複性的工作，你可以把精力放在更重要的事情上。
我的建議是：不要抗拒讓 AI 接手那些繁瑣的工作。把腦力留給真正需要你的部分——比如說，怎麼設計一個讓使用者感到貼心的 UX，或是想出下一個真正有價值的 Feature。那些才是 AI 做不來、需要人類智慧和溫度的東西。
至於寫 boilerplate、查語法、補測試這種事？就交給 AI 吧。
（當然啦，你還是要檢查它有沒有偷懶就是了XD）
