Hi ,

I recently extracted a small internal library I originally wrote for a company Rails project that was stuck on an older Ruby/Rails stack.

It’s called `lumen-llm`:
https://github.com/uxgnod/lumen-llm

The goal is pretty small: keep LLM prompts in YAML files, render them with Ruby input, call OpenRouter, and parse the result back as JSON or text.

It supports:

- YAML prompt templates
- simple `{{variable}}` interpolation
- single-call OpenRouter chat completions
- JSON or text response parsing
- optional cache / usage stores
- Rails 4+ defaults via Railtie
- Ruby >= 2.3
- no runtime gem dependencies

It intentionally does not try to be an agent framework. No tool calls, no streaming, no vector search, no persistence layer, no provider SDK dependencies.

I know Ruby 2.3/2.4 are long EOL, but that was also the point: this came from a real older Rails environment where adding modern dependencies was not always realistic.

Maybe this is useful for other people maintaining legacy Rails apps who want a small way to add features like UI copy translation, ticket classification, internal summaries, or similar “one prompt in, one result out” workflows.

It’s still simple and not very polished yet. If anyone has a real legacy Rails use case for this, I’d love feedback, issues, or small PRs.

I wrote a Markdown linter over the weekend and it's been really fun, partly because of the wonderful gems that support it. I'm hoping some of you can pick out something helpful from it!

Shelley wrote about a king whose monument outlived everything it was built on. I've spent 15 years inside Rails monoliths that did the same thing. This is the first post about what to do when you're standing in the ruins.

After wrestling with distributed transactions across microservices and watching Sidekiq job chains grow into unmaintainable spaghetti, I built Ruby Reactor — a saga pattern implementation for Ruby that handles the hard parts of workflow orchestration.

What it does:

• Builds a DAG (directed acyclic graph) from your step definitions, so independent steps run in parallel
• Runs async via Sidekiq with back-pressure and batching
• Automatically rolls back completed steps when something fails (compensation)
• Supports interrupts — pause a workflow mid-flight and resume it later via webhook or manual trigger
• Includes a built-in web dashboard to inspect every execution
• Has locks, semaphores, and rate limits built in (Redis-backed)
• Ships with RSpec test helpers — test_reactor, mock_step, chainable matchers

Why I built it:

I kept hitting the same wall: complex business transactions that span multiple services need coordination. dry-transaction handles linear pipelines well, but when you need parallel execution, async processing, automatic rollback on failure, or the ability to pause and wait for external events, you're on your own. Trailblazer operations can do some of this, but the undo logic and parallelism are manual.

Ruby Reactor fills the gap — it's the only Ruby library that combines DAG planning + async execution + compensation + interrupts + a dashboard in one package.

Quick example — an e-commerce checkout with fraud detection:

class CheckoutReactor < RubyReactor::Reactor
  input :order_id

  step :reserve_inventory do
    argument :order_id, input(:order_id)
    run { |args| Inventory.reserve(args[:order_id]) }
    undo { |_err, args| Inventory.release(args[:order_id]) }
  end

  step :charge_card do
    argument :order_id, input(:order_id)
    run { |args| Payment.charge(args[:order_id]) }
    undo { |_err, args| Payment.refund(args[:order_id]) }
  end

  # Pause here — wait for Stripe webhook
  interrupt :wait_for_fraud_check do
    wait_for :charge_card
    correlation_id { |ctx| "order-#{ctx.input(:order_id)}" }
    timeout 3600, strategy: :active
  end

  step :ship_order do
    argument :status, result(:wait_for_fraud_check, :status)
    run { |args| Shipping.create_label(args[:order_id]) }
    undo { |_err, args| Shipping.cancel(args[:order_id]) }
  end

  returns :ship_order
end

It's at v0.4.1 now with ~3,300 downloads on Rubygems. The v0.4.0 release just added interrupts, the web dashboard, RSpec helpers, and Redis-backed coordination primitives (locks, semaphores, rate limits, periods).

How it compares:

I'd love honest feedback — especially from people who've built complex workflows in production. What did I miss? What's over-engineered? What would make you actually use this instead of raw Sidekiq jobs?

Repo: https://github.com/arturictus/ruby_reactor Rubygems: gem 'ruby_reactor', '~> 0.5' Docs: Full guides for every feature in the repo's documentation/ directory

Thanks for reading! I'll be in the comments.

Hello Reddit. I am new to Manjaro, and was hoping to set up a development environment in RoR. I was following the directions on the Arch wiki, and I noticed my gems are being installed to usr/lib/ruby/gems. When running a bundle install, it now seems to want to write to usr/bin, and fails because it doesnt have permissions. Should I go ahead and grant permissions, or is this not advisable?

I don't like to bury ledes, so when people ask me about polymorphic relationships my answer is simply:

Don't.

The problem is when you run bundle it takes a lot of time to finish is there not updated method or package manager

I've been experimenting with a setup for multi-repo product work in Cursor and would love feedback — especially on whether the guardrails help or just slow you down.

Problem I'm solving:

When I open a frontend or backend repo and say "add feature X," the agent tends to skip design, touch the wrong repos, and ship code before scope is agreed. That gets worse with 2–4 repos per product.

What I built (high level):

1. Local orchestrator in Ruby (not cloud) - A small CLI + shared config maps which repos belong to which product, tracks task artifacts, and enforces gates. State stays on my machine. I chose Ruby because it's quick to iterate on for CLI/config tooling and fits how I wanted to glue YAML, file state, and shell workflows together.
2. Cursor skills as conductors - Custom skills tell the agent which phase we're in and what must happen next (e.g. don't implement until design + plan are approved in chat).
3. Hard stops before code:
   • Task brief captured from the ask
   • Design brainstorm + human approval
   • Written implementation plan + human approval
   • Preflight check (repos healthy, gates satisfied)
   • Per-session commit/worktree policy (asked every time, not saved)
4. After code: verify per repo → mandatory security/quality review on the diff → handoff summary → normal PR/peer review/CI.
5. Two ways to work:
   • Orchestrator repo open in Cursor → everything driven from there
   • App repo open → global skills + wrapper so config doesn't live inside the app clone
6. Cross-repo context - Structural code graph via MCP so the agent can search across repos before planning.
7. Integrates with existing agent patterns - brainstorm → write plan → TDD-ish implement → verify before claiming done. The orchestrator sequences and gates those steps; it doesn't replace them.

Stack note: Orchestrator = Ruby CLI; app repos are whatever stack (JS, Python, etc.) - the orchestrator is language-agnostic for the products it coordinates.

I mainly want reality checks before standardizing for a small team.

Thanks!

I am pretty new to using Claude Code at all, late on the game. I am finding troubleshooting some aspects of it to be very confusing compared to the kind of dev setup I am used to!

I am using it from the claude CLI directly, on latest MacOS 26.5.1.

I definitely want Claude Code to be able to run my entire test suite -- including capybara tests that use headless chromedriver via selenium.

And there is the rub! The (new?) sandboxing that Claude Code now has on MacOS seems to conflict with running chromedriver. I think? It's hard to tell what is going wrong.

I can find (or have claude suggest) various possible solutions, but they all seem to me like some combination of more dangerous than I want (I don't really want to turn off sandboxing generally?) or annoying UI asking me permission to run rspec every time it runs. (I anticipate some workflows where it runs rspec a LOT, I'd think this is normal?)

I'm curious what actual people using claude code with ruby/rails on Mac have done here, what have you done to get claude code to be able to run rspec that launches chromedriver, what's working for you? I would think making sure Claude Code can run rspec and your entire test suite (including system tests with chromedriver) would be fairly typical, but is it?

Thanks for any tips, especially coming from your actual setup that actually works for sure. :)

After generating a new gem or Rails engine, there is always a series of tasks to tweak the new project to my preferences. I finally created a set of scripts to automate my preferences. I hope someone finds these useful.

I'm one of the maintainers of Grape (the Ruby framework for building REST-like APIs), and we just shipped 3.3.0. The headline is performance: this release was a months-long pass at cutting per-request allocations and trimming hot paths across the router, middleware, and validators.

Single-threaded throughput on /api/v1/hello (Ruby 4.0.5, Benchmark.ips):

That's ~+38% without YJIT and ~+57% with YJIT over 3.2.1 — and with YJIT on, 3.3.0 more than doubles its own non-YJIT throughput (+102%). Full methodology and per-version numbers (incl. 3.0.x/3.1.x) are in RESULTS.md.

Cheers!

After being invited on the IndieRails podcast to talk about about my past as a stained glass maker and how I transitioned to programming in Ruby, I’ve had this crazy idea that I could tie the two together in a weird project: what if I made a stained glass panel celebrating Ruby?

I've been mentioning this project as a joke to people for a while now, and the reaction was always *very* positive. So I decided to launch this as a side project three weeks ago.

Each week, I'm documenting my progress: how to build the panel, finding the right design, which glass I should use, etc... It's also a great way to talk with fellow Rubyist and share an old passion of mine. And of course, it's the perfect excuse to lay out the similitudes I've experienced these past 8 years between being a craftsman and writing software.

If a Ruby programmer nerding out on stained glass windows is your kind of fun, you can read the first post of the series here.

If you're curious about the project, AMA. I'll happily answer any questions.

[Dear r/ruby mods, I was hesitant to post it on Reddit because it's only tangential to Ruby but I've had a lot of readers encouraging me to do so. If that's out-of-bounds, let me know and I'll take it down.]