Claude 不是編譯器：Vibe-Engineering 的興起
Claude 不是編譯器：Vibe-Engineering 的興起
LLM 是垂直整合資源，而非編譯器
像 Claude 這樣的語言模型 (LLMs) 並不是編譯器，因為它們不只是將高階規格轉換為低階實作。相反地，它們是垂直整合的資源，可以在整個軟體堆疊中運作——從高階業務策略和產品規劃到架構與機器碼。
雖然傳統編譯器消除了工程師在暫存器分配或內聯 (inlining) 等低階決策方面的需求，但 LLM 則允許工程師在堆疊的每一層同時快速迭代決策。
這種轉變將工程師的角色從編寫程式碼轉向「vibe-engineering」：透過引導代理 (agent) 進行一系列架構與策略決策，以達成生產就緒的系統之過程。
個案研究：建立分散式 DNS 伺服器
為了展示垂直整合的力量，Bryan Mikaelian 描述了為 exe.dev 開發一個地理分散且具備一致性的 DNS 伺服器。該專案旨在降低俄勒岡州以外使用者的延遲，並提高可用性韌性。
開發流程
與其手動編寫程式碼，該流程涉及與 LLM 的高頻率回饋迴圈：
- 研究與規劃：使用 LLM 研究標準的分散式 DNS 設計、探索安全性缺陷，並評估替代的實作策略（例如 AXFR/IXFR）。
- 迭代原型設計：促使多個並行的代理迴圈來建構整個系統，包括測試與對抗性程式碼審查。
- 差異規格分析 (Differential Spec Analysis)：透過比較不同代理的實作方式（例如 Claude vs. Codex），工程師識別出代理在隱含狀態下所做的關鍵決策。這種「差異規格分析」揭示了系統行為何處需要明確的編碼化。
- 將決策編碼化：工程師將學到的見解轉化為「疤痕組織文件 (scar-tissue document)」——一份簡潔的書面指南，將從高階目標到並行快取 (concurrent caches) 的特定資料型別等所有層級的重要決策編碼化。
技術實作細節：處理資料庫回滾 (Rollbacks)
在差異分析期間出現了一個關鍵決策：如何處理會破壞複製 (replication) 「僅限附加 (append-only)」契約的資料庫回滾。最終設計為每一列 (row) 實作了一個「時間軸 (timeline)」欄位。每個同步請求都包含邊緣伺服器的時間軸值；如果偵測到不匹配，系統會觸發完整的清理重新同步。
Vibe-Engineering 與 Vibe-Coding 的區別
「vibe-coding」與「vibe-engineering」之間存在根本性的區別：
- Vibe-Coding：將任務交給代理，並讓它做出所有決策，以將想法轉化為實作。這通常是不可靠且缺乏監督的。
- Vibe-Engineering：使用 LLM 來加速在堆疊不同層級做出決策的能力。工程師仍是主要的決策者，利用代理來探索設計空間並找出哪些決策才是真正重要的。
在此模型中，工程師可能「閱讀極少量的實際程式碼」，但他們對系統保持著深層的理解，因為他們引導了架構決策，並能對系統行為進行推理。
社群觀點與反對意見
Hacker News 上的工程師討論突顯了對這種方法的一些關鍵疑慮：
隱含決策的風險
一些批評者認為，將決策外包給 LLM 可能很危險。正如 @trjordan 所指出的，代理的「決策廢棄物 (decision exhaust)」——即代理在未被要求的情況下所做的決策——可能導致隱性失敗。其他人，如 @cadamsdotcom，則認為一旦需求被理解，就應該將其編碼化為確定性的程式碼，而非留給機率性系統。
決定論的差距 (The Determinism Gap)
與具備決定論的編譯器不同，LLMs 是機率性的。@davidpapermill 和 @armchairhacker 指出，因為 LLM 可以針對相同的提示詞 (prompt) 產生不同的結果，因此它們不能被信任為編譯器。確保正確性的唯一方法是透過嚴格的測試套件或詳盡的人類審查，這可能抵消 AI 輔助開發的速度增益。
「不要閱讀程式碼」的爭議
生成程式碼的閱讀量極少這一觀點引發了顯著的反對意見。@xav_authentique 和 @borzi 表達了擔憂，認為在不閱讀程式碼的情況下將程式碼部署到生產環境是危險的實踐，忽略了軟體工程的真實問題，這呼應了過去如盲目採用微服務的趨勢。
DNS 架構的批判
從技術角度來看，一些使用者對重新發明 DNS 伺服器是否有必要提出疑問。@nunez 建議，現有的工具如 dnsmasq 或 unbound 可能已經解決了問題，並對 @torginus 警告，ISP 與企業 VPN 的中間層 DNS 快取通常會使伺服器端的傳播速度成為一個無論如何實作都無法解決的問題。