為什麼智慧體編碼使規範問題更糟
本文探討了智慧體編碼在軟體開發中的侷限性，指出雖然AI加速了程式碼編寫，但未能解決軟體開發的本質複雜性——即決定構建什麼。作者認為，最大的槓桿在於改善人類之間的溝通摩擦，而非採用專門的工具或智慧體編排。文章提出了一種以決策為中心的方法，透過追蹤實現決策的全生命週期來促進產品與工程之間的資訊雙向流動。
在軟體開發領域，智慧體編碼（agentic coding）的興起引發了兩種對立觀點：一方強調需要保留對關鍵業務邏輯的可見性，拒絕全面採用智慧體開發；另一方則呼籲完全自動化的開發流程，淡化其操作風險。然而，Bicameral公司認為，對於希望在生產環境中使用智慧體開發的團隊而言，最優解並非採用專門的框架或智慧體編排，而是解決人類之間的交接摩擦。
文章引用了Fred Brooks在1986年提出的“沒有銀彈”觀點，指出軟體開發的核心困難在於本質複雜性——即決定構建什麼。過去的進步（如物件導向程式設計、分時系統）主要減少了偶然複雜性（程式碼編寫），但本質複雜性依然存在。在AI時代，規範問題得到了更多關注，但現有解決方案（如ChatPRD、gstack）的前提是，透過AI揭示規範差距就足夠了。然而，Gabriella Gonzalez在“A sufficiently detailed spec is code”中指出，軟體規範常被誤解為比程式碼更簡單或更具創意。自然語言的模糊性無法承載工作系統所需的精確性；一份缺乏清晰度和細節的文件無法讓編碼智慧體可靠地填補空白。
智慧體編碼在特定場景（如落地頁、CRUD應用、電商網站）有效，是因為這些場景有大量相似專案存在於訓練資料中，而非規範本身變得更容易。但對於大多數需要根據特定業務需求建立定製軟體的情況，AI加速了程式碼編寫，卻未能解決開發人員一直在進行的思考工作。正如一位開發者所言：“當構建新軟體以改進業務時，任務從未真正明確定義。AI可以寫程式碼，但它不會拒絕寫程式碼，除非先被告知為什麼先做X不是更好的主意。”
目前，只有15%的AI決策者報告其AI專案對收益產生了積極影響。受益於“vibe coding”熱潮的仍然是那些程式碼編寫的偶然複雜性是主要技術障礙的少數行業。
儘管如此，文章相信LLM有機會解決本質複雜性。關鍵是不要透過替代開發人員，而是強化他們作為軟體完整性守護者的角色。當前AI整合方式（如數千行程式碼需要人類審查、AI上下文層不透明、vibe coding最佳化功能可見性而犧牲非功能完整性）與開發人員減少歧義的角色背道而馳。
因此，Bicameral採取逆向策略：既然LLM是跨域語義轉換器，應將其用於解決跨職能溝通鴻溝。他們設想每個角色都能改進自己關心的方面，產品負責功能（特性、工作流），工程負責非功能（安全、可維護性、效能）。工具應促進資訊雙向流動：產品上下文幫助開發者做出好的非功能決策，架構影響幫助產品經理做出好的特性優先順序決策。
Bicameral的產品路線圖從追蹤最小單位規範——實施決策——的全生命週期開始。決策被視為一等實體，連結到源文本並紮根於程式碼；提供雙面賬本，團隊決策注入上下文指導智慧體開發，智慧體做出的隱含架構決策被追蹤供日後審查；強調升級而非推薦，標記需要跨職能談判的重要決策。第一個版本已作為開源MCP伺服器釋出，當前支援Claude，其他編碼智慧體支援即將推出。
參考文獻包括Fred Brooks、Gabriella Gonzalez、Edsger Dijkstra、Forrester預測以及Bicameral之前的文章。