AI-First 指令：這是軟體工程的未來嗎？

越來越多的組織正競相爭取被貼上「AI-First」的標籤，通常會實施激進的指令，從根本上改變軟體工程的工作流程。在某些極端情況下，工程師被告知不要親手寫任何一行程式碼，而是依賴於由 AI agent 和專有框架構成的複雜網絡。雖然速度的承諾非常誘人，但現實情況往往顯示出管理層的願景與工程現實之間的鮮明對比。

AI-First 指令的興起

在最近一次軟體工程師之間的討論中，一位開發者分享了他在一家財富 500 強前十名公司的慘痛經歷。該團隊的開發方法不僅僅是用 AI 增強工作流程，而是完全取代了編碼的人類因素。這種「AI-First」策略包括：

• 強制使用 AI： 要求使用 Claude 等 LLM，並結合一個由超過 100 個 agent 和技能文件構成的專有框架。
• Agent 驅動的程式碼審查： 人類進行品質保證的角色正被自動化的 agent 審查所取代。
• 理解力的侵蝕： 這種方法的一個關鍵副作用是，工程師正在交付他們並不完全理解的程式碼，導致了一種文化，即沒有人花時間去深入理解系統架構。

這種轉變導致了某些人所描述的文檔和 Jira ticket 中出現「長篇大論的廢話 (novel-length slop)」——這是 AI 生成大量缺乏實質意義或精確度的文本的能力所產生的副產品。

工程師的反彈

經驗豐富的開發者正在發出警報，認為這種方法與軟體開發的核心原則背道而馳。從業者之間的共識是，雖然 AI 可以加速實作，但它無法取代可持續軟體所需的批判性思考、產品判斷力和建築師級別的架構設計監督。n

一位擁有 30 年經驗的資深開發者將目前的趨勢描述為「混亂、浪費，且與我所學到的一切關於軟體開發甚至基本溝通的知識背道而馳」。

其他工程師也注意到了一種模式：管理層喜歡這些 AI 驅動團隊的「感知效率」，但實際的工程組織對其產出物卻缺乏信任。在某些情況下，這會導致開發出一些沒有用戶的工具（例如 MCPs），且每天都受到 incident 發生所困擾，從而營造出一種生產力假象，掩蓋了系統性的不穩定性。

編排與實作

儘管存在挫折感，但人們也意識到工作流程正在發生變化。軟體工程師的角色正在從程式碼的撰寫者轉變為系統的編排者 (orchestrator)。

"I’m increasingly acting more like an orchestrator/reviewer than someone writing everything from scratch. AI dramatically speeds up implementation, but constraints/product judgment still seem very human-heavy."

這表明存在一個中間地帶：使用 AI 處理樣板程式碼 (boilerplate) 和實作細節，而人類則專注於高層次設計、約束條件和產品市場契合度。危險在於當「編排者」被迫交付他們不理解的程式碼時，危險性會隨之增加，從而移除ي了人類理解力的安全網。

結論：不確定的狀態

整個行業目前處於變動狀態。有些人認為目前的 AI 驅動的混亂是「悲傷」或妄想的一個暫時階段，而其他人則認為我們只是在發現新最佳實踐的過程中。

無論「AI-First」指令是否為一種可持續的模式，還是企業的幻想，有一件事是明確的：時鐘無法倒退五年。下一代軟體工程的挑戰將是在 AI 生成的速度與人類理解的嚴謹性之間找到平衡點。