“I have unlimited tokens. We can fix everything, we can do anything.” — local man discovers LLMs, declares engineering tradeoffs obsolete

I have been using Laravel since version 4 in 2013. Over the years, Laravel has evolved significantly. I initially chose Laravel over Rails due to its favorable position in our local job market. In 2015, I started building our own business using Laravel. Today, that business is the largest job board in Iran, serving over 3 million job seekers and 100,000 employers. Laravel performed well for us, until it didn't.

Over the years of maintaining this application, I have come to some conclusions, both in terms of code and team dynamics. Our entire product/tech team has never exceeded six people, including designers and product managers. During the COVID-19 pandemic I managed everything solo Product/Tech wise.
I have also been part of projects using Spring, Symfony, and Django. We were among the first adopters of Vue.js back in 2015, starting with Vue 0.12.

I told you the story to picture the pains I've been encountering during maintaining a Laravel application over 9 years.

Sticking to framework defaults
Over the years, I have realized that adhering to framework defaults at least 90% of the time is the best way to ensure easy upgrades, address security concerns, adopt new technologies, and hire new developers. Even though there are architectural trade-offs, the benefits outweigh the drawbacks.

Laravel changes opinions and defaults
Laravel tends to change its opinions with every major version or introduce new ones. Most of the time, these new opinions permeate every part of your application. In contrast, Rails sticks to its architectural roots. The "Rails way" remains similar to how it was 10 years ago, allowing you to join a project that respects this method and perform easy upgrades, onboard new developers, or add features seamlessly. Laravel, however, is not like that.

Over the past 10 years, Laravel has promoted various combinations, such as (Vue + Laravel), (Laravel + Inertia), Livewire with class components, and Laravel Folio + Volt. This is just on the framework side. The community, including the framework authors and the crew (like Laracasts), has promoted multiple nonsensical architectural ways of writing software. Many of these make no sense, such as repositories with active record models, repositories as service objects, service objects with models, service objects with models and repositories, and service objects with in/out DTOs.

I found my way early on, but this inconsistency makes it hard to find new developers and maintain a consistent codebase. Every community has its challenges, just like the ones I mentioned, but I have never seen DHH, for example, seem confused about how to write Rails software. Look at the source code for first-party Laravel packages like Breeze Scaffoldings, Laravel Fortify, Laravel Telescope, Laravel Sanctum, Laravel Spark, Laravel Pulse, and Laravel Horizon. Each of them has different choices on how to write software, which is precisely the problem I’m facing. Even the framework owner seems inconsistent on how to write business software or near-end user components with Laravel. There are too many choices, and some are abandoned while others are equivalent to each other.

Laravel is somehow merchant of complexity
People are always eager for new content, new tools and new approaches to writing software. Developer tooling authors often build their business plans around this demand, which isn't necessarily bad, but it does have side effects. This is the problem when a dedicated company including a full-time team works on a set of open-source products: the framework is designed for revenue after some years. Basecamp does a ton of marketing with Rails, but I respect how they keep their commercial software separate from their open-source extractions.

Part of these new opinions on how to write software stems from trying to attract everyone and every method. In recent years, Laravel has turned into a sort of food court. Need MVC? We've got that. Think Phoenix LiveView is cool? We create Livewire as a first-party package and promote it everywhere in the docs. Is the React handler+view in one file hyped? We create Laravel Volt + Folio. People love React and Vue but find writing Next and Nuxt hard? We create Inertia. We have responses for every question and consideration.

Yet, from a developer's point of view, you have to keep up with every new cognitive load you're faced with. Nearly all of them are just noise, with only a few, like Inertia, offering something valuable. Sometimes, the old ways are completely abandoned. Although not entirely without backward compatibility, they are neglected and receive no care. Laravel has somehow become a merchant of complexity, constantly introducing new paradigms that add to the cognitive load for developers. Then, they sell courses, books, commercial packages, and companion software around these new paradigms. I'm really okay with this part, but it significantly affects community packages and standards, developer skills, and codebases, this is the part I'm not OK with.

Enough philosophical things—let's talk about code.

ActiveRecord is years ahead of Eloquent
Eloquent has mimicked ActiveRecord but hasn't brought over the most important parts. ORM is a key component of a battery-included framework, and Eloquent has received nearly zero upgrades since 2015.

Part of this is due to Ruby's influence, but that part is manageable. Eloquent lacks several crucial features, such as self-validating models, commit callbacks, and models acting like aggregate roots. This isn't just about putting validation rules in Laravel form requests, controllers, or models; it's about validations being an important part of the model's existence. They fundamentally change how you define behavior, states and solve problems. In Rails, it's much harder to put a model in the wrong state because of self-validating models, models acting as aggregate roots, and model callbacks being first-class citizens.

With Eloquent, you have to wrap nearly every multi-model interaction in an explicit transaction block, and I've paid the price (even financial price) for missing it, which is easily available in other ORM libraries. Eloquent behaves like a Row Gateway during writes, making it easy to corrupt data states in different parts of your app.

The syntax in Ruby for defining validation rules on a model, accessors, or callbacks is far better than the options available in PHP. I love Active Record pattern because of its progressive behavior during development, but I've reached a point where I define rules, getters, setters, casts, fillable, and guarded attributes independently, instead of defining them for a single field in a data mapper ORM with poor syntax that combines object behavior definition with metadata. How can a battery-included framework that offers multiple ways of building front-end! not offer optimistic locks or commit callbacks for models? I mean callbacks, not event listeners, which introduce the highest level of possible indirection when scanning code—another problem in itself.

Service providers are PHP bullshit
Rails has the advantage of not requiring dependency injection (DI) or inversion of control (IoC), so you don't struggle with IoC on simple tasks like saving an input field to the database. You just see business code in your implementation. In contrast, Laravel uses facades and extensions to address this, but they feel like hacks. As a result, you're left with pages of configuration files and limitations on extending functionality.

Blade is better than ERB
I like ViewComponent in Rails, but even ERB with ViewComponent doesn't match the capabilities of Blade, especially when it comes to components. The XML-like syntax for writing templates is really nice.

About Routes, FormRequests, Policies and Middelwares
When you write a CRUD operation in Laravel, you might end up defining nearly five classes: two Form Request objects, one controller, a policy class, and a simple model, each existing in a separate folder within the application. One of my experiences in programming is the importance of keeping related things together. Rails still has this problem, but you don’t necessarily have to define five classes for a single feature. Using Livewire? You'll need even more classes. Despite this level of abstraction, it's not necessarily enough; there are tons of business-logic-filled middlewares in every Laravel app.

Rails' controller lifecycle callbacks, together with concerns, are a blessing. You still write simple Ruby code without defining a dozen layers just to save a form to the database and introduce some side effects. Route model bindings seem very attractive at first sight, but in a real Laravel project, you either see tons of query logic in explicit route model binding definitions leaking through service providers, middlewares, and route files, or you find yourself performing repetitive find queries for the same fetch logic in hundreds of controllers, passing them to view files each time. Alternatively, you might invent a new class/service/action for these jobs, which every implementation differs from every other Laravel app you've seen.

When learning Laravel, the documentation heavily promotes route model binding, but it seldom mentions that they are not nested through current user and that you MUST define policies for controlling access to them. Just search for sites using Livewire JS file on the internet, create accounts on those sites, and you will likely find many that allow you to access other users' resources by changing parameters in URL.
In Laravel, the routes definition file sometimes contains more logic than your controllers and models combined. Read the documentation for gateways and policies on the Laravel site; they offer dozens of methods for doing the same thing—the scroll is longer than the HTTP server implementation file in Go.

Form Requests advertise nothing about abstraction. Open a standard Laravel project, and you'll see repeated code for rules and authorization everywhere. I've developed the same app for nine years, and believe me, this simple thing annoyed me the most. The annoyance was doubled when they introduced Form Requests. Rails, by default, uses request-lasting query caching for fetching ActiveRecord queries. Open a Laravel app, and you'll see repeating queries in middlewares to control payment walls, bans, etc. There’s still no clear way of sharing data from middleware to controllers. You have dozens of options: singleton classes, request merging, request extending, etc., but no one uses them effectively. At some point, you don't even know what middlewares are bound to your route, and you get surprised.

Laravel controller methods nearly just function as input-output handlers, which is okay, but combining them with dozens of layers and concepts to perform a simple before_action callback directly in the controller or the parent controller is excessive.

Rails has much less noise by not having these features. Rails carefully advertises the way it does things and carefully chooses what not to include to prevent becoming feature-bloated. This is a feature not a bug.

Rails Documentation
At first sight, Laravel seems more documented than Rails, which is true when considering a beginner's perspective. However, the feature of Rails writing the real documentation alongside the code itself is really, really nice. You figure out by Ctrl+B and feels really productive.

Hotwire is better than Livewire
I really believe that simple MVC with strict resource controllers is the best way to decompose an app with hundreds of screens. However, Livewire somehow prevents this. You write your logic alongside some JavaScript-related code, and changing the UI significantly impacts your backend implementation since they live together in the same component. This leads to a lot of dead code in Livewire for long-term maintenance projects, and edge cases are really hard to fix. Additionally, the Livewire way of writing software is deeply specific in its own environment. For instance, I can discuss about models, controllers, before_action, or middlewares—concepts that exist in nearly every framework or library. However, developing software in Livewire, involves a very specific and unique implementation that doesn't translate well to other approaches.

I've also found that 90% of JSON API exposures are just response format changes, which is strongly utilized in the Rails community and is much harder and nearly impossible when using Livewire. With Livewire, you end up writing multiple controllers that do the same thing. Sticking to this design may seem hard at first, but it really keeps the application maintainable and understandable in the long run.

Additionally, I really wish development teams would recognize the value in the Shape Up method. One of its key components during cycles is progressive development. If you want to implement a feature, you can start by writing dead simple HTML and then implement the functionality, wiring them together and adding interactivity later. I think Rails encourages this behavior by the way Hotwire works, and it is really wise.

I also believe that creating TRULY VERY high-fidelity UIs with Hotwire is not possible or practical, but I have accepted the trade-off. Most of the time, I struggle to create those UIs even in environments like Vue. Overall, I really like the progressive approach of Hotwire and the low footprint it introduces, but I think Alpine.js is a better alternative to Stimulus.

Rails developers seem to be more skilled in Rails' front-end offerings because it recommends a single approach through Hotwire. In contrast, Laravel offers multiple stacks, making it harder to find a full-stack developer. At least in our local community.

Notifications and Mailer
Laravel allows defining notification classes that can have multiple destinations: email, push notifications, database, webhooks, etc. Rails has mailers, but they are not designed out of the box with the same semantics as Laravel's notification system. I really wish Rails would make this section more unified by introducing web push notifications in Rails 8. The same lack of important features applies to background jobs and writing console commands.

First party packages and Ecosystem
At first sight, it seems Laravel has tons of first-party packages that do a lot of things, but I really think they create much more noise. The Rails community seems more focused on promoting building actual applications, while the Laravel community seems more focused on developer tooling (not developer experience), keeping developers busy figuring them out. That's why you see more end-to-end apps written in Rails on GitHub. Many communities have had their hypes, but relatively few have produced projects like GitLab, Postal, Mastodon, Redmine, and so on compared to other types of open-source projects.

That's the real power of an ecosystem. You have the option to see what real-world code looks like by exploring some of the best end-user-facing applications. I was around the Laravel community for more than a decade and never found a project that improved my knowledge as much as something like Postal or GitLab did. The Laravel community is warm and welcoming, but they are heavily focused on developer tooling.

I don't know if I've successfully transferred my point, but Rails and Django might be the only full-stack frameworks that give me the feeling that you can be cool and show off by building or teaching how to create end-to-end applications, not just by creating libraries.

The only true masterpiece in the Laravel ecosystem, for me, is Forge. It is truly excellent and frees your mind from many concerns. As for libraries, they already exist in the Rails community or are some fancy additions to my workflow. The real pains I experience are those mentioned above.

Conclusion
In the end, I'm really thankful to Laravel. It allowed me to make real money as a young developer who was just eager to build a good life through the internet. However, I have chosen to continue my path with Rails. I feel happier and more productive when I write in Rails compared to Laravel. While I can customize Laravel to my needs to a certain extent, as I mentioned earlier, there is great value in sticking to defaults. Alternatively, if you don't want to leverage the offerings of a battery-included framework or they require extensive customizations, you might consider using very verbose and explicit languages like Go. However, these customizations can make tasks like finding a new developer or performing upgrades more challenging. 

This is in no way a recommendation for the job market. Job market dynamics vary from place to place and are not usually influenced by personal preferences or personal considerations like the ones I mentioned above or being a one person framework. Typically, the most hyped technology is the one that commands the highest salaries. From this perspective, TypeScript/JavaScript is currently more hyped than anything else on the planet.

I just wanted to share some thoughts on Rails and it's current state and what I've learned along the way, especially recently (kinda long).

The Beginning

I started with Ruby on Rails in 2007 or 2008, and I'm thankful I got to see the whole wave, when Ruby was the absolute hottest language and the pay was insane. It started so many huge companies that are just common place today. Twitter, AirBNB, Shopify, etc.

By about 2013 I realized that Rails was on it's way out, sort of. It at least wasn't the hotness anymore. When Alexander the Great died his territories were split between 4 or 5 generals. That's sort of what it felt like to me. Node hit the scene and a ton of stuff went that way. Go arrived and fast API's went there. Tons and tons of Front end frameworks came along.

Heyday is over

It's safe to say that in 2023 Rails is just not what it once was. The amount of jobs are way down and the pay is too. It's not by any means terrible but it is what it is.

For me personally I really embraced the change. Rails to me had gotten so bloated. I mean almost everyone was running Rails + React or something similar. It's not the greatest language, because it's always been difficult to hire for. So most of my last 15 years have been in Rails but then in 2019 I decided to semi-retire. I drastically reduced my expenses (by 80%) and could live off the money I saved and investments, etc.

Trying other frameworks

With that free time I decided to do what any self respecting programmer would do. I did side projects! I love to code and I just wanted to make stuff, and I figured I'd build some stuff and maybe make a few bucks.

Well... That didn't go as planned. I tried all the languages out there. Rust with Leptos/Dioxus, SvelteKit, React, NextJS, RemixJS, SolidJS/Start, Elixir/Phoenix. The worst part was, I'd write the app and would even finish it but then I'd write it in something else. Like literally from scratch. I wrote the same todo app 6 times. I even used PHP. But I wasn't gonna use Rails.

Rails to me was too clunky. It's heavy weight, it's such a pain to install on Ubuntu, I just hated it. Like with Node or GO I could install the language in 2-3 minutes and the app is running on the server. It's so easy, I loved it.

I couldn't put my finger on it though but there was always something missing, something I was chasing after in developing these apps, but I didn't know what it was. But it was always something. With some of these JS frameworks they were incredibly popular but even things like getting access to the cookies was hard via RPC calls. It's new fangled but it just doesn't work well.

I had cookie issues in Nuxt where your best bet for handling cookies was a third party plug in and it's semi abandonware, or at least the documentation is bad and there isn't much activity on it. So then I'd use something like AlpineJS which is nice but doesn't support components.

As a programmer this really just ate at my soul. Why is this stuff so freakin hard? This shouldn't be that hard.

I see people are bashing on Rails/Ruby a lot

I've (stupidly) got into plenty of arguments online because I've seen so many people who are just bashing the crap out of Ruby/Rails. "Twitter made a mistake using it, so did shopify. There are so many better options, blah blah blah."

But that was just ridiculous. Rails built so much of the Web 2.0 world and was a spaceship compared to the horses that came before it. You could build a whole app in the time it took you to get your J2EE app set up.

A little bit of hope

So recently I've watched some of DHH's posts and talks about how great Rails is, and it felt like a man kinda holding onto a sinking ship. Mostly because the world has migrated away from Rails and there are a lot of criticism I've seen on how Hey is pretty clunky to use vs native apps or even JS based apps.

I haven't used it so I can't talk about it. But DHH said something recently that made me think. He mentioned that since Twitter switched off of Rails their feature development stagnated. I'm an anti microservice person already, but in thinking about that, honestly Twitter has hardly added any features in the last 10 years.

And, I don't know exactly how much their transition saved them financiall as they were spending billions on cloud hosting.

Giving Rails another shot and it all makes sense now

So after recently having rewritten an app again in yet another language I figured I'd give Rails a try again. I used 7.1, and after not having used Rails for a year and a half I actually forgot a lot. But, it wasn't too bad. Came back to me pretty quick.

After 2 days I had my app written and it all made sense to me now. That's why I just couldn't live with the other apps I had written. Rails, for all it's flaws, is absolutely incredible. If you need to set up a association between models and have a dependent destroy? No problem

`has_many :posts, dependent: :destroy`

That's it. I was doing the same thing in Node with Prisma and my god it's a pain. I had a 20 line query in Prisma that was reduced to 2 lines in Rails. I realized I was miserable with these other languages because it takes so much extra typing. Ruby is just amazingly easy to use and so, so powerful.

Another thing I struggled with in these other frameworks was how to get the current user. You'd need middleware and there were problems with that half the time. I'd have to add it to the request object and in some of the JS frameworks specifically you'd get different request objects at different times so your data wouldn't be there.

With Rails I just create an AdminController and have a current_user method there, and make my other admin controllers descend from it. It's so freakin easy. So easy. I feel like someone who's been lost in the woods for months and now I've made it back to civilization and I'm not struggling to get the bare necessities anymore.

Also, now with really nice Turbo integration, you really don't need a frontend framework. You might need JQuery or alpine JS for some really complex forms, but for most pages it really behaves like an SPA out of the box.

It's amazing that, really, no other framework has really caught up with Rails

Laravel in PHP is quite good, and has a ton of add ons. It's nice. But really, I'm just blown away by how good Rails is. I'm really lost as to how so many apps are written in JS frameworks without all the features that Rails has.

No one has made a popular and unified platform that has validations, a great ORM and all the other things Rails has. You have to kinda bolt on all your own stuff to get it going.

What is the future of Rails?

Having seen how great Rails is I've decided that all my future projects are gonna be Rails projects. The only problem is that for me I have to use Docker/Compose. I don't want to deploy to platforms Like Heroku as they kept pulling the rug out from under me and I'd have to do emergency upgrades as they got rid of stacks and providers.

It was fine though. I wrote a docker compose file with NGINX in the front and it wasn't a problem to get it deployed (sqlite for now).

So what is the future of Rails? I don't think it'll ever go back to being the primary driver of startups, as the world has passed it by, but as I'm realizing, they probably shouldn't have. I wouldn't write a 25,000rps api in Rails, I'd use go, but for an actual app it seems like a really great way to go still.

And it's so fast to develop in. Servers might be twice the cost but realistically you gotta get pretty big for it to even matter.

I'm really curious to see how things go. I'm now back in love with my best programming friend, but I do feel like it's a somewhat dying framework. And maybe that's okay. Maybe it will be a Cobol type language where you can get paid well in it for years to come.

Even if it's glory days are past, I'm looking forward to the future, now that I know what I was missing.

Say if you wanted to work for CSX, Union Pacific, Norfolk Southern Etc. How old would you have to be.

Within the past 50 or so years, the minimum ages may have been lower like 18 or 19 years of age.

However nowadays most railway company's would require you to be a minimum of atleast 21 years of age.

Hi,

It September and I see more and more veterans losing their jobs. More juniors changing their title on LinkedIn from junior to lead. Leading what? A bunch of Agents with subscriptions? That not leadership if you are the only human in the team.

So recently I joined a company as part-time consultant because I believed a long term Ruby dev was still with them. They contacted me. I did not warn my friend because I wanted to show up as a surprise. Turn out he was let go in February.

But that not the big red flag.

The biggest red flag was that this company created a new project to upgrade from Rails 8.0 to Rails 8.2. The project is 6 months old and has 102k commits. More than rails/rails.

5 people with agents hitting the keyboard like primitive apes.

The Rails application was massive, over 400 controllers. Rails, but some engines were built in Sinatra. 2 databases, MySQL and PostgreSQL. They moved from MySQL to PG and left their 2000$ instance with old data, and it still has auth data from 2025. You can login with your actual password, or the password you set in 2025 (forever).

I spent 3 days with them, then I said that I cannot continue.

Why ? Because everything was slop. Anything you touch will break.

Some parts of the code were monkey patches of my own gems because the agents didn't read the documentation. The feature already exists, the agent was just not smart enough to find it.

That was a funny moment. Imagine maintaining a gem for years, then joining a company and discovering an AI wrote a monkey patch around your own code because nobody bothered to read the documentation. They also have 3 pagination gem, pagy, will_paginate and kaminari.

Every commit had Claude, Codex, DeepSeek, Kimi, or Antigravity.

Over 800k lines of Ruby and every comment explains to you the origin of Ruby or Rails.

"Rails 8.2 deprecated X, use this."

Im like BRO, we are in Rails 8.2. Why is this shit in the codebase ? Who is this comment even for ?

The codebase reads like 20 different developers with 20 different opinions worked on it, except most of those developers are models and none of them remember what the previous one decided. The senior operators (the humans), are taking bullshit Javascript libraries and converting them to ruby and pushing them to rubygems.

And not only that…

This company is handling medical records for a European country.

All data was accessible to everyone. Most of the other devs have less than 2 years in Ruby. They don't know the ecosystem. They changed established patterns to use ReactJS. Not even react-on-rails, they just use React with npm and created another ecosystem inside the application because apparently one ecosystem was not enough. Everyone is using whatever model they want, and the models have full access to those data.

Not only that, they hooked the platform to send webhooks to Slack, with full data.

Some of the "doctors" responding to users are just Claude or recently Gemini or that free model that openrouter said "It free, but we collecting all info"

At this point the problem is not whether Claude writes better Ruby than a junior. The problem is that nobody knows where the data goes anymore , why half the code exists, and why they keep code in the code base wrapped with `if 0`

And nobody has enough time to understand it because the agents are generating more code faster than humans can review it.

I'm not naming the company for now, but this post is a landmark i will update when everything blow up.

Also my point is that the fallout of AI-powered development is going to be big.

We spent decades trying to make software simpler. DRY, conventions, simple code, small interfaces, reusable libraries, documentation.

Then we gave developers a machine capable of generating 10000 lines per day.

102k commits in 6 months is not productivity or embracing Agentic work.

Even if you pay me thousands per day, it not fixable anymore in the normal sense. Nobody had an idea what the project was doing.

All documentation is in MD files generated alongside the code, and those files go outdated the second another agent decides to “refactor” something.

Their onboarding rules were that i use AI to read those MD files.

Before AI, when I joined a project I normally found one type of problems.

Performance problems. Bad library choices or database design. Wrong patterns. Technical debt.

Nowadays I find all of them at once. And the real management is always busy with Real life shit, or trying to install the new model that is out today.

When I saw this one, I didnt even bother telling them all the flaws. There were so many that making the list would just create another 20000 lines of Markdown for Claude to summarize.

I will update this thread with the name of the company if things blow up in the future.

I kept seeing this company post a job on RubyOnRemote for months now. The job title looks like a rendering error because they tried to be clever and write it in regex.

Noticed a "Founding Product Engineer" role. Was thinking, new year, new challenge maybe, let's give it a try.

Straight away got an email about how they are "Async first, no bs meetings". That's great, saying all the right things.

I have to complete an "async interview". Which is a 30min coding test. Ok, annoying, but whatever I'll do it anyway.

Guess what, it's a stupid JavaScript test to write a function to convert base 24 into base 10 numbers. For a "Founding Product Engineer" role. I got so annoyed looking at it. I recorded 30 min of me staring at this JavaScript code, trying to remember how to loop and split string LOL. Couldn't finish it in time.

I sent an email saying something like "I hope you don't decide based on this test" lol.

They came back and said rejected.

My question after 20 years of web development, why do these companies still do this? Not because I think experience should exempt anyone from testing, but these tests tell you absolutely nothing about whether someone can build a product. Where's the system design? The architecture discussion? Something even remotely related to the role?

It's like they've never hired anyone before and are just faking it.

What that guy did yesterday, invalidating everything the speakers at Rails World said, was one of the most ridiculous things I’ve ever witnessed in the tech world since Steve Ballmer and Bill Gates dancing on stage.

I sat front row for David's talk yesterday morning. Having talked with him the day before, I’ll admit… I wasn’t particularly surprised.

A bit of a field report from Rails World: the vibe here is far from doom and gloom. Quite the contrary. Wherever our industry is headed, most of us are still employed as menders… tending to systems that customers rely on and businesses are quite happy to keep paying for.

Most of us aren’t waking up to a blank canvas and designing the architecture of the future. We’re inheriting decisions made years ago, updating old patterns, working around constraints, and keeping this shit running reliably.

I think these newer tools give us an opportunity to wonder a little more about the systems we’ve inherited. To unpack why things work the way they do. To tinker with assumptions we haven’t had the time, confidence, or permission to revisit… and share what we learn so the next person, or agent, has an easier time.

That deployment model we picked eight years ago? Worth another look. Some of our web apps probably wish they were native apps. And there are plenty of architectural decisions we’ve been living with mostly because… well, we’ve been busy living with them.

There’s plenty of understandable anxiety about what these tools mean for our work. I’m increasingly curious about what they give us permission to revisit.

Once my keynote is published, I’ll share more about a little programming-language-adjacent framework I’ve been working on for approaching exactly this kind of curiosity.

In the meantime… keep showing up. Keep wondering.

Long live Ruby. Long live Rails.

Nice.

Taken from sf ruby meetup april meetup

https://www.youtube.com/watch?v=eqLbYCCCRO0&t=7168s

Programming beginners sometimes get stuck because they want to build great things, without dominating the basics. 

Experienced programmers, on the other hand, sometimes get bored because they are not having as much fun as they used to, and start looking for small projects.

Well…

I'm here to present to you TRMNL. A Ruby-powered e-ink dashboard we’ve been working on. (Rails + plugins + hardware = the fun side of Ruby)

Full disclaimer: I work at TRMNL. We are a small team, but I think we built something cool. TRMNL is mostly open-source and runs Ruby under the hood.

Being open-source, we pledged to keep the project alive, even if we go bankrupt (as a company). You won’t be left with a useless device you bought: https://usetrmnl.com/blog/the-unbrickable-pledge

I think TRMNL shows Ruby used in a new way. But you don't need to be a Rubyist to have fun with it – more on this below.

At its core, TRMNL is a distraction-free desk device that displays your calendar, reminders, notes, etc.

Here’s how we use Ruby:

Backend: We use Rails to power the device’s setup page (web app).

Plugins: You can write plugins in Ruby (or any language) to fetch, format, and display data—GitHub alerts, Home Assistant stats, or a countdown to your next deploy.

Plugin format: Just HTML, CSS, JS, and a JSON payload. If you can build a static web page, you can build a plugin. For more context, here's a video of someone building one using Node.Js

If you’re new to coding, TRMNL is a friendly way to write real-world code that runs on a real device.

If you’re more experienced, it’s a chance to build neat tools for any user, using any language you prefer. 

Check these examples:

https://usetrmnl.com/recipes

If you're learning to code and want to tinker with something, or you’ve been around the block and miss the fun side of programming, this could be a nice little playground. 

Here’s our open-source server client, also in Ruby (+ Hanami):

https://github.com/usetrmnl/byos_hanami

(We also have an OSS server client in Ruby + Sinatra, but the one linked above is much better)

Happy to answer any questions about how it works or where we're heading with it.

The objective of the post was to let you guys know that TRMNL exists, and since our Discord community is full of people having fun, I thought it would be interesting to you.

Since you read this far, here is a discount link – $10 – in case you are keen to check it out:

https://usetrmnl.com/go/pullrequest

(discount valid until June 1st).

Over’n’out.

Hey r/rails! I just released RubyLLM 1.0, a library that makes working with AI feel natural and Ruby-like.

While building a RAG application for business documents, I wanted an AI library that felt like Ruby: elegant, expressive, and focused on developer happiness.

What makes it different?

Beautiful interfaces

chat = RubyLLM.chat
embedding = RubyLLM.embed("Ruby is elegant")
image = RubyLLM.paint("a sunset over mountains")

Works with multiple providers through one API

# Start with GPT
chat = RubyLLM.chat(model: 'gpt-4o-mini')
# Switch to Claude? No problem
chat.with_model('claude-3-5-sonnet')

Streaming that makes sense

chat.ask "Write a story" do |chunk|
  print chunk.content  # Same chunk format for all providers
end

Rails integration that just works

class Chat < ApplicationRecord
  acts_as_chat
end

Tools without the JSON Schema pain

class Search < RubyLLM::Tool
  description "Searches our database"
  param :query, desc: "The search query"
  
  def execute(query:)
    Document.search(query).map(&:title)
  end
end

It supports vision, PDFs, audio, and more - all with minimal dependencies.

Check it out at https://github.com/crmne/ruby_llm or gem install ruby_llm

What do you think? I'd love your feedback!

That’s it. That’s the post.

Happy New Year everybody.

His claim: they completely rewrote the Hey backend in Rust, 100% vibecoded and never looked at the code, taking their servers from 110 to 10 (and a raspberry pi)

But.. Jorge Manrubia just posted a month before this declaration about using Opus to build new Rails domain entities in their Hey backend: https://www.jorgemanrubia.com/2026/08/23/oh-my-craft/

In their own benchmarks the absolute best they can get with extremely expensive models is a 53.3% success rate on features (with other models below 35%): https://rubyonrails.org/ai

Their employees are still talking about how they need to steer the tools closely, DHH is claiming it's 100% autonomous and can handle everything from architecture to implementation and you can just vibe it all.

None of this adds up.

Someday, I was watching a video about the history of Rails and, immediately, I felt the necessity of programming with it as faster as I could.

Dude, that’s simply the best thing invented by the humanity. It’s simple, elegant, beautiful, dev-friendly, I’m really passionate on it.

It was my very first time using it and I’m really excited for exploring it more and more. As a Python developer, Ruby is really easy to use and learn, and Rails give me a superpower to code any SaaS I want in less time than other frameworks.

And it gets more enjoyable after you worked with Java and Spring, configuring hexagonal architectures from scratch by hand, feeling the pain of adding dozens of boilerplates just for creating a simple controller.

I've been working with Ruby and Rails since 2006, and over the years, I’ve shipped some pretty big apps. I remember when Rails was the new hotness - new ideas, new ways of thinking. It was pretty exciting.

I’ve been diving into Hotwire recently, and... it’s kinda boring. But in the best way possible.

Most of the big problems in front-end dev feel solved (at least to me), but somehow, every other week, there’s a shiny new JS framework trying to “fix” things by reinventing some kind of wheel. (Lisp folks, please feel free to point fingers at us Rubyists here…)

This stuff absolutely should be boring by now. I shouldn’t need fifty MB of node_modules just to get a basic search form going.

Anyone else finding a bit of boring simplicity is exactly what they want these days?

👋 Hi all,

I've been busy the past few days building a new Rails gem, called ActiveJobTracker, to make tracking background jobs in ActiveJob easier to manage.

If you've ever needed job tracking in Rails, check this out. I'd love to hear your thoughts.

Basically this is what it does:

Seeing how far your CSV upload, data import/export, or report generation is in a long running job should be intuitive, but there doesn't seem to be an easy plugin solution where you can see the progress or what went wrong.

With this gem you get:

• Persisted job state in a database.

• Optional thread-safe write-behind caching so that you don't hammer your database.

• Tracking job statuses (queued, running, completed, failed) and their timing

• Automatic error logging when a job fails

• Useful helpers like progress_ratio and duration

• Plug and play with minimal setup

• Backend independence (works with Sidekiq, Delayed Job, etc)

Please let me know what you think.