软件工程与 GenAI 的八个神话

原文 ↗ Hacker News 讨论 ↗

有人声称生成式 AI 只能加速开发者一天中大约 14% 的打字编码时间，但这一说法遭到强烈质疑；许多工程师表示，现代工具现在能加速研究、设计文档、调试、测试编写，甚至产品规划。评论者争论的焦点包括：代码是否仍是主要瓶颈、团队能容忍多少 AI 生成的“垃圾”和安全风险，以及代码行数或自报提速是否真的是有意义的生产力指标。更深层则是对炒作、岗位替代，以及在激进 AI 辅助下构建的系统未来可维护性的广泛焦虑。

对开发者时间与工作流的影响

  • 许多人不同意文章中“AI 只影响 14% 的编码时间”这种表述，认为当前工具加速的远不止打字：调试、阅读遗留代码、编写测试、搭建脚手架、文档、Jira/Linear 管理、仪表盘和研究都被加速了。
  • 一些人表示自己一天大部分时间都在“驾驶代理”，审阅输出并协调工作；如今编码占比反而更大，因为其他任务变快了。
  • 也有人说，AI 只有在问题已经被理解之后，才会对“把想法写成代码”这一环节带来有限提速，类似更聪明的 IDE。

代码质量、审查与安全

  • 对 AI 生成代码到底能信任多少，存在明显分歧。
    • 有人选择性地只审查“重要的”或与安全相关的代码，其余部分则依赖测试或安全扫描器。
    • 也有人认为这很冒险，尤其是那些接触用户输入或生产数据的端点；他们看到的是“AI 代码膨胀”和巨大、难以审查的 PR。
  • 担心 LLM 带来的高产出会让彻底的人工审查变得不现实，从而把团队推向更高风险的规范。

生产力提升与指标

  • 代码行数被广泛批评为糟糕的生产力指标，尤其是在 AI 语境下，不过少数人仍为 LoC 辩护，认为在精选良好的项目中它是有用的个人替代指标。
  • 几个人指出，关于 AI 生产力的研究和调查很快就会过时；引用 2025 年初的工作被视为具有误导性。
  • 有人强调，生产力必须在系统层面或结果层面衡量，而不是看代码体量或 token 花费。

设计、需求与会议

  • 对 AI 是缩短还是拉长设计周期存在争论：
    • 支持方：更快的研究、自动起草的设计文档、低成本原型，会让“想法 → 测试 → 迭代”的循环更紧密。
    • 反对方：这会鼓励“凭感觉”做事，以及那些看起来已经完成、但实际上掩盖了糟糕或缺失设计的精美演示。
  • 有人认为，如果编码变得廉价，那么 PRD 的更多工作将通过代码/原型来完成，而不是通过会议和文档。

组织与职业影响

  • 有报告称，管理层期望生产力提升 10 到 100 倍，并按每位开发者设置 AI 预算；许多人认为这不现实，甚至危险。
  • 观察到采用情况并不均衡：有些工程师“全力投入”，另一些人则避免使用或私下使用 AI，有时是因为担心被认为能力不足。
  • 不少人预见，未来会分化为两类：“代码工厂”不断产出由 AI 辅助生成的垃圾，以及更小型的“工艺化”团队维护关键系统。

局限、风险与人为因素

  • 担心幻觉、边缘情况处理错误，以及快速生成但理解不足的代码会带来长期技术债。
  • 担忧“认知投降”：过度依赖 AI，以至于技能退化，并失去对系统进行推理的能力。
  • 一些开发者表示，当很大一部分工作由 LLM 生成时，尤其是在副项目中，他们对工作的乐趣和连接感会下降。