Rails World 2026: Harnesses, agents, and why human judgment matters more than ever

Five of us from Telos went to Rails World this year. Arely Rivera and Alicia Rojas gave a talk on how a designer on our team ships production Rails. Luigi Rojas, Moises Montaño, and Fernanda Sánchez spent the conference in the audience, taking notes on what the rest of the Rails community is working out.

AI has made writing code cheap. At Rails World 2026, the teams getting ahead were spending their effort on what surrounds the code: guardrails and structure, plus the human judgment to decide what gets built.

Harness engineering is the new craft

We heard “harness” in nearly every room. A harness is the set of rules, checks, and feedback loops that keep an AI agent on track, so its output follows your conventions instead of drifting.

Luigi’s favorite talk was Joël Quenneville’s Harness Engineering on Rails. Every developer is reworking how they write code right now, and he wanted principles to build on. Quenneville argued against “prompt and pray,” and against developers acting as a “meat proxy” who copy output back and forth for their agents. His distinctions between feed-forward and feedback controls, and between computational and inferential checks, gave Luigi a framework he’s already using every day.

Arely heard the same thing in the UI guardrails talks. Her takeaway was clear: an agent treats a README-style guideline as a suggestion. If a rule matters, the system has to enforce it.

Split big prompts into focused agents

Fernanda’s pick was Agents on Rails: Building AI Pipelines in plain Ruby. She liked that it used agents to improve the product for end users, beyond writing code. In the example, agents read a user’s existing data and generate personalized dashboard tiles, so the app changes based on what each person actually does.

The key design choice was giving each agent one clear job instead of asking a single prompt to do everything. Recommendations got more accurate, with fewer hallucinations and less evaluation bias.

We’ve seen the opposite on a fintech product we support. Its in-app assistant runs on one large prompt that covers formatting, available content, blocked content, tone, and styling. As the prompt grew, the model started ignoring rules, and some rules overlapped or contradicted each other without anyone noticing. We’re now looking at splitting those responsibilities into dedicated agents.

Designers belong in the repo, with onboarding

Arely and Alicia’s talk, Layered Design, Layered Trust: How a Designer Started Shipping Production Rails, covered how Arely went from handing off Figma files to opening pull requests, and the harness that makes AI-generated UI follow our design system.

Most of the questions were practical: the terminal, local environments, branches, PRs, and where Figma fits. Developers liked the idea of giving designers repo access. Arely’s point was that a lot of what developers consider basic is new to designers. They need onboarding, guardrails, and time to learn the workflow before access is useful.

The harness itself got the most technical questions. People wanted to know how to keep agents from drifting and how to make generated UI stick to a design system. Many attendees had the same problems: inconsistent UI, design drift, and a lot of back-and-forth. One designer working on a similar Rails UI problem came up afterward and said, “Wow, you figured it out.”

The insight that got the strongest reaction: “Repetitive is not the same as good. We still need someone to determine what’s worth being repeated.”

Cheaper execution makes judgment worth more

We heard this idea all week: AI makes execution cheaper, and that raises the value of human judgment.

Moises’s favorite session was the conversation between Matz, DHH, and Jeremy Daer on Ruby, Rails, and the future of programming. Matz and DHH have very different personalities, and they’ve ended up working with AI in similar ways. Both still talk about purpose and enjoying the work. Moises came away thinking about ego-less code, where you don’t get attached to what you wrote. He also liked their call for better science fiction, meaning more hopeful pictures of where this is all going. Joy, motivation, and freedom are the values behind Ruby and Rails, and they’ll still matter even if the language or framework someday doesn’t.

Alicia’s pick was Aaron Patterson’s closing keynote. The first half went deep on Ractors. The second half walked through the RubyGems supply-chain attack from earlier this year, which she found a little scary and also empowering. Other talks suggested developers barely need to look at code anymore. Here was one of Ruby’s best-known engineers digging into low-level Ruby and showing why that knowledge still matters.

Alicia put it this way: “Some think AI makes using your intelligence optional. I feel it makes it non-negotiable, now more than ever.” She wants to understand the code even when she didn’t write it, and even when her agent reviews it and catches bugs she’d miss.

What we’re bringing back to Telos

Moises said the reassuring part was that a week with the people doing the most advanced work didn’t make us feel behind. Our job now is to be more deliberate about what we already do.

• A harness on every project. This was Arely’s suggestion, and the simplest one. Luigi sees it as the way to move fast with agents and still know exactly what’s being automated.
• Focused agents instead of one big prompt. We’ll start with user-facing assistants and dashboards, where a single overloaded prompt is already causing problems.
• Proper onboarding for designers in the repo. Access plus training, guardrails, and time, so designers can ship UI directly without guessing.
• Tools that work for agents and humans. Moises flagged this, along with security, as the next big area for the industry.
• Understanding the code. Agents write more of it every month. Our people still need to know what it does and why.

What does this mean if you run a business?

This applies even if you never watch a Rails talk. If your company builds custom software with AI involved, you can build fast now. What’s still hard is making sure the software is consistent and secure, and that it fits how your business runs. That takes a harness, clear jobs for the agents doing the work, and people with the judgment to decide what’s worth building.

That’s how we run every engagement at Telos. We start with a Strategic Assessment that identifies where custom software will make a real difference before anything gets built. If that sounds useful, let’s talk.