AI 工程師的崛起：從翻譯轉向架構

傳統軟體工程師的形象是蜷縮在鍵盤前，細心雕琢每一行程式碼，花費數小時進行除錯，並優化每一個迴圈。數十年來，這種「翻譯」過程——將概念性解決方案轉化為語法正確的實作——一直是開發者的主要活動。

然而，一個挑釁性的新觀點正在出現：認為實際輸入程式碼從來不是這份工作「有趣」或最有價值的部分。相反地，軟體工程的真正本質在於決策過程——架構、抽象化以及解決問題。隨著 AI agent 變得越來越有能力處理實作細節，工程師的角色正從程式碼的生產者轉變為系統的評估者。

翻譯的代價

對於許多經驗豐富的開發者來說，寫程式碼感覺就像是為了讓想法成真而支付的代價。重複性的樣板程式碼、null checks 和標準模式往往感覺像是肌肉記憶，而非智力刺激。當概念性的工作——決定系統在出錯時應該如何運作，或複雜度應該存在於何處——在幾秒鐘內完成時，隨後的數小時輸入程式碼僅僅是一種翻譯練習。

透過利用 AI agent 來處理這種翻譯，工程師可以進入「全 AI 工程師」模式。在這種工作流程中，主要活動轉向：

• 架構設計 (Architecting)： 定義系統的高層級結構和原語 (primitives)。
• 審查 (Reviewing)： 仔細閱讀 diffs 並拒絕那些解決了錯誤問題的實作。
• 回擊 (Pushing Back)： 反對不符合專案長期目標的模式。
• 指定規格 (Specifying)： 為 agent 編寫詳細的規格說明書。

在這種範式下，關鍵技能不再是語法熟練度，而是品味 (taste)。品味是指能夠識別不良設計、發現即將崩潰的負載支撐假設，並知道該堅持什麼以及該放手什麼的能力。

「氛圍編碼 (Vibe-Coding)」的危險

這種架構方法與某些人所稱的「氛圍編碼 (vibe-coding)」之間存在顯著差異：後者是指在沒有嚴格審查或理解的情況下，讓 agent 生成程式碼的行為。氛圍編碼是危險的，因為它會導致生產環境變得不可預測，且在凌晨 3 點時無法進行除錯。

真正的 AI 工程需要更高層級的審查。評估程式碼可能比產出程式碼更困難；審查者必須在更多事情上保持正確，且速度更快，通常還是在上下文資訊較少的情況下。工程師必須對 agent 進行「短繩控制 (short leash)」，確保每一行程式碼都經過審查，且每一次測試都是有意義的，而非「虛假」的覆蓋率。

反對意見：萎縮與狹隘

雖然向 AI 驅動的編排 (orchestration) 轉型對於某些人來說是解放，但這也在工程社群中引發了激烈的辯論。幾個關鍵的疑慮被提出了：

1. 認知萎縮

許多人認為，閱讀程式碼是寫程式碼的拙劣替代品。人們擔心，如果停止了「實作」，工程師將失去深入理解語言細微差別的能力。正如一位評論家所說，如果你停止從實際程式編解碼能力的角度來思考程式碼，你就是在為失敗做準備。

2. 解決方案空間的狹隘化

有一種理論認為，在問題開始時與 LLM 互動會縮小解決方案的空間。工程師不再是制定獨特的、量身定制的解決方案，而是可能開始僅僅標記看起來錯誤的東西，並從 LLM 生成的替代方案選單中進行選擇。這可能導致「中庸思考 (mid-thinking)」，即工程師的大腦被訓練得像 LLM 一樣思考，潛在性地導致次優的架構。

n. 「最慢的 IDE」問題

從務實的角度來看，一些開發者認為，用自然語言描述微小的修改是極其低效的工作方式。使用 LLM 來重新命名一個專案中的變數，可能比直接打開檔案並手動進行要慢得多。在這些 cases 中，AI 變成了「一個具有更高延遲和更低精確度的冗長且有損的介面」。

結論：新的工程師身份

向 AI 驅動開發的轉型迫使人們面對職業身份的認同。多年來，「開發者」的身份與編寫程式碼緊密相連。如果這種身份取決於工具棧，工具棧就是脆弱的。

然而，如果身份轉向與解決問題和創造價值的能力掛鉤，工具就變得無關緊要了。辯論的核心最終在於：手動編寫程式碼的「代價」究竟是一種建立領導 AI 所需品味的必要紀律，還是可以最終被捨棄的負擔。對於擁有十年經驗的高級工程師來說，這場轉型可能是一種解放；對於新手來說，在從未寫過 for-loop 的情況下實現那種「品味」，路徑仍然是一個開放且或許令人擔憂的問題。