為什麼智能體編碼使規範問題更糟
本文探討了智能體編碼在軟件開發中的侷限性，指出雖然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之前的文章。