A year ago, Andrej Karpathy coined “vibe coding.” Prompting AI, accepting what it spits out, not reading the diffs, shipping if it works. It was fun, it was fast, and for throwaway projects, it almost worked.
A year later, Karpathy himself retired. The practice has evolved. Developers are now orchestrating AI agents to write code while they own the architecture, the quality, and the correctness. He calls it “agentic engineering.” The distinction matters.
I got to see that distinction firsthand a few weeks ago, when I rescued a Ruby on Rails Stripped out every em dash, kept your sentence rhythm, your paragraph breaks, your list formatting. The agentic engineering framing sits on top without changing how the blog reads or feels.project.
At first glance, the product looked fine. The app was running, more than 200 paid users were using it, and new features had been added quickly as per the users request. The development had clearly been moving fast. But once I started going through the codebase, the story became clearer.
The code had been vibe-coded.
Quick decisions. Features built in the moment. Minimal structure. Very few tests. Some logic in controllers, some in models, some hidden in helpers. I checked with my team. Things worked, but nobody was fully confident touching the code.
If you’ve worked on projects like this, you know the feeling. The product is alive, but the codebase feels fragile.
This is exactly the gap agentic engineering is meant to close. AI can generate code fast. But someone still needs to own the architecture, enforce conventions, and make sure the system holds together. That’s the engineering part.
Here’s how we did it with Rails.
The Good News: Rails Is Built for This
What I love about Rails is that it handles this situation surprisingly well.
Rails is actually one of the best frameworks for agentic engineering workflows. Whether the code was written by a human in a rush or generated by an AI agent without enough guardrails.
Why?
Because Rails comes with strong opinions.
When a project drifts away from those opinions, you can bring it back. Rails conventions act like guardrails. They help you restore order without rewriting everything.
Step 1: Bring Back the Conventions
The first step was not rewriting the features. It was simply bringing the project back in line with Rails conventions.
This included things like:
- Keeping controllers lightweight and focused on request handling.
- Moving business logic into models or service objects
- Removing duplicated logic
- Following clear naming patterns
- Organizing the project structure properly
Rails’ “convention over configuration” philosophy makes this process surprisingly effective. The codebase becomes easier to understand and far more predictable, once the project aligns with those conventions again.
Predictability is essential for teams working collaboratively.
Step 2: Add Tests Where They Matter
The next step was introducing the tests.
The focus was placed on the most crucial parts of the system rather than attempting to cover everything immediately. This included key user flows, core business logic, and important API userpoints.
Rails provide solid testing support out of the box, whether you use Minitest or tools like RSpec. The small number of well targeted tests significantly improved the confidence while modifying the code.
Developers could make changes with much less risks, once these tests were done.
Step 3: Clean Up the Deployment Lifecycle
Another area that needed much attention was the deployment workflow.
The deployments often become informal in the fast moving projects. A few manual commands are run on a server. If something breaks, a quick fix is applied, and the process repeats.
However, Rails applications benefit greatly from a structured deployment process.
A reliable Rails deployment setup typically includes:
- Version-controlled codebase
- Automated tests before release
- CI checks on every push
- Clear environment configurations
- Predictable build and deploy steps
- Rollback capability if something fails
The deployments became much more predictable and far less stressful, once these practices were introduced.
Step 4: Letting Rails Do What Rails Does Best
Another common issue in many projects is trying to work around the framework instead of using it effectively.
Rails already provides well-established solutions for many common problems, like authentication, background processing, data validation, and API deployment.
The development becomes much more efficient and the overall system becomes easier to maintain by leaning into the patterns and tools Rails already offers.
The Result
After roughly two weeks, several gradual improvements were made:
- The codebase became significantly easier to navigate
- New features could be added more confidently
- Developers felt more comfortable working within the system
- Deployments became predictable and reliable
Most importantly, the application did not need to be rewritten. The improvements came from restoring the structure and following Ruby on Rails best practices.
Final Thoughts
Vibe coding is not a bad approach at all. In early product stages, it can help teams move quickly and validate ideas.
The structure becomes increasingly important, as an application grows and more developers become involved.
This is where Ruby on Rails continues to stand out.
Rails allows teams to move quickly in the beginning, while providing the conventions and tools needed to bring order to a growing codebase.
In many cases, teams also benefit from a dedicated Ruby on Rails maintenance service to keep the application stable, optimized, and easy to scale over time.
This balance is why still today, Rails remains a strong choice for building real and maintainable applications.
