AI 改变了软件重写的经济性

原文 ↗ Hacker News 讨论 ↗

AI 与重写的经济性

  • 许多人认为，AI 确实让重写更便宜、更快，尤其是对小到中型代码库而言，这使得“沉没成本”不再是那么大的障碍。
  • 另一些人则说，这种看法主要忽略了漏洞、维护和组织失调的成本；更快地替换符号并不能解决更深层的问题。
  • 也有人认为，AI 正在降低“功能完全一致移植”的成本（例如，为了摆脱过时的框架或平台），而不会改变语义。

测试、保真度与可维护性

  • 普遍共识是：AI 重写是否有用，很大程度上取决于测试覆盖率和测试工具。
  • 支持者声称，AI 能比人类重写更好地保留旧系统的边缘情况，并且可以帮助生成测试工具。
  • 持怀疑态度的人报告说，LLM 会漏掉边界情况，把棱角“磨平”，忘记约束，并且需要持续纠正。
  • 即使使用 AI，要验证行为是否等价，往往仍需要逐行映射以及大量手动或自动化测试。

什么时候重写才有意义（或没有意义）

  • 一些人强调 Joel Spolsky 式的谨慎：重写经常失败，尤其是在你同时更改功能和技术栈时。
  • 另一些人反驳说，极端的技术债和过时的技术栈会让组织陷入瘫痪；有时重写加简化是必要的。
  • 一种普遍观点是：如果你要重写，首先应以行为完全一致的替代为目标，然后再进行简化和演进。

技术栈选择、买还是造，以及组织因素

  • 流行且稳定的技术栈有利于 AI，也有利于招聘；严重的弃用情况会让模型困惑。
  • 良好的内部文档可以让定制框架也能被 AI 有效使用。
  • AI 降低了定制化“造”的成本，但“买”和“造”都仍然包含长期维护。
  • 许多人指出，组织文化、激励机制和监管约束往往比技术经济性更重要。

LLM 的感知局限与使用方式

  • LLM 常被比作初级开发者：在指导下擅长局部任务；但作为自主架构师或大规模重构者则表现不佳。
  • 相关报告包括：在不常见的 DSL 上失败、对系统行为误分类，以及推理不稳定。
  • 一些人看好 AI 辅助的 transpiler，以及用 AI 设计架构和测试，但前提是必须有人类监督。

元话题：文章质量与 AI 讨论

  • 多条评论批评这篇链接文章像 LinkedIn 风格的“broetry”，而且很可能是 LLM 写的，缺乏实证内容。
  • 也有人表达了对重复、两极化、低信息量的 AI 评论的更广泛不满。