回歸手寫程式碼：分析軟體工程中的 AI 採用與退縮

AI 速度與系統理解之間的張力

雖然大型語言模型 (LLM) 編碼助手已變得無處不在，但軟體工程社群的一部分正積極限制或回歸不使用 AI，以優先考慮心理模型 (mental models) 與程式碼品質。這種轉變的主要驅動因素是意識到：程式碼生成的速度並不總是與解決問題的速度或最終產品的穩定性成正比。

AI 生成程式碼的認知成本

對於許多開發者而言，推導解決方案並建立心理模型的過程是軟體工程中最關鍵的部分。依賴 AI 生成實作可能會使開發者與邏輯脫節，導致幾個系統性問題：

• 失去心流狀態 (Flow State)： 自動化建議可能會中斷將腦中的願景流向程式碼的認知過程。
• 掩蓋架構問題： 當 AI 透過快速生成讓困難任務顯得容易時，開發者可能會忽略底層的系統缺陷，而如果這些程式碼是手寫的，這些缺陷本應是顯而易見的。
• 技能侵蝕： 手寫程式碼正日益被視為維持語法熟練度與技術面試準備度的必要實踐。

"having derived the code and built a mental model is something like 90% of the work, the code artefact being 10%... once I have this model / vision in my mind, I’m streaming it from my mind into reality via code and having code suggestions pop up breaks that flow state for me."

AI 驅動的技術債與功能膨脹

在初創企業環境中，使用 AI 生成程式碼的便利性可能導致「功能膨脹」以及缺乏架構紀律。在開發週期早期進行快速迭代的能力，可能會建立一個過於複雜而難以管理，或過於不穩定而無法用於生產環境的程式碼庫。

一些組織正在考慮在不使用 AI 的情況下重寫核心功能，以確保系統保持簡單、易於理解，且變動速度較慢。這種方法將 AI 視為快速原型設計的工具，但將其視為核心架構穩定性的負擔。

AI 使用上的策略與經濟限制

某些產業與公司規模決定了更保守的 AI 採用方式：

• 深科技 (Deep Tech) 與高風險環境： 在專業領域，完全理解每一行程式碼是安全性與可靠性的前提。在某些情況下，客戶可能會將 AI 生成的程式碼視為交易破裂的關鍵因素。
• 企業退縮： 有報告指出，大型實體如 Ford、IBM 與 Commonwealth Bank of Australia 已縮減了與 AI 相關的招聘或計畫，儘管其動機範圍從經濟重組到品質控制不等。
• "Vibe Coding" 的崩潰： 有傳聞指出某些部門（例如 AWS 的 AI 部門）採用了 "vibe coding" 的方法——優先考慮快速、AI 驅動的迭代，而非嚴謹的工程實踐——結果在軟體缺乏穩定性時面臨解散或失敗。

反對論點：AI 作為一種演進工具

相反地，許多工程師認為禁止 AI 等同於禁止 IDE、編譯器或 Stack Overflow。他們主張 AI 僅僅是將複雜度從開發者身上轉移的下一步，類似於垃圾回收 (garbage collection) 取代了手動記憶體管理。

從這個角度來看，生產力增益是不可否認的，且目前的摩擦是源於缺乏成熟的模式與設計原則。支持者認為 AI 最好的使用案例並非在核心邏輯，而是在周邊領域：安全性檢查、效能審計與測試生成。

AI 使用模式摘要

Approach	Primary Motivation	Typical Use Case
Full Adoption	Maximum velocity and token-maxing KPIs	Rapid prototyping, commoditized UI, boilerplate
Selective Use	Balancing speed with deep understanding	Review, test generation, periphery checks
Manual Core	Architectural stability and client trust	Core technology, deep-tech systems, complex spatial reasoning
Complete Avoidance	Risk mitigation and skill preservation	High-security systems, interview preparation