问 HN：你知道有哪家公司又回到了手写代码吗？
AI 编码工具因能快速原型开发、减少“阻力”而受到称赞，但许多工程师表示，这种速度提升会被激增的技术债、几个月内形成的不稳定“遗留”代码库，以及对系统深层理解的丧失所抵消。评论者描述了不同策略：一些团队禁止或严格限制在核心代码中使用 AI，而将其用于审查、测试或样板代码；另一些则在管理层推动下尽可能多地使用 AI，哪怕牺牲质量和长期可维护性。一个反复出现的主题是，真正的问题往往不在工具本身，而在于领导力、激励机制和工作流，这些因素会把短期产出置于代码质量、学习和可持续工程实践之上。
问题范围
- 原帖作者问：有没有公司先采用了 AI 代码生成，然后又回退到人类手写代码？
- 若干回复表示，他们知道没有哪家在大规模上这样做过；也有人指出，很多公司至今还没有采用 AI 编码工具。
生产力提升 vs 代码质量
- 一些人认为，AI 通过消除阻力、加快原型开发，确实能明显提升短期生产力。
- 批评者说，如果这些“生产力”只是产出低价值或错误的功能，那就毫无意义。
- 许多人预测，长期来看，这些“收益”会在极端技术债和认知债的压力下消失。
技术债、遗留代码与“垃圾代码”
- 多条评论把 AI 形容为“核动力脚枪”：你可以在几个月而不是几年内构建出一个遗留代码库。
- 一个创业公司故事：启用 AI 后快速迭代导致核心代码混乱且不稳定；一次大重构失败了，因为 AI 会借助 git 上下文不断把旧模式重新引回去。团队正在考虑禁止在核心部分使用 AI。
- 还有人表示，当 99% 的改动都由 AI 生成时，团队会丢失对项目的知识；疑难 bug 处理起来会慢得多。
有限或不使用 AI 的政策
- 一些团队避免在核心/“深层”代码中使用 AI，只把它当作审查器使用（类似静态分析）。
- 一家约有 15 名工程师的创业公司会手写所有“有意思”的核心逻辑，只把 AI 用在通用 UI 和类似搜索的任务上。
- 另一家公司完全不用 AI；还有公司只允许把 AI 用于安全/性能检查或测试（但对 AI 生成测试的价值持怀疑态度）。
领导力、流程与文化
- 多人认为，混乱的 AI 驱动代码是领导力/流程失败，而不是 AI 不可避免的结果。
- 建议包括：为 AI 使用建立结构化工作流，强调沟通与共同理解。
- 有人指出，“团队开心地按自己喜欢的方式用 AI”与长期软件质量之间存在张力。
比较、类比与其他领域
- 有人把 AI 工具类比为 IDE、编译器和 Stack Overflow；也有人反驳说，AI 会“幻觉”，所以这种类比并不成立。
- 有报告称医生放弃了 AI 记录员：本来节省的时间都花在核对冗长且不准确的记录上了。
- 还有人担心，广泛依赖 AI 会削弱学习、工艺水准和整体产品质量，尽管企业会为了短期产出而进行优化。