AI

Too Lazy to Set Up My Pet Project, So I Vibe Coded a CLI to Do It. Don’t Ask.

Why I Did This

I was about to start a pet project. Then I remembered I’d have to set it up. And I didn’t feel like doing that. So instead, I decided to start a completely different project: one that would set up my pet project for me. Without me writing a single line of code.

The logic was simple: if I could get an AI agent to set up my ideal stack, Rails, React, GraphQL, Docker, then not only would I skip the boring setup, I might even end up with a tool I’d actually use again.

I also figured this “comfy stack” would be a good baseline, since I’ve been using variations of it for years. Ironically, by the time I got the CLI working, I’d already changed my mind about the stack I wanted for my original project. But I went ahead anyway because, well, eclectic developer is in the blog title for a reason.

I also already knew that:

  • AI won’t replace knowing how to code, it just changes how you spend your time
  • The last 20% of a project is where most of the effort is
  • “Hands-off” coding still needs a lot of steering

This wasn’t about learning anything new. I already knew. I just wanted to witness it firsthand, for science.

Giving Credit Where It’s Due

For the initial steps (product definition, task breakdown, and project plan) I used ai-dev-tasks. This tool takes a single prompt describing your project, then generates:

  • A PRD, detailed product requirements document
  • A structured list of tasks to complete the build
  • Logical grouping and sequencing of those tasks

In short, it gave my AI agent a roadmap to follow instead of making it improvise everything from scratch. Think of it as handing a chef a recipe instead of just telling them “make something good.”

The Stack

The plan was to build:

  • Rails API backend
  • React frontend (to be done later)
  • GraphQL in between
  • PostgreSQL for the database
  • Docker for local and production parity

This stack is second nature to me, so I’d know if the agent was doing something weird. Or at least I’d like to think I would, some of it probably slipped past while I was pretending to read logs.

Process and Lessons Learned

The CLI win

Before anything went sideways, there was a clear victory: the CLI tool was up and running in under an hour of actual work. Full feature set, ready to generate projects, rollback on failure, with proper logging and prompts.

I was genuinely impressed, if this was any indication of what was ahead, my hypothesis (and everything I thought I knew about the “last 20%” being the hardest) might actually turn out to be wrong. (Spoiler: I wasn’t.)

Task sequencing matters (and the agent got it wrong)

I know setting up/configuring Docker should be the foundation. The agent didn’t. It put Rails first, Docker last. I followed along anyway, partly to see what would happen.

So the agent went ahead and set up everything Rails. And then it was convinced I could “just test” Rails without Docker. I couldn’t, I don’t even have Rails installed locally, and the whole point of using Docker is so I don’t need to. At one point, it told me the project was “ready to run” and to go ahead and try. Obviously, I couldn’t.

I suggested maybe we should have started with Docker. The AI agreed, and that’s when the real work began. What followed was a spiral of rebuilding and reconfiguring: spinning up more than 20 temporary Rails projects, tweaking Docker configurations, and wrestling with templates the AI’s own generators weren’t using correctly.

This took a couple of days (about four hours of actual hands-on time) of debugging and feeding information back to the agent. Still technically “hands-off” coding, but I was deep in the weeds guiding it toward something that actually ran.

Would planning Docker first have made it smooth? Maybe. Or maybe the AI would have just found a different way to make me regret my life choices.

Note on security: or lack thereof

Security wasn’t the focus here. The JWT setup and authentication configurations might be right, or they might be a disaster. I haven’t really checked.

At this point, I just don’t care. This is an early proof of concept, and if anything, it’s a reminder that security still requires a human touch and proper audits.

What We Got So Far

After running a single command, everything you need to start working on a solid backend is ready in seconds.

This includes a fully functional Rails API with authentication, database setup, and documentation, all wrapped up in a Docker environment that matches production.

The CLI handles project generation, error rollback, and comes with sensible defaults to make life easier.

This is not “half-baked proof of concept” territory. It’s a working full-stack backend generator. The React part is still ahead, but the foundation is solid.

If you’re curious or want to poke around yourself, check it out here: https://github.com/ItsGenis/rails-react-graphql

Achievements Recap

We built a CLI tool that generates boilerplate Rails + GraphQL projects with Docker support, ready for immediate development.

The tech details start here. Think of this as the changelog for curious minds, and yes, there will be some jargon.

CLI Tool Foundation

  • Core Infrastructure: TypeScript CLI, Commander.js, Inquirer.js, Chalk & Ora, rollback system, error handling
  • Commands: generate, rollback, help
  • Options: Project name/path, Rails & React versions, DB choice, TypeScript, RSpec, Jest, RuboCop, ESLint, Prettier, JWT auth, Swagger docs, Git init, Docker config

Rails Backend Generator

  • Core Setup: API-only Rails, PostgreSQL, Redis, multi-stage Dockerfile
  • GraphQL: GraphQL-Ruby, schema, queries, mutations, GraphiQL IDE
  • Auth: JWT-based, bcrypt, login/register/logout, migrations
  • Docs: Rswag with OpenAPI/Swagger, interactive docs at /api-docs
  • Testing: RSpec, FactoryBot, Faker, Shoulda Matchers, DB Cleaner
  • Code Quality: RuboCop, Sorbet, config files, Rake tasks
  • Env: variables management, Rails credentials, setup scripts
  • Docker: multi-stage builds, Compose config, dev overrides, health checks

Technical Challenges Solved

  • Template processing, constant naming, ERB handling
  • Docker service dependencies, DB automation, volume management
  • GraphQL schema autoloading, type definitions, routing
  • Rails config for API-only mode, CORS setup

Next Steps

React frontend generator with:

  • React + TypeScript
  • Apollo Client
  • Vite
  • Jest & React Testing Library
  • ESLint & Prettier

Also on the roadmap: CI/CD integration and expanded testing workflows.

Takeaways So Far

None of this was a surprise, but it’s useful to see it play out in a real build:

  • Not typing doesn’t mean not thinking, coding knowledge was essential to guide the agent
  • The first 80% really is fast, the last 20% takes most of the effort
  • You’re still the builder, just at a higher altitude

I’m hoping the React part will be easier. High hopes.

If you’ve made it this far, you now know:

  • Yes, you can get a Rails + GraphQL + Docker backend up without typing a single line yourself.
  • No, it’s not “push button, walk away.”

But it is a functional proof of concept that started with a genuinely lazy idea.

PS: Because README is code (or part of the project) too, I had to make the AI write it, and add a link to this post. What caught me off guard? It actually read the blog, gave feedback, and reviewed my work instead of just pasting a link. Peak recursion achieved.

Go figure.