已经不存在“小型软件团队”这回事了
关于 AI 编码 agents 会让每个工程团队都变成“超大团队”，从而支持数百个并行变更的说法，遭到了大量质疑。评论者认为，把系统拆成成千上万个微服务只是把复杂性转移到了运维层面，还会让协调更困难，并可能制造出大量为了 PR 数量而优化、却缺乏用户价值的低质量代码。许多人把 LLM 看作个人开发者和小型、架构良好的单体系统的强大工具，但也警告说，过度依赖 agents 会威胁可维护性、产品聚焦，以及人类软件工程师的长期角色。
Agents、“小团队”和生产力指标
- 一些评论者怀疑，依靠 agents 实现“小团队”每天 100 个 PR 之类的说法并不意味着真正的进步。
- 高 PR/commit 数量被视为很容易被操纵的虚荣指标，在 AI 时代与用户价值进一步脱节。
- 据称，一些组织如今会向“落后者”施压，要求更用力地使用 AI，即便 AI 生成的工作最后还得悄悄重做。
在 AI 之下，微服务 vs 单体
- 许多人认为，微服务会增加运维复杂度（部署、网络、重试、一致性、版本管理），却并不会消除产品本身的固有复杂性。
- 一些人表示，结构良好、代码模块化且边界清晰的单体仍然更优，尤其因为 LLM 可以保留更多上下文。
- 另一些人则认为，更细粒度的服务，甚至“纳米服务”，更符合 LLM 的上下文限制和 agent 的并行性，但这一点存在争议。
质量、正确性与协调
- 很多人强烈怀疑 agents 能否安全地修改成千上万个服务：agents 缺乏完整系统上下文，可能引入微妙的跨服务破坏。
- 并行的“agent 群”面临的风险是语义冲突，而不只是简单的合并冲突，这会让集成和发布协调更困难。
- 有人建议把 AI 用于维护：强制约束不变量、简化代码，或系统性地偿还技术债务——但也有人反馈，随着上下文变大，模型往往会忽视不变量。
开发者体验与工作影响
- 体验分化明显：一些独立开发者/小团队开发者声称 LLM 带来了巨大生产力，甚至能推动整套应用重写；另一些人即使不用它们也同样高效。
- 关于未来角色的争论：从“你要么是 prompt engineer，要么就被炒”到“系统设计、理解能力和工艺水准仍然至关重要”。
- 有人担心，资深工程师的架构知识被不透明的 AI 生成改动所取代后，一旦有经验的员工流失，故障率会升高。
伦理、经济与社会问题
- 人们担心对外部 LLM 供应商的依赖、不可预测的成本、隐私风险、版权问题以及技能退化。
- 一些人认为，AI 驱动的生产力与社会需求并不一致（“更多烂应用”，而不是“更好的”软件），其背后是投资者的 FOMO 和“tokenmaxxing”。
- 另一些人则认为，AI 是一种永久性的、变革性的技术浪潮；也许会有 capex “寒冬”，但不会回到 AI 之前的软件开发方式。