The 
Tropical on Rails 2026 returned for its fifth edition, bringing together around 700 Rails developers from across Brazil and beyond for two days of talks, workshops, and conversation in São Paulo. As always, the conference paired deep technical content with the warmth and energy that make the Brazilian Rails community so special.
As an engineer at Planet Argon, attending again this year was a chance to take the pulse of where Rails is heading, and one theme was impossible to miss. The conversation has clearly shifted from "will AI replace developers?" to "how do we work alongside AI without wrecking our codebases?" That shift in maturity is what I most want to share here.
In this post, I'll recap the event, walk through a few of my favorite talks, and reflect on how these ideas are already shaping the way we think about building and maintaining Rails applications at Planet Argon.
Overview of Tropical on Rails 2026
Held on April 9–10 at the Pullman in Vila Olímpia, São Paulo, this year's edition gathered a diverse community of developers, speakers, and companies for two days of knowledge sharing and connection. Beyond the scheduled sessions, the hallway conversations and informal meetups were, as usual, half the value of being there.
Across the 20 talks, a clear through-line emerged: AI-assisted development is growing up. Instead of the tired doom-and-gloom narrative of replacement, speakers focused on the discipline, architecture, and tooling that make agents genuinely useful. The recurring conclusion was reassuring for anyone who cares about craft: the fundamentals of software engineering matter more than ever, not less.
Key Takeaways from Sessions and Workshops
Minha Experiência com Agile Vibe Coding: Fabio Akita
Akita's keynote tackled the AI panic head-on, and his central framing stuck with me:
AI is a mirror and an accelerator—it makes a great developer 10x faster, and a careless one 10x messier.
If you're a strong engineer, AI can multiply your output; if you write poor code, it will generate bad code and technical debt at exactly the same speed.
Akita then took aim at a popular misconception. Many developers believe they can do "spec-driven development" by writing one massive specification file and expecting the AI to build the entire system perfectly in a single shot. He strongly advises against this: it simply doesn't work, wastes the model's context window, and produces confusing, contradictory instructions.
His alternative is PILOTA, an iterative, step-by-step method for what he calls Agile Vibe Coding. The acronym is in Portuguese, but it maps cleanly to English:
- Planejar — Plan
- Investigar — Investigate
- Lapidar — Refine / Polish
- Operar — Operate
- Testar — Test
- Ajustar — Adjust
The mindset behind it is to treat the AI like a junior programmer while you act as the manager or senior mentor. Rather than handing over a full spec upfront and hoping for the best, you constantly evaluate its work one step at a time: you ask it to run tests (coverage tools, linters), you review the execution chain, and you continuously adjust its instructions based on the errors it makes. It's the opposite of "fire and forget"- it's deliberate, hands-on guidance.
One practical note resonated with me: don't try to save money on cheap models that lack strong thinking (reasoning) and tool-calling capabilities. When quality and speed matter, spend on frontier models. The deeper takeaway, though, was a vindication of the basics- TDD, refactoring, and constant code review have never been more essential.
Your Views Deserve a Grammar: Marco Roth
Marco addressed a pain the Ruby community has lived with for years: the view layer (HTML + ERB) never had the editor tooling, linters, formatters, autocomplete, that the JavaScript ecosystem takes for granted. The root cause was the absence of a formal grammar capable of understanding HTML and ERB simultaneously, without losing the context of one inside the other.
His answer is Herb, a parser and complete toolchain built on top of Ruby 3.4's new Prism parser. The Developer Experience gains are immediate and tangible: precise in-editor errors when you forget to close an end in Ruby or a tag in HTML, intelligent linting, and automatic formatting.
He also offered a glimpse of the future with the Herb Diffing Engine, a technology aimed at bringing real reactivity to Hotwire, much like Phoenix LiveView, with partial DOM updates and hot reloading during development, all without recharging the page or migrating to a Single Page Application. It's the kind of tooling leap that closes the front-end gap while keeping the full-stack "magic" that makes Rails Rails.
From One to Two — Scaling Rails Apps: Vladimir Dementyev
Vladimir reached for a space-exploration metaphor to explain the startup life cycle. Point One is launch- getting the satellite into orbit, and Rails is unbeatable at that early speed. The real challenge is Point Two: putting a human in space and bringing them safely back, which translates to scaling sustainably with real users, a growing team, and ongoing maintenance.
To frame this, he introduced Software Product Fit (SPF): your codebase's ability to adapt to the product's growing demands. When the product outgrows the maturity of the code, friction rises, and value delivery slows down.
His AI tie-in was, for me, the sharpest of the conference. He described AI as an amplifier, a "loot box." Without clear architectural patterns, AI will turn your system into unmaintainable chaos remarkably fast. But with solid conventions in place (his example was extracting filter logic out of controllers into dedicated Filter Objects), the architecture acts as an implicit harness that guides the AI to generate the right code in the right layer, with far fewer errors and hallucinations.
Chatting with the Community
One of the most rewarding parts of Tropical on Rails is always the people. I had great conversations about agent-assisted workflows, view-layer tooling, and the very real trade-offs of letting AI into a mature codebase. There's something energizing about being surrounded by developers who genuinely love the framework and are eager to swap war stories and ideas.
I also got to chat with folks curious about Planet Argon's approach to legacy and long-lived Rails apps- a topic that felt especially timely given how much of the conference circled back to maintainability and architecture. A few of those conversations may well turn into exciting collaborations down the road.
What This Means for Us at Planet Argon
The insights I gathered are already sparking ideas back at Planet Argon:
- Inspired by Akita's talk, we're being more intentional about how we fold agents into our day-to-day work, leaning on frontier models for non-trivial tasks and doubling down on fundamentals (tests, refactoring, review) as the guardrails that keep AI output trustworthy.
- Vladimir's "architecture as a harness" idea maps almost perfectly onto maintenance work. The stronger and clearer our conventions are in the apps we maintain, the safer it is to let AI assist on them so we'll keep investing in extracting clear, well-named objects that point both humans and agents to the right layer.
- And we'll be keeping a close eye on Herb. Better linting and formatting for the view layer is a genuine DX win, and the Diffing Engine is worth watching for client projects that want reactivity without the full SPA commitment.
Wrapping Up
Tropical on Rails 2026 reminded me, once again, why I love this community: the blend of technical depth, real-world wisdom, and human connection. This year, that came wrapped in a refreshingly grown-up take on AI- not as a replacement for developers, but as a tool that rewards the engineers who already care about doing things well.
If you ever get the chance to attend, I highly recommend it. And if any of these topics caught your interest or you just want to talk Rails, drop me a line!
🌴 Until next year!