为什么智能体编码使规范问题更糟
本文探讨了智能体编码在软件开发中的局限性，指出虽然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之前的文章。