TL;DR:
Vibe coding (“one-sentence apps”) is fun, but it doesn’t scale.
Spec coding is a workflow where .md files (product.md, tech.md, requirements.md, etc.) act as living specs that guide the build, supported by automated hooks.
I tested this by building LiftFire, a gym-tracking app. Here’s what I learned:
- A small site can run on ~50 specs.
- A real-world app may need 500+ specs and 700+ vibes.
- Specs handle the big architecture; vibes nail the details.
- Humans remain the difference-maker.
It convinced me spec coding is the path forward for AI-assisted development.
From vibe coding magic to spec coding reality
The first time I saw vibe coding, it felt like magic: “Build me a site” → boom, a site appears.
But that magic doesn’t last when you go beyond toy demos.
One-sentence apps are fun demos, but they’re a dead end for serious development.
Real apps need structure. They need more than vibes.
That’s where spec coding comes in. Tools like Kiro IDE are exploring this path, and here’s how it worked for me:
-
Steering files (
product.md,tech.md,security.md,structure.md) act like living design docs. -
Specs break down systems into smaller apps, features, or modules — each with its own
requirements.md,design.md, andtasks.md. - Hooks (aka vibe requests) trigger things like tests, commits, or formatting — either manually or automatically when conditions are met.
This isn’t about replacing engineers. It’s about moving the conversation up from “lines of code” to “intent + architecture.”
My scaling law: 50 specs vs 500 specs
A small site = ~50 specs.
A real-world app with frontend, backend, DB, AWS, and social features = 500+ specs and 700+ vibes.
Specs move the big rocks.
Vibes hammer the details.
And the human supervising the process makes or breaks the outcome.
Automation is powerful, but it’s human judgment that gives the project meaning.
Specs vs Tickets
Specs in
.mdfiles beat tickets in Jira. Period.
Tickets scatter intent; specs centralize it.
Jira and Trello were built for human workflows, not AI-driven ones. Specs are closer to code, easier to maintain, and directly steer the build.
I’d even predict:
In 5 years, most startups won’t start with a codebase. They’ll start with a stack of
.mdspecs.
What it felt like building LiftFire
To test this workflow, I built LiftFire, a gym-tracking app.
Yes, I dragged my nephew into the gym for testing — accountability is a feature.
The MVP is functional: track exercises, goals, milestones. It’ll soon be published as an APK on Google Play.
But the most important part wasn’t the app itself — it was the experience of coding differently:
- Writing specs in
.mdfiles instead of losing intent in tickets. - Watching vibe hooks auto-generate tests when files changed.
- Realizing commits, linting, and other chores could fire automatically while I stayed in “design mode.”
It felt less like coding alone, more like orchestrating with a super-fast junior developer who never sleeps — but still needs guidance.
Why this matters
Most dev tools focus on speeding up typing.
Spec coding focuses on raising the level of abstraction:
- Engineers spend more time thinking about architecture and context.
- AI handles repetitive mechanics.
- Human supervision ties it all together.
What three devs + Jira do in six months, one dev with spec coding could do in two weeks.
It requires more effort up front, but it produces more robust software, faster, with fewer people stuck in glue work.
And still — people are the key. Without human vision, judgment, and long-term stewardship, there’s no lasting value.
Final thoughts
Vibe coding was the fun demo.
Spec coding is the step change toward real, large-scale AI-assisted software.
It doesn’t mean engineers go away — it means our role shifts: less boilerplate, more architecture, more decisions that matter.
And from what I’ve seen building LiftFire with Kiro, projects that embrace this model will ship faster, stronger, and leaner than those that don’t.
👉 What do you think: are specs the new tickets, or am I overselling the future? Would you trust 500 specs / 700 vibes to build your next app?
If you’re curious about the personal side of this story — why my nephew got dragged into the gym with me, and how that shaped the LiftFire app, I wrote about it on my personal blog
Top comments (4)
This was so interesting to read, I didn’t know spec coding could be used this way to improve development. It seems like a smart way to take advantage of AI and keeping the human role in architecture and decision-making. I’ll definitely be keeping an eye out for new updates on spec coding and LiftFire app, sounds like a cool project!!
Hey, thank you so much! I'll be pushing a landing page with a roadmap for more features over the LiftFire app. And all contributions are welcome!
In relation to spec coding, yeah I felt exactly like that: spent more time managing and creating functional documents than coding.
Damn I gotta check this out! I've been saying for ages that we should have LLMs enforcing ADRs, READMEs, etc, so this is just an extension of that principle. Keen to collaborate on this app!
Exactly! ADRs/READMEs are the gateway drug 😅—once you realize LLMs can enforce those, why stop there?
The tricky part is: should specs be just enforced, or also evolved automatically when code drifts?
If an AI can refactor code, why not refactor the spec too?