为什么软件工厂会失败（或者说：仅有搭建工程还不够）
旨在以尽可能少的人类参与来生成并交付代码的 AI 驱动“软件工厂”，正面临代码质量、可维护性和长期设计方面的硬性限制。评论者认为，尽管现代模型可以产出令人印象深刻的功能和重构，但如果没有严格的人类主导规划、验证和品味，架构上的“劣质内容”就会在大型、不断演进的代码库中不断累积。许多人认为，更有前景的路径是高纪律团队在强规格、测试和审查流程中把代理当作放大器，而不是完全“关灯”式自动化。
“软件工厂”的现状与 StrongDM 背景
- 有些评论者指出，StrongDM 的 AI 工作后来分拆成了一家咨询公司；这既可被解读为成功（说明这些想法有价值），也可被视为产品需要大量服务支持的迹象。
- 一位 StrongDM 实验室成员澄清，他们的“天气预报”一直在定期更新，并声称大多数软件问题都能被他们的工厂技术攻克，尤其是在更新的模型上。
- 也有人认为我们仍处在早期、实验阶段；还没有稳定的“标准方法论”。
严谨性、可维护性与规格说明
- 大致共识是：从 AI 中获得最大收益的团队，本来就具备很高的纪律性、干净的代码、测试和良好的工程卫生。
- 许多人认为可维护性是核心未解问题：模型可以实现功能，但会随着时间推移缓慢恶化架构和耦合。
- 有人探索 RFC 风格的规范性规格和类型化约束来限制代理，但也指出非常细致的规格开始会像代码，而且并不明显节省工作量。
- 还有人提出用 RL 设置来奖励代码库的长期健康，但也指出并不存在能快速、客观判断“好设计”的 oracle。
代码审查、PR 与流程
- 关于代码审查，分歧很大：
- 一派认为人工审查对于知识共享、品味、设计把关和合规都至关重要；用 LLM 去假装审查被视为失职。
- 另一派则自动化审查，并声称组织主要在意的是防止 bug 和提速；他们认为应该审查正在运行的软件，而不是 diff。
- 许多人抱怨 PR 的 UX、代理生成的超大 diff，以及“LLMese”式评论。
- 有人主张通过大量自动化检查、测试、lint 工具和便捷回滚来尽量减少 PR 门槛；但也有人认为这些仍会漏掉架构和向后兼容性问题。
模型能力、RL 与长上下文
- 对前沿模型（Opus、Fable、GPT-5.6 等）到底改变了多少局面，意见不一。有些人表示已经把整个功能交给代理；另一些人则说“关灯”式尝试仍然产出劣质内容或自我强化的坏设计。
- 一些人注意到，只要明确要求，模型重构得很好，但并不会自主意识到何时需要重构。
- 长上下文表现喜忧参半：有些人几乎看不到退化；另一些人则举例说明模型在大上下文中会忘记简单工作流。
- 许多人强调，如今的 RL 主要优化的是任务成功，而不是设计质量，因此奖励黑客和脆弱测试都很常见。
工程师的角色与“品味”
- 多条评论把软件工程师的主要工作定义为系统所有权、长期设计与品味，而不仅仅是敲代码。
- 好架构被描述为微妙、难以衡量，并且要通过痛苦经验才能学会；评论者怀疑当前模型能否可靠地做出这些设计判断。
- 一个反复出现的主题是：代码库中的模式会充当“隐式提示”，因此人类必须警惕地守护抽象和模式，否则劣质内容就会不断累积。
工厂今天可能有效的场景
- 许多人认为“黑暗工厂”在以下场景更可行：
- 小型、低风险或业余应用。
- 短期实验和脚本。
- 对于复杂、能带来收入或受监管的系统，大多数人主张使用有人在环的工厂，并进行更多前期规划（产品、系统、程序设计）以及更严格的约束，而不是完全自治。