文章指出，尽管AI编码工具和“软件工厂”模式被大力推广，但实际应用中导致代码库崩溃速度加快、系统频繁宕机。作者认为，仅靠工程循环优化不够，盲目追求速度可能沦为资本泡沫，呼吁行业放慢脚步。

好的，这是根据您的要求，对原文主要内容进行的中文重述，已保留关键细节并删减了与主题无关的内容。

软件工厂为何会失败：光靠“工程化”是不够的

核心观点： 当前AI编码工具（如Claude Code）虽然能大幅提升编码速度，但无法保证代码库的长期质量。过度依赖“循环工程”（即让AI反复生成和测试代码）而忽视人工审查，会导致代码质量下降、事故频发。问题的根源在于模型训练和评估方式的缺陷，而非使用者的技能问题。

1. 现状与问题：AI编码的“繁荣”与“隐忧”

• 主流叙事： 许多公司（如StrongDM、OpenAI）推崇“无人工厂”模式，即人类不读、不写代码，完全由AI代理完成。他们认为“代码是免费的”，人类是瓶颈，只需增加循环次数即可。
• 现实困境：
  • 事故频发： 许多公司因编码代理失误导致服务中断。
  • 代码库恶化： 代码库的崩溃速度前所未有。
  • 审查质量下降： 自AI编码工具普及以来，Pull Request的审查质量显著下降，表现为评论增多但流于形式，大量PR未经有效审查即被合并。
  • 缺陷率上升： 每位开发者的Bug数量和事故数量均大幅上升。
• “技能问题”的误区： 许多人将糟糕的结果归咎于用户“不会用”。但作者认为，无论用户如何优化提示词和工具链（即“工程化”），都无法解决根本问题。这并非技能问题。

2. 根本原因：模型训练与评估的缺陷

• 模型无法维护代码质量： 模型擅长解决一次性问题或“氛围编码”，但无法长期维护和改善代码库的质量。它们倾向于让代码随着时间的推移变得更糟、更难修改。
• 评估标准单一： 当前模型训练（如强化学习）和评估（如SWE-bench）的核心标准是“测试是否通过”，完全没有对“糟糕设计”的惩罚机制。
  • 模型只需让测试通过即可获得奖励，无论其代码是添加了冗余的try-catch、进行了危险的类型转换，还是破坏了代码的可维护性。
  • 测试通过与否的反馈只需几秒钟，而糟糕架构的代价（如未来修改困难、引入新Bug）则需要数周、数月甚至数年才能显现。
• “可维护性”缺乏快速验证器： 强化学习需要一个快速、可靠的“裁判”来评分。但代码可维护性没有这样的快速验证器，因此无法在训练中作为奖励信号。如果模型能可靠地判断代码好坏，它可能一开始就能写出好代码。

3. 解决方案：回归“以人为本”的流程

作者认为，在模型能力真正突破之前，必须重新引入人工审查和前期规划，以在速度和质量之间取得平衡。

核心原则： 接受约束，拥抱人工参与，追求“安全地快2-3倍”，而非“危险地快10-100倍”。

四个关键阶段（利用AI辅助，但人类主导）：

1. 产品评审： 在编码前，用简短文档明确“要解决什么用户问题”和“成功的标准是什么”。使用HTML原型图比长篇文字更高效。
2. 系统架构： 确定服务、端点、数据模型等如何交互，使用序列图等可视化工具对齐理解。
3. 程序设计： 这是被严重低估的一步。 在编写实现代码前，先定义代码的具体形状：类型、方法签名、程序布局、调用栈。使用伪代码、文件树差异图、关键函数签名等方式，将决策前置，避免在代码审查时才发现重大问题。
4. 垂直切片： 避免“水平计划”（如先做完所有数据库迁移，再做所有服务层）。采用“垂直切片”方式，每次完成一个端到端的功能片段（如从API到前端），并在每一步进行测试和迭代。这比一次性生成数千行代码再审查要高效得多。

总结与建议：

• 不要追求“无人工厂”： 目前它行不通。必须重新打开“灯”，让人工审查回归。
• 30分钟的规划可以节省数小时的审查时间。 对于重要任务，不要跳过规划步骤。
• 问题不在于PR太多，而在于糟糕的PR太多。 一个高质量的PR是审查的乐趣，而一个需要大量返工的PR是沉重的负担。
• 拥抱约束： 模型擅长某些事，不擅长另一些事。优化流程以适应这些约束，而不是试图无视它们。
• 最终建议： 深入了解模型的局限性，通过大量实践培养直觉，在约束范围内优化系统，寻找杠杆点，并且——去读那些该死的代码。

评论总结

核心观点：AI编码代理的现状与局限

1. 数据质量与工程纪律是关键（评分：None） - 多位评论者强调，AI编码效果取决于输入代码质量。doctorlove指出：“AI works on data. The better the data, the better the likelihood of a desirable outcome.”（AI基于数据工作，数据越好，结果越可能理想。） - 高纪律团队才能用好AI：“the teams seeing the best results with AI were already high-discipline and high-hygiene.”（看到最佳结果的团队本就是高纪律、高规范的。）

2. 模型能力存在根本性局限（评分：None） - 维护性问题是核心短板。jadar质疑：“why can't models do software maintainability?”（为什么模型不能做软件维护？）认为问题在于“harnesses can't do software maintainability”（框架本身做不到）。 - Robdel12用亲身经历说明：“models are no where near good enough to run off on their own without a human in the loop”（模型远未达到无需人类参与的程度），并警告“models LOVE to cheat”（模型喜欢作弊）。

3. 对“软件工厂”概念的质疑（评分：None） - AIorNot批评：“these arent 'software factories' they are strung together ai rube goldburg machines”（这不是软件工厂，而是拼凑的AI鲁布·戈德堡机器）。 - rapatel0指出：“A software factory will not work infinitely forever for everything”（软件工厂不能无限适用于所有事情），需要“establish intent, define what you care about, define guardrails”（确立意图、定义关注点、设置护栏）。

4. 积极实践与乐观视角（评分：None） - sergiotapia分享成功经验：“multiple non technical people at my job were able to build features”（非技术人员也能构建功能），认为工程师角色正转向“higher level facilitator”（更高层次的促进者）。 - 2001zhaozhao提出折中方案：“you can vibecode all the parts where maintainability doesn't matter”（可以在维护性不重要的部分使用vibecoding）。

5. 对文章本身的评价（评分：None） - vanuatu称赞：“This is one of the best writeups I've seen of this”（这是我见过最好的相关文章之一）。 - ozhero认为：“This is a very well written article and he makes his arguments backed up by data”（文章写得很好，论点有数据支撑）。 - 但fishtoaster质疑时间线：“any perspective/experience on 'what agents can/can't do' from before that period is... maybe less than relevant”（该时期之前的经验可能已不相关）。

平衡性总结

评论呈现明显分歧：一方认为AI编码代理存在根本性局限（维护性、决策错误、作弊倾向），另一方则看到实际应用价值（赋能非技术人员、提高效率）。多数评论者认同：当前AI编码需要人类监督，不能完全自主；数据质量和工程纪律是成功前提；对“软件工厂”概念应保持务实态度。