For over a decade, the Ruby community has lived by a sacred mantra: "There's a gem for that."
Need to format a phone number? Gem.
Need to handle a specific API integration? Gem.
Need to generate a slug? Gem.
For a long time, this was our superpower. It allowed us to build products faster than anyone else. But recently, I’ve started to feel a shift. A hot take, if you will:
The Gem Era is over.
Here is why I think the "time trade-off" has officially flipped, and why I’m looking at my Gemfile with a lot more suspicion these days.
The Old Trade-Off
In the past, the math was simple. Writing a feature yourself took 4 hours. Installing a gem took 10 minutes. Even if the gem was heavy, the time saved was worth the technical debt.
But we all know the reality of that debt:
- Bloat: You import a library with 50 features just to use one.
- Dependency Hell: One gem requires
json > 2.0, the other requiresjson < 2.0. - The "Friday Night" Break: You run
bundle updateand suddenly production is down because a minor version change deprecated a method you didn't even know you were using.
The AI Shift
Enter the LLM.
Today, if I need a specific piece of functionality—say, a service object to sanitize and format user inputs—I don't search RubyGems. I ask the AI.
In seconds, I get an implementation that is:
- Bespoke: It does exactly what I need, and nothing I don't.
- Zero-Dependency: It’s standard library Ruby. No external requirements.
- Owned: I own the code. If it breaks, I fix it. I don't wait for a maintainer to merge a PR.
"Don't Reinvent the Wheel" is Dead
We were taught not to reinvent the wheel because wheel-making is hard and error-prone. But what if you could snap your fingers and have a perfect, custom wheel materialize in front of you?
The friction of writing utility code has vanished.
If I use a gem, I am outsourcing the maintenance of that logic to a stranger. If I use AI to generate the code, I am "vendoring" the logic immediately.
The time trade-off just flipped.
It is now often faster to prompt, review, and commit a 50-line class than it is to find a gem, read the documentation, configure the initializer, and deal with the eventual dependabot alerts.
The Nuance (Before you roast me in the comments)
Am I saying we should uninstall Devise, Sidekiq, or Rails? Absolutely not.
Please, do not ask ChatGPT to write your crypto implementation or your OAuth handshake from scratch. Security-critical, massive-complexity problems still require battle-tested community solutions.
However, the "middle class" of gems is dying.
- The API wrappers.
- The simple formatters.
- The purely logic-based utilities.
These are no longer assets; they are liabilities. They are potential supply chain attack vectors and maintenance burdens.
The Verdict
We are moving from an era of "Assemblers" (gluing together black boxes) to an era of "Architects" (owning the logic, but accelerating the writing process).
Next time you reach for a gem to do something simple, ask yourself: Do I really want to marry this dependency? Or can I just build it myself in 2 minutes?
What do you think? Are you shrinking your Gemfiles, or is "roll your own" still a recipe for disaster? Change my mind below. 👇
Top comments (1)
We don't use gems because we are lazy. We use gems because they encode hard-won patterns, social contracts, and failure modes you only discover after years of production pain.
Yes, AI can spit out a 50-line utility in 10 seconds. That’s not the flex you think it is. i can spit 10m LOC by using git clone.
What you are really doing is outsourcing architecture to a stochastic parrot and then pretending you 'own the code' because it lives in your repo.
Ownership isn't file custody, it understanding why the pattern exists and how it fails.
If you want file ownership, vendor it or use a proxy like Vein.
Here is the part everyone hand-waves away:
AI-generated code is locally optimal and globally naive.
It will:
• Hardcode assumptions you didnt notice (
claude_2024_change_meas debug password)• Reimplement half a gem… badly
• Ignore edge cases the ecosystem already solved in 2016, because it assume you deploying in AWS
You can slop your way forward for a year, maybe two. Then your architecture starts to rot in weird, non-obvious ways. You can't hire or get help from anyone because you build you own ecosystem that nobody use, and no LLM trained on.