AI 生产力鸿沟
AI 编码工具和代理正在改变软件工程师的时间分配：它们压缩了实现工作，但往往扩大了规划、监督和审查的工作量。许多人报告个人吞吐量有所提升——尤其是初级工程师和结构清晰的任务——但也抱怨要“照看”代理、代码臃肿或存在隐蔽错误，以及对系统理解下降。一个反复出现的主题是：如果没有刻意的流程和质量控制，AI 只是在转移瓶颈，而不是消除它们，这也引发了关于团队长期生产力、技能发展和代码库健康的疑问。
感知到的生产力提升
- 体验从大幅加速（2 倍到“1.5 小时完成一人周工作量”）不等，也有人感到总体生产力中性或负面。
- 许多人指出，AI 能极大压缩实现/样板代码时间，但对架构、集成和验证的帮助要少得多。
- 一些领导者误以为 AI 能带来统一的 X% 速度提升；评论者则认为，不同任务上的改善差异非常大。
开发者工作的转变
- 有人形容自己从亲自写代码的人，变成了多个代理的协调者，甚至是“赶猫的人”。
- 盯着、反复提示和引导代理会让人觉得乏味且耗神。
- 为了避免这种额外开销，有些人把 AI 仅用于自动补全或最初的样板代码。
代码质量、审查与 Bug
- 人们强烈担心 AI 生成的代码不那么可信、更长、更抽象，也更难推理。
- Bug 往往很“非正常”：奇怪的删除、猴子补丁、诡异的并发问题、微妙的作弊。
- 由于 PR 过于臃肿、测试说明冗长，以及作者对自己代码的理解也更少，审查时间往往增加。
- 也有人认为，在使用 AI 时，人类审查反而更加必要；少数人则认为，以人为中心的风格预期可能与 AI 生成的代码并不匹配。
流程与工具很重要
- 一些团队报告，在严格流程下生产力提升约 2 倍：前置规格说明、规划、由第二个模型进行对抗式审查，以及大量文档化。
- 强调“harness engineering”、上下文管理、标准化的入场/收尾流程，以及知道何时终止或改向糟糕的代理会话。
- 其他人则认为，如果把 AI 直接塞进旧工作流而不重新设计流程，就会出现混乱。
初级、资深与技能
- 初级工程师和实习生借助 AI 可以产出更多，但也有人担心他们会形成肤浅理解和“LLM 监督员”式习惯。
- 有些人担心长期上会侵蚀专业能力，并加重对少数供应商的依赖。
- 建议的工作流包括：初学者手动重新输入 AI 建议以学习；有经验的开发者主要用 AI 做补全，而不是做架构。
组织与系统层面的限制
- 评论者提到阿姆达尔定律/约束理论：只加速编码，通常只是让工作队列变长。
- 上游（需求）和下游（QA、运维、采纳）流程仍然是串行的，并受人力约束。
- 小团队和经过精心设计、对 AI 友好的技术栈可能获得更大的收益；而在更大的组织里，这些收益更难实现和衡量。