I had the opportunity to attend Kaigi on Rails this year. Japan is a country that cares very much about both Ruby and Rails and has tenderly contributed to both for over two decades. To attend a Ruby event in a country that has fostered as well as attracted from overseas so many talented Ruby developers is something every Rubyist should do at least once. And while there has been a lot of excitement lately over other languages and the benefits of migrating to them, I left Kaigi on Rails with firm belief that Rails is here to stay, and that its future is bright.

The event this year was split into two halls with simultaneous presentations, so I unfortunately could not listen to them all. Some engineers talked about how Rails fit into their overall architecture, others about optimisation tricks, contributions to Rails itself, security, Hotwire and Turbo (which I still haven’t gotten the chance to use, unfortunately), best practices and such. What struck me was how grounded most of the talks were. Of course, each presenter did go into more abstract detail on why the ideas presented were good ideas, but they were all ideas I could go home and try out immediately on my own laptop with the product I work on. That was pretty exciting.

There were tons of merch and goodies handed out for free, like stickers, lanyards, Ruby passports, t-shirts and so on. Plus, free bentos for lunch, and snacks from sponsored booths (Money Forward included!). I am grateful to the event staff for running things so smoothly – not easy when you have so many attendees! The event hall was in Shibuya, so there was no lack of restaurants nearby serving delicious meals like cheese gyuudon, which I had for dinner after the event. It was a good location for an event and I hope they use it again next year.

I’d like to jump straight into my thoughts on my personal highlight of the event – David Heinemeier Hansson (DHH)’s talk – but allow me to first digress a bit to write about the developer experience with Rails. A big plus of Rails is how it knows what you want to do before you do it, saving you the effort of actually having to do it. Writing resources :posts automatically generates the routes you need to list posts, create a new post, show a single post, edit a post and so on. This has, over the past two decades, saved programmers many keystrokes from doing the software engineering equivalent of routine plumbing.

This also means that most Rails projects look the same, architecturally. There is no royal decree that you must use a model-view-controller architecture, but Rails makes this so easy with its preconfigured defaults that you would only deviate from this if you had a very good reason to. Jumping into a new Rails project is simple because its resemblance to your previous Rails project helps you understand the gaps where it differs, much like how there is no need to relearn the bicycle part of a tricycle – the additional wheel is all you need to get used to.

DHH gave his talk right at the beginning of this year’s event. He used the phrase ‘pencils down’ to tell us that the age of handwritten code has come to an end. That’s definitely true. 99.8% of my code last week was written by AI. That also means I haven’t had to think about Rails Magic in a while. Of course, I still remember that naming a model Person maps it to the people table, but do I need to? Not really. Does AI need to? It does, in order to work with this table, but does it appreciate this quality-of-life feature? Not really. There is no such thing as ‘quality-of-life’ for an AI agent. An agent doesn’t need rails generate scaffold – it’ll happily write it all up from scratch in seconds. AI doesn’t care.

During his talk, DHH showed us examples of ActiveRecord queries, written very elegantly in Ruby. That’s the point of an ORM, of course – it lets you write queries without SQL, in more familiar syntax, without the risks of forgetting to sanitise your inputs, and so on. ActiveRecord is nice to read and write – for humans. But to AI, there is no difference between ActiveRecord and SQL. Plus, ActiveRecord isn’t free – you pay the cost of runtime overhead in exchange for more readable code. DHH spoke about this and how we might go back to just writing plain SQL. AI won’t care either way.

ActiveRecord is just one example. DHH brought up how Rails has many libraries created for developer happiness that don’t really matter to AI, some of which slow down execution. While Rails has always had a reputation for being slow, Ruby itself performs quite well, so we might see a future where agents only use the bare minimum from Rails to scaffold a project and forgo the rest. I don’t think we should ditch Rails altogether, though. The resemblance of one Rails project to another is still useful to AI. Agents don’t need to remember the plumbing between files or how routes are configured if Rails guarantees that they’re always the same. And it does guarantee they’re the same because rails generate deterministically generates the same idiomatic code each time. That frees up context for your application requirements, which are what actually matter – the third wheel of the tricycle.

This also means less token usage and costs. If we really want to put our pencils down and start orchestrating fleets of agents mass-producing code, we must think of how to make every token count. I for one do not think that spending tokens to write public static void main(String[] args) is a good use of our budget, and Ruby (and Rails)’s focus on reducing developer keystrokes has coincidentally created a framework that requires very few tokens to code with.

To summarise, despite the title of this article, there is some Rails Magic that AI cares about. The future of Rails might be to focus on convention over configuration and to give us even more sensible defaults that agents don’t have to remember in their context windows. This is difficult to predict, however. During his talk, DHH talked about how there are ‘decades where nothing happens and weeks where decades happen’, and how we are now currently in the weeks where decades happen. It hasn’t even been that long since AI was struggling to draw Will Smith eating spaghetti and now we see changes to our agentic coding workflows every other week.

We should always keep in mind that AI agents are not animals that freely roam prairies, but rather, programs that are deployed, managed and paid for by humans. Whether to use Rails or not, and how much Rails Magic to use – these are decisions that affect code quality, reliability, and development costs, all things that impact both engineers and the end users we care about. It is therefore crucial that we make these decisions carefully, because AI won’t make them. AI doesn’t care.