1. The Core Problem: Too Many Ideas, Not Enough Finished Things
I always have loads of ideas for projects. Often I start them, and most of the time I don't even finish them. My problem isn’t creativity. The problem is that most of those ideas never make it past the “oh, that would be cool” stage.
So I end up with this growing backlog of “things I could build someday” and no clear way to:
- store them
- compare them
- or decide which one actually deserves my time
I saw an opportunity in this Kiroween Hackathon to build an app where I could:
- dump all my ideas
- validate them against the hackathon (or any) criteria
- and then actually move them towards something shippable
And so No Vibe No Code was created.
2. What is No Vibe No Code?
The core concept is from idea to vibecoding (or spec-coding in Kiro's case)
At a high level, No Vibe No Code is A place to bootstrap your ideas and get them into a Kiro-ready, development-ready shape as quickly as possible.
Here is an example of the user flow:
Step 1: Get an idea (or generate one)
- Write your own idea – maybe something that’s been sitting in your notes app for months
Or
- Use Dr. Frankenstein, this is basically a chaotic idea generator (inspired by the Kiroween category)
I personally love Dr. Frankenstein feature on No Vibe No Code because it randomly picks a few popular tech companies or a few AWS services -> Smashes them together -> And creates some weird hybrid idea that actually fits nicely for hackathon-style creativity.
Step 2: Validate your idea
Ok, so I have 100s of ideas, but how do I know if they are good ideas? How do I know if they are feasible? Are they even good ideas for this hackathon?
For that, we've added a 'Kiroween Analyser'. This feature will generate a report against the hackathon criteria and score it accordingly.
This validator opens a possibility to add multiple validators that can serve to analyse ideas against specific criteria like hackathons, games, small side-projects, the possibilities are endless. In this case, we were focused on Kiroween.
Step 3: Generate some core documents
Once you have an idea (manual or Frankenstein’ed), No Vibe No Code helps you generate the core docs you need to support your building:
- A PRD – to clarify the problem and the user
- A technical design doc - to describe how the solution will work at a feature level
- An architecture design - to map the high-level components, services, and boundaries (more tech-oriented)
- A roadmap for an MVP – to define the smallest version worth shipping and how to get there
The goal is: your idea stops being just a sentence and starts becoming a structured concept.
Step 4: Power up Kiro
Once those docs exist, you can export to kiro:
No Vibe No Code will then:
- Generate steering rules for Kiro
- Generate spec templates aligned with your roadmap
So instead of opening Kiro with a blank chat and writing “Help me build X,” you:
- Walk in with a defined idea
- Have a PRD, design, architecture, and MVP roadmap
- Already have steering rules and spec scaffolding ready to go
From there, you can just start kicking off specs and building.
That’s the main idea of No Vibe No Code:
from raw idea → structured docs → Kiro-ready boilerplate, with as little friction as possible.
Demo
3. Building Before Kiro
Because of my background as a platform / DevOps engineer, I naturally thought in terms of structure: roadmaps, milestones, and tasks.
So my workflow looked roughly like this:
Create a PRD or Readme with context for the project -> Create a roadmap with milestones to achieve and divided by tasks -> Ask the AI to implement each task based on those documents.
At the time, I didn’t even realise there was a name for what I was doing!!
So when I eventually discovered Kiro and saw its spec-driven development focus, I had this moment of:
“Hold on your horses… they’re doing exactly what I’ve been trying to do, just… better.”
That’s when I decided to go all in on Kiro.
4. My Journey with Kiro
When I first set up Kiro for this project, I went with the default, raw setup:
- No custom steering rules
- No MCPs
- No hooks
Obviously, this wasn't ideal as I was missing a lot of features.
Discovering Kiro’s Best Practices
In my first week, I joined the Kiro Discord and started reading through posts and getting to know best practices and how other people were building with Kiro.
Around that time, Kiro also released the MCP Server directory, which made it much easier to install MCPs.
I also discovered that Kiro could auto-generate some basic steering files for things like: tech, structure and product.
Taking it to the next Level
From there, my Kiro setup evolved gradually:
- Started adding steering rules and adapting them to my setup.
- Wired in some useful MCPs (context7, github, supabase).
- Using rules for inclusion on steering and triggers on hooks
Over days and weeks, this went from:
“Just raw Kiro, let’s see what happens.”
to:
“I have a small ecosystem here that actually understands how I like to work.”
Models - From autopilot to Opus 4.5
When I started this project, I kicked things off using Kiro Auto model. I wasn't sure if I was going to burn all my credits with the other models, and I didn't know the actual difference between those models. Default seems like a good plan.
For a big chunk of the journey, Auto was genuinely fine. Sometimes it produced bugs or weird decisions but nothing too critical.
Later on, when I saw I still had credits left, I decided to experiment a bit.
Sonnet 4.5
I tried Sonnet 4.5 for a few specs. Overall, it felt the same as Auto model bit more expensive. I still had to babysit some results and debug like crazy.
But then... There was an announcement!
Opus 4.5
Opus 4.5 landed, at x2.2 cost and with 500 credits left for the month, I decided to go all in with Opus for the last few specs.
That’s where I actually felt the difference. The code quality was noticeably higher, and there were fewer bugs (still some, but manageable).
Yes, it’s more expensive, but for the final specs, where I really cared about quality and didn’t want to waste time chasing edge cases, it felt absolutely worth it (I ended the month with 50 credits left)
Adding Property-Based Testing to the mix
Kiro announced Property-based testing halfway through Kiroween. It was such a good concept that I couldn't resist spending a spec on this.
After implementing it, I felt more comfortable trusting AI-generated code. It aligned well with the whole “let’s automate the boring but important parts” mindset. It creates a pretty solid safety net.
7. What I’d Do Differently (And how No Vibe No Code can help)
Let's recap on my journey:
- Started with a raw Kiro setup (no steering, no MCPs, no hooks).
- Added things gradually, as I discovered them.
- Let my IDE configuration drift and change over time.
- Tweaked the ecosystem spec by spec.
That worked, but it could have been a smoother experience. What I’d prefer instead is a solid boilerplate from day one: sensible project structure, steering rules setup, and documentation to get ready to spec.
And that’s exactly the point of No Vibe No Code. I want a place where I can show up with an idea, press a few buttons, and end up with:
- project docs generated.
- clear path from idea → MVP.
- boilerplate Kiro ready.
If there’s no vibe with the idea and documents, there’s no code
Share your Work and Ideas
You can try it out now!! Go to No Vibe No Code
You can spin up your own No Vibe No Code too!! Open Source GitHub repo: (https://github.com/llamojha/no-vibe-no-code-kiroween)
If you end up playing with this No Vibe No Code workflow, I’d genuinely love to see what you come up with.
In particular:
- What Dr. Frankenstein ideas did you generate?
- Which ones actually made it past the “haha that’s funny” stage and into a real PRD / design / roadmap?
- How was your experience going from raw idea → Kiro → working thing?
- If you think I should rebrand to No Vibe No Spec
Let’s get building!!
Top comments (1)
Really cool concept, but I wonder if adding this many layers (idea generator, analyzers, multiple docs, Kiro export) risks over-structuring early ideas. Could some genuinely good but “weird” ideas get filtered out because they don't score well or vibe in this framework yet? Curious how you avoid analysis paralysis in a tool meant to reduce it.