The fact that an LLM now writes the code does not mean any abstractions we made before are suddenly less important or less useful. I didn't like having to write my own plumbing in Rust when I attempted a rewrite-in-rust and I wouldn't like an LLM to spend many tokens on it either, at least not in the process of writing my software. When we build a product for people we should be focused on solving their actual problems rather than writing job queues and ORMs and I believe that still holds true for a situation where an LLM writes 100 percent of the code. The framework provides a predictable structure to easily navigate a project, reason about it, debug it and extend it. And of course LLMs have been trained on frameworks and their usage as well.

Many people have shown that you can burn a bunch of tokens to rewrite things into several different languages. Does this now mean that it's actually trivial to rewrite an entire application into another language and that it just takes a bunch of money to burn? I'm not convinced, at least not yet. Different programming languages, frameworks and their surrounding ecosystems were all created under different constraints and took different design directions. This means that switching to another language means you have to make all kinds of decisions you never thought you had to make. The LLM will just make a random decision in order to reach its goal: to create a functionally equivalent programme that passes the same tests.

But will a full Rust-rewrite truly behave the same way? A lot of behaviour could actually be caused by the framework, libraries or programming language itself. Using a different programming language means a lot of this behaviour has now already changed, even if the business logic you write on top is computationally equivalent. Perhaps it fixes some bugs from the original application that a user already relies on today. Or it could introduce subtle new bugs that don't occur in the original framework but do in another. In any case I think there would be a high probability that users will be impacted by any rewrite, probably in a good way if the application got faster, but probably also in a bad way, when it suddenly behaves differently.

Which is why I think a full rewrite to Rust - especially when you are dealing with a user interface - is hard. Not because of writing the code but because you have to test it thoroughly. Our users are the kind that use our application for many hours every day. They have become very familiar with all its quirks and features and rely heavily on them to get their job done. When we move some pixels around or change an icon or a description, we immediately get complaints. Will a rewrite still work in exactly the same way? How can you be sure? Will it be worth it, or will you annoy all your users to the point where they won't trust your decisions any more?

So why even think about rewriting it in Rust when you can ask the LLM to simply... improve the performance of your existing application? There are so many ways you can optimise software and most of them don't require switching programming languages. As a bonus, it is much less likely that you change any behaviour when you simply instruct the LLM to "make it faster".

Actively developed frameworks, libraries and programming languages get improvements and security checks on a regular basis. The use of LLMs will just accelerate that even more. Just by updating your dependencies you get all of that for free, without having to test it yourself. This was already the case before and continues to be the case today. Perhaps in the near future, a new Ruby version will make all your existing code run 10x faster and use 10x less memory?

I also think there is still value in being able to look at the code and ask questions about it. If often reveals those decisions that the LLM never asked you about. It could have been some existing code or structure that was copied over in the assumption that all existing code is probably correct. Or the wording in your prompt was perhaps ambiguous, but not ambiguous enough to trigger a question for you to clarify. Eventually you would find out by testing. Or your users would find out and complain about it to you. In any case I prefer to avoid these situations by looking at the code. And the code being Ruby and the framework being Rails means I already know which parts are most important to look at when the agent proposes a giant batch of changes.

There are other advantages to using Ruby that you won't get with Rust. It allows for instant reloading of changed code meaning you won't have to wait for compilation to test any changes. You can use a REPL to play with code, inspect data or run scripts easily without a full compile and/or deploy cycle. I've seen coding agents use these features quite often to quickly diagnose issues.

Having said all of that, I am definitely excited and thinking about the possibilities of rewriting parts of our software in a different programming language, indeed mostly for performance reasons, but also out of curiosity and because it would be something new for me to learn. For me this would be the Go programming language because of its simplicity and fast compile times. I do not enjoy writing lots of Go myself as I find it rather verbose and repetitive, but I won't have to write much of it anyway. And it is so easy to read, even if you have little experience writing it. Go also compiles quite fast, allowing for relatively fast iteration and deploy, especially compared to Rust. Rust would obviously perform even better but comes with the downsides of slower compilation and harder to read code. In most cases the performance of Go should be more than sufficient anyway. I have some use cases where Go would be used in the background, avoiding the need for complicated interoperability with the existing Rails stack.

On the frontend I quite enjoy Svelte and I like the hot reloading capabilities in development, which is nice when you are experimenting with styles and layout. Switching the frontend over (from HTMX) to Svelte however would mean some fairly big breaking changes. Ideally you would use SvelteKit and run Node on the backend, which basically means a full rewrite in JavaScript. Or the Rails backend would need to supply data as JSON or GraphQL. I don't particularly like this kind of frontend/backend split as it leads to the dreaded spinners and pulsating grey placeholders everywhere while waiting on the numerous http requests that will be made to the backend. Perhaps when the LLM takes cares of both the backend and the frontend anyway, it can also just take care of those issues though.

To get back to the decision of whether to let LLMs rewrite everything in Rust: in the end a person is responsible for the software and will have to explain the decisions being made. And when that person is me, I choose to continue building our current application in Rails, at least for the time being. Is there other exciting tech? Yes. Does it solve more problems than Rails does? Probably not. Would I still use Rails for new projects? Definitely. Although I would be more tempted to try out something new and see what that would look and feel like. Would I choose Rust for anything? Maybe if I wanted to build something where performance would be more important than anything else, but I don't think it's a great fit for most run-of-the-mill business software.

In conclusion, does Ruby on Rails still make sense? Yes, I think it does.