Jason Arbon

I love Rails. I've built my wealth on it. That's exactly why I think we need to have an honest conversation about its biggest blind spot. Eileen M. U. gave a brilliant talk at Rails World last year: "The Myth of the Modular Monolith." After 6 years of modularizing Shopify's monolith, she concluded: "You can't solve human and cultural problems by changing your architecture." She's right kinda of about the culture part. But stopped one step short. Rails doesn't just allow tight coupling. It incentivizes it. ActiveRecord makes every model globally accessible from anywhere. Any controller, any model, any job can reach into any table through any association chain. There's no boundary enforcement. No import restriction. No compilation step that says "this module shouldn't know about that one." When your framework makes coupling the path of least resistance, blaming developers for coupled code is like blaming water for flowing downhill. Shopify tried to fix this with Packwerk. It just give you a map not a real solution. Rails Engines? Been there, done that. They are miniature apps that provide functionality to their host applications. They don't enforce real isolation and they weren't designed for progressive extraction. But this isn't a Rails problem. It's a missing tool problem. Look at what Nx did for the Node/TypeScript ecosystem: → Module boundaries enforced at the import level, not via YAML to-do lists → Dependency graph visualization built in → Affected-only CI: only test what actually changed → Clear public API per module, everything else is private by default → A real path from monorepo module to extracted service Nx didn't replace Node. It gave Node developers the guardrails to build modular systems naturally. The right thing became the easy thing. By default. Rails deserves the same. Imagine a Rails-native tool that: • Enforces module boundaries through autoload paths, not opt-in linting • Gives each module a public API (explicit exports) while keeping internals private • Generates a live dependency graph from actual code usage, not manual YAML declarations • Runs affected-only CI based on that graph Not a replacement for Rails. A companion that makes Rails' conventions work at scale. Eileen is right: culture matters. Education matters. Leadership incentives matter. But culture alone didn't give us CI/CD. Tools did. Culture alone didn't give us code formatting standards. Linters did. Culture alone won't give us modular Rails applications. Rails gave us developer happiness for building products. Now we need the same philosophy applied to building organizations of code. The myth isn't the modular monolith. The myth is that we have the right tools for one. Who's building this? 🎥 Eileen Uchitelle — "The Myth of the Modular Monolith" (Rails World 2024) https://lnkd.in/dabvzHQm

13

I'm incredibly excited for this talk. Top K queries are the backbone of search engines, which have historically been NoSQL databases unable to execute JOINs. We're fixing this with ParadeDB. Highly recommend attending, I promise you'll learn something!

36

I've just published a MailChannels skill for OpenClaw (formerly Clawdbot, then briefly Moltbot). If you have a MailChannels Email API account (signup here: https://lnkd.in/g9e6mzc3), add this skill to OpenClaw and you can start automating email workflows using OpenClaw. And no, we aren't afraid that spammers will sign up. New sources of email abuse emerge thousands of times a day across the hundreds of web hosting providers who use us to send email from their hosting infrastructure. MailChannels is the only email delivery service architected to safely deliver email from uncapped agents like OpenClaw.

19

2 Comments

uncannyuse now has schema pages for Reality Composer Pro components—showing the exact USDA block RCP writes, field-by-field with types and sparse-authoring behavior, plus annotated fixture examples. 20 components covered so far. https://lnkd.in/dpsT2A-8

9

Pretraining vs RL investments is likely to change and models could do one day’s worth of complex software development work in 2026 - Anthropic team https://lnkd.in/gYhCNxyR

1

Garry Tan, president and CEO of Y Combinator, recently posted about why Ruby on Rails plus Claude Code is a "crazy unlock." Rails is designed around strong conventions, predictable patterns and expressive DSLs. That combination means an LLM has far less ambiguity to fight through before it can be useful. As he put it: "Rails was designed for people who love syntactic sugar, and LLMs are sugar fiends." And it got me thinking about Django. Django has some convention. The framework will tell you roughly where your models and views and URLs live. What it won't tell you is where your business logic goes. Or how your views and models should be structured. Those questions get answered differently by every team, in every project. The thing about those decisions is that you don't really know if they were good ones until years later. A pattern can feel perfectly sensible in year one and leave you maintaining a small archaeology project by year five. That experience is what pushed me to write Django RAPID Architecture. RAPID adds convention where Django leaves things unsaid. It gives you a clear horizontal structure: data, interfaces, readers, actions. It makes it obvious where different kinds of code belong. And with django-readers, the specs layer gives you a compact, expressive way to describe what data a view needs and how it should be shaped: something close to a DSL. Well, it turns out that Garry was right. When the codebase has already made the structural decisions, a model doesn't have to reverse-engineer your team's habits before it can be useful. With a bit of guidance, the shape of the thing is immediately visible. And LLMs love it. I've seen agents one-shot large, complex features, and the code is exactly as I would've written it. That's the deeper point in Garry's post. It's not really about Rails specifically. The most AI-native codebases are the ones that are already legible, where the important decisions have been baked into the structure itself. So RAPID isn't just for humans, it's for agents too. If you want help moving your Django codebase in the direction of these huge AI productivity gains, get in touch: https://lnkd.in/eiRtAepq And if you just want to learn more about RAPID: https://lnkd.in/ejkF7DMB

100

18 Comments