這幾年 AI agent 把寫 code 這件事從工程師的核心動作，變成可以指派出去的步驟。寫 code 不會消失，但它從工程師最大的時間花費，退到日常輸入的一部分。當這件事發生，工程師的價值點會跟著移位。我想從技術、角色、context engineering、能力四個面向，講這個位移是怎麼發生的。
過去幾十年我們評斷一段 code 寫得好不好看三件事：效率、正確性、可讀性。這三件事的隱含主詞都是人，跑這段 code 的機器要快、邏輯要對、未來接手的同事要看得懂，團隊協作的成本決定了這些判準。但現在最先接手這段 code 的對象經常是 AI。它要讀懂你寫了什麼、知道你想做什麼、然後往下延伸或重寫。code 的好壞因此多了一條判準：你給 AI 的東西能不能讓它正確接手。
這條判準的重點落在 code 之外的那份文件。spec-driven 開發在這裡變得關鍵。一份寫得清楚、把意圖、邊界、預期行為講明白的規格，能讓 AI 產出對的程式碼。一份模糊的、靠團隊默契填空的規格，AI 接到只會猜，然後猜錯。過去工程師「會寫」這份文件是加分項，現在是必要條件。
連帶地，工程師個人的能力核心也在移動。過去比的是「你 coding 寫得多快、多好」，未來比的是「你能不能設計一套 agent harness 來指揮 AI 做事」。這裡講的是 builder 級的設計能力。Builder 級要面對的是：怎麼切任務讓 AI 不會搞混、怎麼設停損避免它跑偏、怎麼讓多個 AI agent 平行做事還能合得起來、怎麼把錯誤回饋餵回去讓下一輪做得更好。這套設計能力過去不存在，現在是工程師能不能拉開差距的關鍵。
角色端的變化則要看你原本走哪條路。技術型工程師那條路最大的特色是系統架構能力，這件事沒變。怎麼把一個複雜系統拆成可以維護、可以擴張、可以容錯的模塊，怎麼選資料庫、怎麼設計 API 邊界、怎麼讓服務之間溝通乾淨，這些事 AI 還做不到。它可以幫你實作其中某個組件，但不會替你決定整個系統長怎樣。技術型工程師的價值在這層判斷上，這條路在 AI 時代沒有變窄。
PM 型工程師那條路變化比較大。過去這個角色的位置是需求的聆聽者，聽客戶或產品 PM 講想要什麼，翻成技術可行的方案，再找方法去執行。重點在聽、翻譯、執行。未來這個角色要變成需求的討論者。客戶說的「需求」往往只是他自己對解法的猜測，工程師要從中還原他真正的「意圖」，也就是他想解的問題是什麼、為什麼這對他重要、不解會怎樣。理解了意圖之後，重點是找 solution（解決方案），也就是真正解掉客戶問題的路徑；method（執行方法）只是達成 solution 過程中的選項之一。這個位置實質上就是 Forward Deployed Engineer（FDE），帶著 AI 工具到客戶現場，邊問邊做邊調整，幫客戶把意圖落地。
除了 spec-driven 跟 agent harness，還有一層新的工程設計面向冒出來，叫 context engineering 架構。過去做軟體系統，我們設計的是資料怎麼流、服務怎麼切、狀態怎麼存。AI 進來之後，系統裡多了一個會「思考」但需要被餵 context 才能做對事的角色。問題是 context 從哪裡來？怎麼確保使用者在過程中產生的脈絡，他剛剛做了什麼、為什麼這樣做、他現在卡在哪，被正確保留下來，等到 AI 要做事的時候能讀懂？
這層架構過去不存在。它要決定的是：系統在哪些點記錄使用者的動機、在哪些點記錄他的決策、這些訊號怎麼儲存、AI 需要時怎麼撈出來。設計得好，AI 能聰明地接續使用者的脈絡，知道他真正想完成的事，給出對的回應。設計不好，AI 每次都從零開始猜，輸出讀得通但對不上使用者真正要的東西。
這件事跟 prompt engineering 不是同一層。Prompt engineering 是當下這次互動怎麼跟模型講話，context engineering 是整個系統怎麼把使用者的歷程留下來讓 AI 在任何時刻都能讀懂。
最後是能力面。這層其實在前面三件事裡已經出現過，但值得單獨拉出來講。
第一個是理解跟溝通能力被同時放大兩次。你要對人聽懂他真正想做什麼，這部分過去就重要，未來更重要，因為 AI 把翻譯成 code 的部分接走了，前面這段「聽懂並還原意圖」變成更核心的動作。你還要對機器，用 spec、prompt、context 把這個意圖翻成 AI 能正確執行的指令。兩端都得要強，才能讓需求真正被落地。
第二個是 AI 邊界的識別能力。AI 在它熟悉的範圍裡可以快速試很多方案，可以把可讀性、效能、邊界情況都顧到。但它無法替你判斷哪些事它做得到、哪些事它在編造你看不出來的東西。能準確說「這個交給 AI 做、這個千萬不能讓 AI 做」的工程師，產出品質會跟「丟給 AI 看結果如何」的工程師差非常多。
這兩件事過去都算 senior 工程師的隱性差異，現在是所有層級都要面對的明確分水嶺。
把這四件事擺在一起，方向就清楚了。技術評斷在變，角色職責在變，多了一層 context engineering 的設計面向，能力的比重也在重新分配。四件事都圍繞同一條軸線：能不能定義對的問題、能不能給 AI 對的 context、能不能判斷 AI 的邊界。寫 code 這件事還在，工程師也還在。只是工程師價值的中心，從產出 code 移到了這條軸線上。
沒有留言:
張貼留言