AI 编程之后，软件可以做得更大胆

Dan Luu 从 Michael Malis 的 pgrust 项目谈起。面对大量粗制滥造的 AI 重写项目，人们怀疑它很正常。但 Malis 做了足够深入的测试，甚至找出了 Postgres 本身的错误。即使 pgrust 没能成功，这些修复也会留下价值。不过，Malis 也明确表示，当时不建议把它用作主要生产数据库。

Dan Luu 更愿意把“应该更有野心”说成“可以更有野心”。别人不断制造劣质软件，并不妨碍开发者认真测试、测量性能，把过去负担不起的项目做出来。

他拿自己的工具链举例。考虑到模型进一步提速后，搜索、Rust 编译和文件操作可能成为瓶颈，他做了正则引擎、ripgrep 分支，以及加快自己项目构建的 Rust 工具。他估计，过去做到“自己能用”需要一年以上，如今只投入了几个小时的个人时间。要达到公开产品或开源项目的质量，仍有大量工作；文中也没有提供严谨的全面性能测试。

很多程序员仍沿用智能体出现前的成本判断。以前，因为编译慢就另写编译工具，很容易变成永远交不了货的折腾；如今，某些定制方案已经值得尝试。

他还比较了桌游 AI 的开发经历。早期模型经常把论文方法实现成似是而非的东西，需要人读论文、反复纠正。新模型在这方面明显进步。他的 zstd 小型评测也变得太容易，只好换成 IMAP 和 Pandoc 等更难的任务。但目标随能力提升而扩大，实现与自主验证之间的差距仍在增加，他没有获得“交给模型就万事大吉”的体验。

附录里，Yossi Kreinin 提出反驳。许多任务没有清晰的成败标准，人也难以理解生成的大型黑箱；针对少数案例的优化，可能留下难维护、无法推广的代码。Dan Luu 认可这些问题，仍认为可以主动设计一致性检查，结合模糊测试、基于性质的测试，提高验证能力。

他随后谈到只为自己制作的游戏、极其挑剔的 Neovim 格式化工具。这些需求过去往往不值得花时间实现，如今有了动手的理由。与此同时，模型和工具变化太快，也不宜在很快可能过时的工具上投入过多。

相比 AI 实验室依靠充足资源完成的大项目，他更看重普通人在业余时间做出的成果。软件的尝试范围扩大了，判断和验证的能力依然决定成果能走多远。

#AI #软件开发 #编程