首先是你怎么看待 DHH，如果你把他当成商人、销售、网红、脱口秀演员、意见领袖，那无疑非常优秀。如果这些职业的人写这样一个东西，我还会去点个赞。

他这个行为，在没有 AI 的时代，类似靠着 google，用各个语言写了个 hello word。

But if you're no longer reading the code?

他真想证明不需要读代码，可以让 AI 对着文档，一个一个迭代实现，然后再给结论。

顺便说一下，DHH 八成和多数的 Rust“爱好者”一样，搞不清 Rust 所有权。

这个对比最大问题是 rust 版本有 300 多个 commit，其他版本都是几个 commit，一点都不严谨。

反而证明了不了解底层的话，vibe 难以一步到位，优化也找不到重点。

其实吧 目前阶段 ai 暂时代替不了大规模工程

问题就是 2 年前大模型还只是用来做 代码编写的时候输出的方法，现在已经可以勉强能实现项目

那么 two years later 呢？

从严肃的生产、长期的可维护、迭代的角度看，他 vibe 出来的这几个版本都是垃圾

维护和迭代，人能比得过 AI 了？

确实比不过，人类写 benchmark 的项目大概率写不出 db 操作没有连接池，而是全部串行 这种代码。

如果他不再阅读代码了，那他就发现不了这个问题，这还是别人帮他阅读代码后发现的

你猜这种写法是 AI 发明的还是真的会有程序员也这么做

不排除有初级程序员会这么做啊，但问题在于他的 AI 也跟着这样做了，而且上蹿下跳、沾沾自喜

看完这个对比，最大的启发其实是流程而不是结论：300 多个 commit 的 Rust 版和几个 commit 的其他版本放在一起比较，量级本身就不对等。我自己最近用 AI 做过一批小工具（文件整理、Excel 对账、报表拆分），同一个任务用「一次生成」和「分步验证」两种方式跑，前者偶尔会产出像「db 操作全串行」这种单看每行都对、整体却很怪的代码；后者把每一步的输出接测试或者真实数据校验，问题会早暴露很多。所以我觉得 vibe coding 短板不在 AI 写不出能跑的东西，而在「没有人读代码」时质量反馈回路断了——DHH 这次等于用 9 个版本做了一次没人读代码的压力测试，这个数据点本身挺有价值的。

我一点 rust 不会，不妨碍我用 ai 写 rust 工程并用在生产环境

现在大部分人都不看前端代码了吧，看不看代码其实不在于 ai 写得好不好，而是这个业务有多重要，或者说万一有点 bug 你能不能承受

短期看 AI 能不能验证（达到你能接受的程度），长期看 AI 能不能维护（AI 搞不定，或者在能接受的预算下，搞不定怎么办）。

DHH 想要说明的是，一个商业项目，可以不用看代码。但多数商业项目，需求有迭代，需要长期维护。他的例子显然不合适。

最后是看项目的复杂度是什么样的，在你不懂 Rust 的前提下，靠着 AI 能不能搞定。

补一个经验：图形验证码识别率低的时候，别急着换识别参数，先换会话和出口 IP 再试，命中率反而明显提高。大家做自动化时踩过类似的坑吗？

但是问题可能是都比 ruby 快。。。。

是个人就知道 Rust、Go 比 Ruby 快啊，这还用做 benchmark 吗？

争议点在于宣传一个 prompt 重写整个项目且不再阅读代码了

two years later，大家肯定都转行了，软件从长期看就是应该针对自己的需求生成。

Claude Code 团队如何进行代码审查 https://claude.dev/blog/solving-code-review-at-anthropic/

这不是用一个 prompt 重写出来了吗。。我想表达的是，重写的逻辑不完美，但是不完美的逻辑也比 ruby 快。

你是今天才知道 rust 比 ruby 快嘛？

你要真在意性能，当初前 AI 时代就不需要用 ruby 啊，写 go 能多花多少时间