As developers, we’re living in a time where building applications from scratch is easier than ever, thanks to AI tools like Claude Code.

Our customers now have the opportunity to experiment with new ideas and requirements by testing them in actual running software—in virtually no time. It takes just a few hours to explore multiple options, allowing everyone involved with the new product or feature to learn by interacting with the implemented ideas.

While modern frontend stacks (like Next.js) are often the best choice for UI-demanding prototypes, We found that the Rails 8 stack offers a convenient toolkit that balances backend and frontend work without requiring complex integrations. The Rails framework excels at pivoting between ideas, thanks to its practical approach to full-stack architecture.

However, the ease and speed these tools provide come with a catch: it’s just as easy to let the codebase spiral into chaos, making future changes and additions harder than they should be. Rapid early progress can quickly turn into bottlenecks if we don’t apply a bit of discipline from the beginning.

The following tips will help keep prototypes under control without sacrificing speed, while leveraging AI assistance to its fullest.

Tip 1: Define good practices and code style guidelines from the start

Early prototypes traditionally traded code quality for speed. To some extent, this is a valid tradeoff. However, tools like Claude Code actually benefit from working in a clean codebase.

For this reason, spending a little time to generate a good CLAUDE.md file is a smart investment. Make sure the following topics are covered:

• Clearly define that the project is a prototype or pre-production codebase. No backward compatibility is needed, data can be regenerated if schema changes are destructive, and simple solutions are preferred over complex abstractions—allowing us to iterate quickly.
• Consider writing down style decisions such as color palette, layout patterns, and components to use. Think of it as a simple component library for your prototype. I usually ask an LLM to generate this for me from a list of websites or ideas I provide as inspiration (mentioning we’re using Rails 8, so the documentation is written for our stack). The idea is to avoid wasting time wrestling with the AI over stylistic matters during prototyping—assuming, of course, that look-and-feel isn’t a key part of the ideas being tested.
• Something like “It’s a modern Rails 8 setup leveraging the new Solid* stack (Solid Cache, Solid Queue, Solid Cable) for database-backed caching, job processing, and WebSockets.” We’ll discuss the Solid stack importance in a following tip 🙂

Tip 2: Equip yourself with a good set of feedback tools for the AI

Recent versions of Ruby on Rails provide helpful tasks to check the quality of our codebase:

• The test suite. Yes, I know—does it really pay off writing tests for a prototype? But let the AI write tests from the start. They serve as documentation of implemented features for later rounds of changes made by the AI tool itself.
• RuboCop, the official linter. This ensures all generated code is consistent and easy to read in the future, at no cost. Less ambiguity also improves AI tool performance.

We always make sure Claude Code always runs those tasks so it gets immediate feedback and fixes any problems right away.

Rails includes security scan tasks by default. We rarely ask the AI to run these for every commit, but we set up to run them in the CI to be aware of potential problems early—before features are consolidated or promoted to production.

Tip 3: Leverage the Rails’ new Solid* stack

One interesting aspect of newer Rails versions is the intentional shift to rely solely on the web server and database. The so-called Solid* stack has evolved to reduce the need for additional products in the stack to virtually zero. Background jobs are one key area where you can have all the power you need without adding extra databases (e.g., Redis) or extra setup.

When starting a greenfield project, relying on a simple setup helps you move fast and focus on trying ideas. Migrating to more addecuate architectures is a need that will come if the application and the business around it mature enough.

In fact, for many proof-of-concept or new applications, the default database option in Rails —SQLite— is a decent starting point, even for production environments (which are usually pre-production or beta testing environments). There are voices claiming that SQLite is no longer a test-only database. Whether or not you believe such opinions, you can probably agree that it’s a simple setup that removes worries in the experimental stages of development projects.

Tip 4: Master the art of the “good enough review”

One of the most revolutionary aspects of using code agents is that we need to verify the code they generate—to some extent. At the end of the day, we author the code, so we need to understand what’s happening.

Ideally, we’d review every line to ensure quality in both code and behavior. However, this is ambitious when iterating quickly. Focusing too much on reviewing every detail will limit the productivity boost AI provides.

Our recommendation is to find the right balance—the appropriate amount of review necessary to understand the solution, validate the approach in each change, and confirm the behavior matches expectations (here you act more like QA). We focus on thinking through corner cases and identifying potential blind spots.

By mastering this you’ll remain comfortable navigating the codebase, even though you’ll know some parts better than others. As a rule of thumb, you need to stay in control of the basic MVC decisions (models, associations, controllers, routes), the database schema, and what runs in background jobs. Examples of things you’ll review less: view/template code, implementation of specific book algorithms, and most testing code.

Tip 5: Let the coding agent write documentation

When working on a complex feature or technical problem, the plan mode in Claude Code generates detailed documentation outlining the proposed solution. If the scope of work is significant—beyond what the AI can complete in a single session—markdown files are typically created alongside code changes to track progress across multiple Claude Code sessions. Documentation files are also created whenever the coding agent encounters something it deems worthy of being documented.

Consider keeping these files in a dedicated folder so coding AI tools can refer to them in later interactions, providing richer context. Having many documentation files isn’t a concern since almost no time is spent crafting them—the implementation plan must be written by the AI to present to you anyway. The AI can easily modify these files as the codebase evolves. You’re in control and can prune documents whenever needed to keep the codebase lean.

Tip 6: Make the most of the Ruby & Rails flexibility

When working with rapidly changing requirements, practical tools like Rails ActiveRecord and the Rails Console make everything easier. Ruby is an excellent choice for having AI write scripts—especially when you need to extract and manipulate data from databases, files, or the web. For example, you can have Claude Code periodically generate or update your seeds.rb file, ensuring you always have a robust set of local test data available.

Claude Code can interact with Rails application internals in powerful ways. For instance, you can ask it to generate test data, write scripts to simulate requests, or trigger background jobs programmatically—along with many other helpful tasks.

Ruby on Rails’ practicality shines when AI can propose numerous clever ways to interact with the codebase and running application we’re building, allowing us to accomplish more in less time.

Tip 7: Sense when you can consolidate part of the codebase

As time passes in the prototype phase of your application (or new parts of an existing mature one), you’ll need to decide when an implemented idea graduates from experimental to accepted. Ideally, after some iterations, you’ll find features or changes that feel less like a prototype and more like features stakeholders want to keep.

When this happens, transition to a more mature development process with greater scrutiny of code and technical decisions. The AI-generated code won’t be perfect, and you may need time to refactor and add better abstractions. However, if you followed the previous tips, you’ll still be able to navigate the solution and make the right decisions. In fact, the codebase will likely follow all the guidelines in CLAUDE.md and other documentation files you created along the way, making the current state a solid foundation to build on.

A recent example

Over just 20 focused working days, a single senior developer designed, built, and deployed a complete proof-of-concept application using Rails 8 and AI-assisted development. The project explored two divergent product hypotheses simultaneously:

• A user-driven platform where attendees self-organize professional meetings.
• An admin-driven platform where AI algorithms match participants through semantic profiling.

Both versions reached production quality and were deployed on Fly.io. By production quality, we mean the applications were tested with real users (~100) and ran without bugs or performance issues. However, the codebase wasn’t yet prepared to scale or be fully maintainable—that simply wasn’t our primary goal yet.

The development cadence remained consistently strong: 233 commits—averaging 12 per active day—and roughly 15,000 lines of code. Despite the prototype nature, the system delivered sophisticated features, including:

• Semantic matching powered by OpenAI
• Background job processing with Solid Queue
• Email campaign automation
• A complete design system and polished UI
• Real-time features via Solid Cable
• 100% dependency-free infra using SQLite, thanks to the Rails 8 Solid* stack (Solid Queue, Solid Cache, Solid Cable)

Work unfolded in strategic bursts: 3–5-day focused sprints for complex feature sets, followed by natural pauses for stakeholder review or other responsibilities. This rhythm preserved momentum while allowing product discovery to shape the next iteration.

Final thoughts

We’ve covered many ideas for testing new projects quickly. This year, powerful coding tools like Claude Code have enabled us to implement proof-of-concept and new applications in days. We’re still surprised by the productivity levels we’re achieving and the possibilities this opens for our customers.

If you have ideas you’d like to implement, reach out—let’s join the fast-prototyping ride with Ruby on Rails 8.1 and Claude Code.