在 AI 編碼代理（Coding Agents）爆發的時代，寫程式的門檻正迅速降低。當產品經理、設計師甚至銷售人員都能透過 AI 快速產出功能碼時，軟體工程師的核心價值將從「能寫出程式碼」轉向「如何定義與管理系統」。
對於許多習慣於在 Ticket 驅動下完成任務的工程師來說，這可能會帶來焦慮。但如果將視角轉向新創公司（Startup）的生存邏輯，我們會發現，AI 時代需要的不再是單純的開發能力，而是一種解決問題的系統性思維。
以下整理自 Ben Greene 在 QCon 的分享，將其轉化為工程實務中最重要的六個心法。
從簡單開始，對抗 Jevons Paradox
在自動化工具普及後，程式碼的生產成本降低，但這反而導致對軟體的需求量激增。這在經濟學上稱為 Jevons Paradox（傑文斯悖論）：當資源利用率提高使成本降低時，人們反而會增加該資源的總消耗量。
對工程師而言，AI 讓我們能以極快速度增加功能，但這很容易導致系統過早複雜化。實務上應遵循 Gall's Law（加爾定律）：一個能運作的複雜系統，必然是從一個能運作的簡單系統演進而來的。
如果你設計的系統在簡單階段就無法達成目標，增加複雜度絕不會解決問題。在 AI 時代，工程師的責任是克制「增加 Token」的衝動，確保系統在擴張前，核心邏輯已驗證可行。
comprehension 理解力才是真正的競爭力
AI 代理能以極速生成大量程式碼，但它最危險的地方在於：它能幫你寫出你完全不理解的系統。
在實務中，最可怕的狀況是程式碼庫中存在一個「看不懂的炸彈」。當需求變更時，工程師因為不理解舊邏輯而不敢修改，只能選擇在周圍繞路（Workaround），導致技術債呈指數級增長。
理解力（Comprehension）是變更的基石。工程師必須意識到，如果一段程式碼讓審閱者感到認知負荷過重，那麼這段程式碼就應該被重寫，無論它是 AI 寫的還是人類寫的。
主動挑戰困難，而非追求快速交付
AI 代理傾向於提供「最容易實現」的方案，而非「最正確」的方案。例如在開發複雜功能時，AI 可能會建議你用 Web 模擬而非原生開發，僅僅是因為後者更簡單。
在工程實務中，應採取 POC（Proof of Concept，概念驗證）先於 MVP（Minimum Viable Product，最小可行性產品）的策略。優先攻克最困難、不確定性最高的功能點（Hard Bits），一旦這些風險被消除，後續的開發才會變得可預測。
如果工程師淪為 AI 建議的執行者，只做簡單的整合，將失去處理複雜問題的能力，而這正是 AI 目前無法取代的高價值工作。
從程式碼轉向對影響力的關注
優秀的工程師不應將工作定義在「寫完程式碼」的那一刻。在 AI 時代，定義問題的能力比解決問題的能力更重要。
這意味著工程師需要具備系統思考（Systems Thinking）與同理心（Empathy）。你需要走出開發環境，理解客戶在什麼情境下使用產品、他們的痛點是什麼。
AI 可以生成邏輯，但 AI 無法「在意」客戶的痛苦。能將技術能力轉化為對商業問題的解決方案，才是工程師在自動化浪潮中不可替代的護城河。
打破傳統工程師的舒適圈
長期以來，工程師習慣建立緩衝區，將自己與用戶、業務隔絕，專注於技術實作。但現在，這種「純開發者」的標籤正變得危險。
未來關鍵的技能組合將包含：創造力、品味、學習敏捷度、高度主動性（High Agency）以及同理心。工程師需要從「程式碼生產者」轉型為「問題解決者」，將軟體視為達成目標的手段，而非目的本身。
警惕 comprehension 的崩潰
當公司要求工程師大量使用 AI 代理來提高產出時，最直接的後果是：三個月後，沒人記得這段程式碼為什麼這樣寫。
這本質上是在加速累積技術債。如果組織只追求交付速度而忽略對系統的理解，最終將導致系統崩潰或無法創新。工程師應在團隊中建立一種文化：承認「我不理解這段程式碼」並非恥辱，而是一種對系統健康的負責。
總結
AI 並沒有奪走工程師的工作，而是奪走了「枯燥的重複勞動」（如寫重複的 REST API）。這讓我們有機會將精力集中在真正有趣的算法、系統架構以及真實世界的問題解決上。
只要保持對系統的掌控力，並將視角從螢幕移向用戶，AI 將成為最強大的槓桿，而非威脅。
來源：infoq.com - The Future of Engineering: Mindsets That Matter When Code Isn’t Enough
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。