One of the biggest surprises of this edition was how many talks touched on the use of AI, directly or indirectly, an interesting contrast with last year's focus. But above the hype, one point had everyone agreeing: software engineering is not going away. If anything, it will be needed more than ever.
If our role is safe, the real disagreement in the community is about how to use AI day to day. The debate split along a dilemma of control: micromanaging the AI (as a strict code producer) versus macromanaging it (treating it as a junior dev with more autonomy, where we act as guides and set the boundaries).
At the event, two references illustrated those two paths perfectly: Rodrigo Serradura's project and Fabio Akita's insane productivity. It gets clear once you look at their careers and where each philosophy came from.
1. Micromanagement (The Serradura View)
Working as a Principal Engineer and with a long history of debating architecture and design patterns in the community, Serradura argues for a structured approach. The focus here is micromanaging the code, isolating layers, and the long-term ownership of a product.
That organization built up over the years (in processes, documentation, and architectural standards) is exactly what brings companies predictability and sustainable growth, and it shields the code against staff turnover. Drop AI into a setup like that and it practically gains a superpower. You can see this in benchmarks like AutoCodeBench, where Elixir, for example, hits around an 82% success rate against a general average of 50%. That comes from the "one obvious way" philosophy and the functional paradigm, which drastically cut the amount of context the AI needs to understand.
The "A-ha! Moment" of his talk landed when he put up the diagram of how his architecture evolved. The slide showed rigorous separation of concerns across the branches, paired with quality metrics measured relentlessly by Rubycritic:
- Family 1-2: Controller Architecture
- Family 3: Domain Structure
- Family 4: Entry Point Separation
- Family 5: Model Authority
- Family 6: Domain Naming
- Family 7: Bounded Contexts
Diagram of the architecture evolution and quality metrics.
Bringing that discipline and those tight boundaries into any language hugely increases how effective AI can be for a company over the long run.
More on Serradura's view in his project: railswhey/app
2. Macromanagement (The Akita View)
On the other side, Akita brings the perspective of a founder and director of the consultancy Codeminer 42. In the consulting world, what rules is solving the client's pain, so the focus sits on delivering value and on the metric that was contracted.
In that philosophy, technology and programming are aimed at and measured by ROI. Business and product walk side by side with the code. It is the perfect environment to hand more context to the AI and macromanage it, focused on delivering the final value to the user. It is close to what we have watched in the big successes of initiatives like OpenClaw, and to the line of thinking Anthropic itself let slip when Claude Code leaked.
For Akita, the paradigm break peaked in the slide where he showed the project board from his two-month "marathon": 8 projects built and shipped in record time using AI.
Eight projects shipped in record time with the help of AI.
How is that possible? He explained it in another stretch of the talk focused on "accepting imperfection". When the cost of generating code drops that hard thanks to agents, being wrong gets cheap. Several practical examples made it clear that iteration picks up so much speed that fixing failures no longer creates the bottleneck it used to, and that is what sustains insanely fast and continuous delivery.
Accepting imperfection: the speed of the fix beats the cost of the mistake.
More on the "Akita way": VS Code is the new punch card
Which Path Is Best?
We are only at the start of this wave, and all of us need to mature and work out the right route, if there even is a single one. Personally, largely because my career has similarities with Serradura's trajectory, I tend to follow the path focused on micromanagement and on stricter code fundamentals.
But let's be honest about the environment around us. The Ruby ecosystem has breathed the "Convention Over Configuration" motto of Rails culture since it was conceived. That community preference for pragmatism and speed suggests the general mood will lean more toward Akita's side.
No More Room for the Dev Fauna
Whichever path we use to get to production, whether we are sculpting architectures or marathoning deploys, we are seeing a clear warning for a portion of devs.
The era of what we used to call "dev fauna"2 or the "bad programmer"3 has ended. There is no more room in the market for people who survive by writing CRUD or by holding a monopoly over parts of the system. Coasting is now a synonym for a scheduled layoff.
An unspecialized vibe code, with no review and no ownership, can fool people in the short term, but it breaks against the real world. Only a firm engineering foundation guarantees a system's long-term stability. No matter which shortcut AI manages to take, being able to orchestrate a production environment over the long run will not be absorbed autonomously any time soon. And that is why, whatever tool we have at our disposal, survival belongs to whoever understands that the responsibility, as always, will be entirely ours.
2 A term we used back when I worked at a consultancy (not Codeminer), for when we ran into exotic solutions, like a calendar built by hand, day by day, instead of a simple loop; or a non-deterministic authentication where the same user and password worked or failed depending on which server they hit.
3 A term Akita uses for complacent programmers who are being let go in layoffs.