大規模言語モデル（LLM）の台頭は、ソフトウェア開発の経済性を根本的に変え、コードの生成を大幅に安く、かつ速くしました。この変化により、本来は人間（開発者）の生産性を高めるために構築済みの構造を提供することを目的として設計された高レベルなフレームワークが、AIがRustなどのあらゆる言語で生のコードを低コストで生成できるようになった現在でも、依然として価値を保持しているのかという議論が生じています。低レベルな言語への移行を支持する議論は、多くの場合パフォーマンスに焦点を当てていますが、本番環境のアプリケーションを維持・進化させるという実務的な現実は、単なる実行速度を超えた複雑な課題を突きつけます。

Ruby on Railsのようなフレームワークは、開発者がプロジェクトをより容易にナビゲートし、デバッグし、拡張することを可能にする予測可能な構造を提供します。たとえLLMがコードを記述したとしても、フレームワークはジョブキュー、Object-Relational Mappers（ORM）、セキュリティプロトコルといった「配管」部分を一貫して処理することを保証します。たとえ機能的に同等であっても、別の言語への完全な書き直しは、微妙な動作の変化を引き起こす可能性があります。ユーザー向けの多くの癖や機能は特定のフレームワークや言語のエコシステムに結びついているため、書き直しによって既存のユーザーワークフローを破壊したり、元のスタックには存在しなかったバグを導入したりするリスクがあります。さらに、積極的にメンテナンスされているフレームワークは、開発者にとって「無料」で提供される継続的なセキュリティアップデートやパフォーマンスの向上を提供しますが、これらをカスタムビルドされたソリューションで再現するのは困難です。

構造的な利点に加え、言語の選択には開発者体験と反復速度のトレードオフが含まれます。例えば、Rubyは即時のコードリロードやREPL（Read-Eval-Print Loop）環境を可能にし、これらは迅速な診断やテストにおいて非常に効果的です。Rustのような言語への書き直しは優れたパフォーマンスを提供するかもしれませんが、多くの場合、より長いコンパイル時間や複雑な構文を伴います。多くのビジネスアプリケーションにおいて、低レベル言語によるパフォーマンスの向上は、完全に新しいシステムをテストするコストを上回らないこともあります。完全な書き直しを行う代わりに、開発者はLLMを使用して既存のアプリケーションを最適化することができ、これならばコアな動作を変える可能性を抑えつつ、パフォーマンスの目標を達成できる可能性が高くなります。結局のところ、フレームワークは複雑さを管理するためのツールであり、開発者の焦点が基礎となるインフラの再発明ではなく、ユーザーの問題を解決することに向けられることを保証するものです。