AI 时代的《神话人月》
AI 编码工具和自主 agent 正在极大加速代码生成，但许多工程师认为 Fred Brooks 的旧洞见仍然成立：瓶颈在于协调、理解和验证，而不是打字。评论者将 AI 描述为一种放大器，它让强大的开发者生产力大幅提升，同时也让较弱的开发者更快地交付更多未经检查的“糟粕”，并警告说审查和整合 AI 输出在认知上可能非常疲惫，而且在组织层面也很脆弱。普遍共识是，小型、编排良好的团队以及范围明确的任务最受益；而在共享代码库上天真地并行化多个 agent，可能会放大复杂性、技术债务和不一致的功能。
《神话人月》仍然适用（大体上）
- 许多人认为 Brooks 的核心观点仍然成立：困难的部分是协调、共享理解和设计一致性，而不是打字。
- AI 让代码生成变得廉价，但审查、集成以及记住当初为何做出这些决定，仍然是人类瓶颈。
- 有些人发现 AI 开发在认知上更令人疲惫：循环更快、决策更多，而且要持续警惕大规模变更。
- 在没有谨慎编排的情况下并行运行多个 agent，被认为只是把“人多手杂”的问题又复现了一遍，只是更快。
Agents、并行与编排
- 反馈并不一致：有人说多个 agent 会互相干扰工作、制造嘈杂的测试，并在循环中互相重写。
- 也有人声称，大模型可以很好地协调子 agent，借助计划、
git worktrees和清晰的任务边界，高效地并行运行多个 agent。 - 关于使用更便宜的子模型是否真的能节省 token，存在争论，因为主管模型仍然必须重新阅读并审查它们的输出。
- LLM 被描述为不擅长自我管理：会把计划写得过于细致，锁定次优设计，并且很少质疑早先的假设。
“更快给出错误答案”与原型开发
- 许多人认为，快速生成“糟糕但可运行”的 POC 具有巨大价值，因为这有助于澄清需求并让各方对齐，相比之下，昂贵而模糊的会议则效果差得多。
- 好处包括：有形的演示能暴露误解，用户更善于指出自己不喜欢什么，而且当代码很便宜时，沉没成本偏差更低。
- 风险在于：炫目的原型可能诱使利益相关方把一次性产物当成可交付产品；POC 也可能掩盖复杂性，并在缺乏足够深入思考的情况下把团队带上错误道路。
- 共识是：迭代胜过一次性追求完美，但验证、测试和人的判断仍然至关重要。
生产力、质量与团队动态
- 有些人报告了 ≥10x 的“已调试 LOC”生产力；另一些人则看到事故增加、臃肿加剧，以及可靠性和简洁性下降。
- AI 被广泛描述为一种放大器：强大且有动力的开发者会变得更高效；而能力较弱或投入不足的开发者会更快地交付更多未经审查的糟糕代码。
- 代码审查疲劳是一个主要痛点；工程师感觉自己被降格为 PR 审查者和 QA，这让许多人感到缺乏动力。
- 单人开发者加上 agent，或者非常小的团队，被认为越来越最优；在有 AI 的情况下，大团队会面临协调过载的风险。
认知与文化层面的担忧
- 有些人喜欢“工程总监”的角色——负责指定、批评、打磨——胜过逐行写代码。
- 另一些人觉得与 agent 互动很乏味，担心这会侵蚀他们的推理能力和工艺感，因此更愿意自己写代码。
- 还有人担心，组织激励机制（速度高于质量）再加上 AI，会加速技术债务和“影子 IT”，而不是构建可持续的系统。