大语言模型（LLMs）的兴起从根本上改变了软件开发的经济模型，使得代码生成变得显著更便宜且更快速。这一转变引发了一场辩论：当 AI 能够以低成本生成任何语言（如 Rust）的原始代码时，最初旨在通过提供预构建结构来提高人类生产力的框架是否仍具价值。支持转向低层语言的论点通常集中在性能上，但维护和演进生产级应用的实际情况引入了超出简单执行速度的复杂性。
像 Ruby on Rails 这样的框架提供了一种可预测的结构，让开发者能够更轻松地导航、调试和扩展项目。即使是 LLM 编写的代码，框架也能确保“管道”部分——如任务队列、对象关系映射器（ORMs）和安全协议——得到一致的处理。即使功能等效，全量重写到另一种语言也可能引入微妙的行为变化。由于许多面向用户的特性和功能与特定的框架和语言生态系统紧密相关，重写可能会破坏现有的用户工作流，或引入原始技术栈中不存在的错误。此外，活跃维护的框架提供持续的安全更新和性能改进，这些对开发者来说是“免费”的，但在自定义解决方案中很难复制。
除了结构上的优势，语言的选择还涉及开发者体验和迭代速度的权衡。例如，Ruby 支持即时代码重载和 REPL（读取-求值-打印循环）环境，这对于快速诊断和测试非常有效。虽然重写到像 Rust 这样的语言可能会提供卓越的性能，但往往伴随着更慢的编译时间和更复杂的语法。对于许多业务应用来说，低层语言带来的性能提升可能不足以抵消测试全新系统的成本。与其进行全量重写，开发者可以使用 LLM 来优化现有应用，这在实现性能目标的同时，不太可能改变核心行为。最终，框架仍然是管理复杂性的工具，确保重点始终放在解决用户问题上，而不是重新发明底层基础设施。