Why Rails Conventions Make AI Coding Work Better
By Armando J. Perez-Carreno · Featuring Benito Serna
I talked with Benito Serna, CTO of Brick, about why a framework that reads like plain English plays so well with LLMs, how his team writes 80% of its code with AI and still reviews every line, and why building lean beats building everything up front.
If your codebase follows a clear, predictable shape, an AI model has a much easier time helping you. Benito Serna, CTO of Brick, builds on Ruby on Rails, a framework where every project puts the same kind of file in the same place. That convention is exactly what makes LLMs work well with it. The model already knows where things go, so it spends less time guessing and more time being useful.
In this episode, I talked with Benito Serna, CTO at Brick, a real estate crowdfunding platform out of Mexico. I've known Benito for years, going back to the college music scene, and he turned out to be as good at software as he is at music. Brick is a small company, fewer than 30 people, and it started as a side business inside Inku, a Rails shop that also spun off companies like Aventones (carpooling before Uber) and Reservamos. Benito has been programming in Rails for more than 12 years.
The part of his story I want every founder to hear is how Brick started. The first version was a website where the progress bar on each campaign was updated by hand. Someone behind the scenes changed the number, then pushed a deploy to update the page. There was no system to count investments automatically. And it worked. As Benito put it, who cares if a person or a computer updates the bar? The investors just want to see the progress. They proved the concept first, then invested in the real product. A lot of people get trapped building the whole back end before they've checked that anyone wants the thing.
We spent a good chunk of time on why Benito loves Rails, and his answer was about how it reads. Ruby looks like pseudocode, close to plain English. I was looking at some on my screen during the call, lines like "post has many comments" and "comment belongs to post," and even though I've never written Rails, I understood it. The creator of Ruby, Matz, designed it for programmer happiness, so the people who read and write the code feel good doing it. That readability is the whole point.
Here's where it connects to AI. Rails ships with conventions that almost every project follows. You get models, views, and controllers, with Active Record for the database and Solid Queue for background jobs, plus a generator that scaffolds your sign-in flow. Because everything has the same shape, an LLM can see where a piece of logic belongs without you explaining your whole architecture. Benito made a sharp point about this. The models have their own conventions from training, and those aren't always the best ones. So we as engineers need to set our own conventions, the patterns we trust, and let the tools assemble code inside them.
At Brick, more than 80% of the code is now written by AI. Every bit of it gets reviewed, both with AI and by a person. Each engineer takes a project for one to three weeks, breaks it into tasks, and opens pull requests. They have a review skill in their editor that flags what could break, what's risky, and what can wait until later. The tools they use change month to month. Cursor, Claude Code, Codex, open code. The process around them stays steady, and that's what makes the output repeatable.
The debugging story stuck with me. A while back, Brick had a one peso mismatch between their bank concentrator account and their internal accounts. That kind of bug is brutal to chase by hand. Benito chatted through the problem with Claude, had it build a script to dump one giant CSV, then a second pass to reshape the output so the mismatch jumped out. Work that might have taken a full day got done in under half an hour. Before AI, you wouldn't build a custom dashboard to find a one peso bug. It made no sense. Now you can, and it does.
For folks who aren't engineers, Benito's advice was refreshingly small. Ask the AI for one HTML file, plain JavaScript and CSS, no React, no framework. You'll get something usable for a report, a CSV viewer, or a small tool you run every day. The model stays on track when the scope is tight. Push past 20 messages on something complex and it starts building things you didn't ask for. Start small, learn a little about how the pieces work, then reach for something like Rails when you're ready to grow.
At the end of the day, the lesson from Brick is about discipline. Prove the idea before you build the machine. The team picks conventions they trust and lets AI work inside them, and a human still reviews every line. The tools are getting better fast, and that's a lot of fun, but the wins still come from people who know what good looks like and set things up so the AI can hit it.