- Published on
Vibe Specs: Vibe Coding That Actually Works

- Authors
- Name
- Luke Bechtel
- @linkbechtel
"It doesn't matter how quickly you can create something if it's useless"
0. Quick Start (2 minutes)
TL;DR: Make your AI write requirements before code. It takes 5 extra minutes and saves hours of confusion. Copy the cursor rules below and try it on your next feature.
Just wanna try it? Here's the fastest path:
๐ Expand for Quick Start Instructions
1. Copy this into your Cursor settings (or your AI IDE of choice)
๐ Copy These Instructions
## Development Workflow: Spec โ Code
THESE INSTRUCTIONS ARE CRITICAL!
They dramatically improve the quality of the work you create.
### Phase 1: Requirements First
When asked to implement any feature or make changes, ALWAYS start by asking:
"Should I create a Spec for this task first?"
IFF user agrees:
- Create a markdown file in `.cursor/scopes/FeatureName.md`
- Interview the user to clarify:
- Purpose & user problem
- Success criteria
- Scope & constraints
- Technical considerations
- Out of scope items
### Phase 2: Review & Refine
After drafting the Spec:
- Present it to the user
- Ask: "Does this capture your intent? Any changes needed?"
- Iterate until user approves
- End with: "Spec looks good? Type 'GO!' when ready to implement"
### Phase 3: Implementation
ONLY after user types "GO!" or explicitly approves:
- Begin coding based on the Spec
- Reference the Spec for decisions
- Update Spec if scope changes, but ask user first.
### File Organization
\`\`\`
.cursor/
โโโ scopes/
โ โโโ FeatureName.md # Shared/committed Specs
โ โโโ .local/ # Git-ignored experimental Specs
โ โโโ Experiment.md
\`\`\`
**Remember: Think first, ask clarifying questions, _then_ code. The Spec is your north star.**
(source: https://lukebechtel.com/blog/vibe-speccing)
2. Make sure the rules are labelled "Always Attached"
3. Start a new chat and type:
"Help me add user authentication to my app"
4. Follow the AI Through Spec Creation
The AI will:
- โ Ask smart questions you hadn't considered
- ๐ Write a clear requirements document
- โ Wait for your approval
Example questions it might ask:
- "Will users log in with email or username?"
- "Do you need password reset functionality?"
- "Should sessions expire?"
You're free to edit this for as long as you'd like.
The LLM won't write code until you say you want it!
5. Authorize Code
Once you're happy, you can authorize the LLM to go (just say "go!").
The LLM will then build exactly what you agreed on
That's it! You just experienced Vibe Speccing.
โฑ๏ธ Time invested: 5 minutes writing requirements
๐ฐ Time saved: Hours of wrong implementations
๐ Keep reading to understand why this works
If pasting AI rules from random strangers makes you uncomfortable, read on for some background.
I. Vibe Coder's Lament
Consider the modern predicament: You sit before your IDE, cursor blinking expectantly. The task is clear enough in your mind: implement a widget. You open your AI Agent of choice, and begin typing:
Create a widget that...
30 minutes later, you're ten modules deep, with 49 files changed, and have iterated through six separate widget architectures, each one replete with handlers for edge cases you'll never encounter and optimizations for scale you'll never reach.
You close the chat window. You open a new one.
๐ฎโ๐จLet me be more specific...
Sound familiar?
LLMs will happily expand a vague prompt into paragraphs of plausible code. Hundreds of memes make fun of the low-quality "slop software" that comes from lazy prompting -- but even the best-intentioned programmers still run into issues where the AI spends a lot of time building features that didn't align with their original intentions:
@karpathy: Noticing myself adopting a certain rhythm in AI-assisted coding (i.e. code I actually and professionally care about, contrast to vibe code).
...
The emphasis is on keeping a very tight leash on this new over-eager junior intern savant with encyclopedic knowledge of software, but who also bullshits you all the time, has an over-abundance of courage and shows little to no taste for good code. And emphasis on being slow, defensive, careful, paranoid, and on always taking the inline learning opportunity, not delegating. Many of these stages are clunky and manual and aren't made explicit or super well supported yet in existing tools. We're still very early and so much can still be done on the UI/UX of AI assisted coding.
There are many folk remedies for this; longer prompts, stricter system messages, chains / trees of thought, endless "you are an expert" preambles. These remedies have their place. But they're all nuanced, flaky, and complicated to implement. The average developer just wants something fire-and-forget -- and who can blame them?
AI was supposed to be easier!
Besides, these are all bandaids. The real problem, the real reason that so much AI-generated software kinda sucks is much simpler: the AI doesn't understand the problem you're solving, because you didn't adequately explain the problem's context.
Context Engineering
source, @karpathy to @tobi on X
There's a growing understanding that "prompt engineering" isn't a sufficient term for what working with LLMs actually requires. As Andrej Karpathy recently noted in response to Tobias Lรผtke, "Context Engineering" better captures the sophisticated orchestration involved.
Karpathy Elaborates:
People associate prompts with short task descriptions you'd give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step. Science because doing this right involves task descriptions and explanations, few shot examples, RAG, related (possibly multimodal) data, tools, state and history, compacting... Too little or of the wrong form and the LLM doesn't have the right context for optimal performance. Too much or too irrelevant and the LLM costs might go up and performance might come down. Doing this well is highly non-trivial. And art because of the guiding intuition around LLM psychology of people spirits.
source, @karpathy to @tobi on X
Too little context and the LLM flails. Too much and it gets lost, or expensive. It's about finding that sweet spot.
Perhaps what Karpathy is saying here about LLM Applications could also improve our day-to-day use.
And art because of the guiding intuition around LLM psychology of people spirits.
"People Spirits"... it is kinda like that, isn't it?
Hmmm... maybe this problem isn't really so new?
Manager Brain
The very same issues come up when delegating tasks to human workers, too.
The way we solve this with humans, is to write a concise set of specs (AKA requirements / PRDs), answering basic questions:
- What is the objective?
- What determines success?
- What tools should we use to achieve the objective?
- What is out-of-scope?
- How will we know when we're finished?
And indeed, with AI, it turns out that this older, humbler practice is still the cure: write the specs first.
Give the AI a crisp spec, and you get crisp, consistent output; give it a vibe, and you get a vibe back.
"But specs are hard to write!" -- you complain.
Ah yes, they used to be... until recently...
II. The Modest Proposal
I know what you're thinking:
Ugh, great, more documentation I have to write. Just what I needed.
But here's the thing - you don't write the Spec; the LLM does.
Your job is to critique, tweak, and clarify.
The multi-turn Spec construction process naturally guides you toward giving the LLM exactly what it needs. The Vibe Specs pattern helps you fall into the pit of success with context engineering.
And here's the best part: you don't even have to remember to do it. Just paste my cursor rules (below) once, and your AI will automatically ask to create a Spec before writing any code.
Make your LLM write a spec before it codes.
That's it. That's the whole trick.
The first thing you do with your LLM should be to write a Spec, not Code.
Workflow

(Click to expand): Complete Cursor Rules (Copy This!)
## Development Workflow: Spec โ Code
THESE INSTRUCTIONS ARE CRITICAL!
They dramatically improve the quality of the work you create.
### Phase 1: Requirements First
When asked to implement any feature or make changes, ALWAYS start by asking:
"Should I create a Spec for this task first?"
IFF user agrees:
- Create a markdown file in `.cursor/scopes/FeatureName.md`
- Interview the user to clarify:
- Purpose & user problem
- Success criteria
- Scope & constraints
- Technical considerations
- Out of scope items
### Phase 2: Review & Refine
After drafting the Spec:
- Present it to the user
- Ask: "Does this capture your intent? Any changes needed?"
- Iterate until user approves
- End with: "Spec looks good? Type 'GO!' when ready to implement"
### Phase 3: Implementation
ONLY after user types "GO!" or explicitly approves:
- Begin coding based on the Spec
- Reference the Spec for decisions
- Update Spec if scope changes, but ask user first.
### File Organization
\`\`\`
.cursor/
โโโ scopes/
โ โโโ FeatureName.md # Shared/committed Specs
โ โโโ .local/ # Git-ignored experimental Specs
โ โโโ Experiment.md
\`\`\`
**Remember: Think first, ask clarifying questions, _then_ code. The Spec is your north star.**
(source: https://lukebechtel.com/blog/vibe-speccing)
- Add a new rule for your AI Code Helper of Choice (Cursor, Windsurf, Claude Code, etc)
- Make sure the rule is "Always Attached"
- Start a New AI Chat
- Let the AI guide you through Spec creation
- ???
- Profit
Example
What does this do? Here's a before and after:
BEFORE (Immediate Code Generation)
help me create an API route that handles search functionality
I'll create a search API route for you. Let me implement this with a basic search endpoint that can handle query parameters.
I've implemented a comprehensive search API with:
- Full-text search across multiple fields
- Pagination support
- Fuzzy matching for typos
- Search result ranking
- Caching layer for performance
The endpoint supports filtering by category, date range, and custom fields. Would you like me to add search analytics tracking as well?
ok first of all this isn't working
secondly you used several systems we don't have access to, like:
...
deletes branch in frustration
AFTER (Spec-First)
help me create an API route that handles search functionality
I'd be happy to help you create a search API route!
Before I start coding, should I create a spec for this task first?
This will help us clarify exactly what kind of search functionality you need.
Yes, let's do that
Great! Let me ask a few questions to understand your search requirements:
- What will users be searching? (products, blog posts, users, etc.)
- What fields should be searchable? (title only, title + description, everything?)
- Do you need any filters? (category, date range, price range, etc.)
- What about search features?
- Exact match only or fuzzy/partial matching?
- Case sensitive or insensitive?
- Do you need autocomplete/suggestions?
- Performance requirements?
- Expected search volume?
- Need for caching?
- Response time targets?
- What database/search solution are you using?: (PostgreSQL, Elasticsearch, etc.)
We're searching blog posts. Just title and content fields, case-insensitive partial matching is fine. No filters needed yet. Using PostgreSQL. This is for a small blog, so performance isn't critical.
Perfect! Let me create a spec for this search functionality:
I've created a spec for your blog search API.
Does this capture your intent? Any changes needed?
Looks perfect! GO!
Excellent! Now I'll implement the search API based on our spec.
I've implemented a clean, focused search API that matches our spec exactly:
โ Simple ILIKE queries on title and content
โ Case-insensitive partial matching
โ Returns title, excerpt, and URL
โ Limits to 20 results
โ Title matches ranked higher
The implementation is just 24 lines of focused code.
Want me to add a simple test file as well?
My original instructions kind of sucked, didn't they?
But because we were vibe speccing, it didn't matter!
In the Spec-First approach, we account for this type of under-specified problem. The LLM will ask us follow up questions, and ensure it's building the right thing, before it jumps in.
The contrast is striking. In the first screenshot, the assistant immediately dives into implementation, spending 5 minutes generating code that may not match the user's actual needs. In the second, it pauses to understand requirements first.
The Spec-first approach doesn't just produce better code, it respects your time and cognitive load.
Benefits
Why do this? Doesn't this just take a lot of extra time on the front end?
Aren't we trying to move fast & break things?
Well, no. Slow is smooth, and smooth is fast.
It doesn't matter how quickly you can create something if it's useless.
Here are the key problems I've noticed with traditional LLM workflows, and how a Spec-first approach solves them:
Chat Drift โ Stable Documentation
Problem: Exploratory Chat histories necessarily include the exploration and correction of many blind alleys. These turns of conversation would confuse anyone -- and LLMs are no exception.
Solution: A Spec document remains stable, even as the chat context changes. Reset the chat window. Change models. Switch IDEs. It doesn't matter; the Spec is just a document in your codebase, like any other file. You're providing structured, dense information that the LLM can parse efficiently (Batarseh et al., 2021).
Solo Coding โ Team Sport
Problem: LLM development is often a solo endeavor because chat histories are ephemeral and personal. You can't easily hand off work to a colleague or pick up where someone else left off without lengthy explanations.
Solution: With a Spec, suddenly it's not single-player anymore. You can close your chat, go to lunch, come back, and hand the same Spec to a completely fresh context window โ or to a human colleague. The work persists beyond the ephemeral chat session.
No Version Control โ Git-Tracked Requirements
Problem: Git doesn't track your AI conversations. It can't diff your chat history. When requirements evolve or team members need context, there's no systematic way to track the evolution of your thinking.
Solution: Git can track
WidgetFeature.md
, and more importantly, it can track howWidgetFeature.md
evolves as your understanding deepens. You can push up the git branch with the Spec and let another colleague begin work immediately, with full context about what needs to be built and why.
Feature Creep โ Defined Scope
Problem: Natural language can be very ambiguous. There's a reason that legalese exists. When you tell an LLM "make a search feature," it might reasonably assume you want fuzzy matching, autocomplete, search history, and real-time updates, or it might assume you want none of these.
Solution: When your Spec specifies "basic string matching on user names only," you skip the feature creep entirely. Structured requirements are less ambiguous than conversational requests.
Lost Context โ Instant Resume
Problem: Projects go off course and feel like they require too much effort to get back on track, leading to abandonment.
Solution: With Specs, you can return to a project after a week and understand immediately not just what you were building, but why you made specific architectural decisions.
Blank Page Paralysis โ Structured Start
Problem: That terrifying moment of not knowing how to start a feature or project.
Solution: The LLM becomes your documentation assistant first, your coding assistant second. It's much easier to critique a proposed Spec than to draft one from scratch.
Token Waste โ Efficient Context
Problem: Burning precious context tokens on exploratory conversation instead of focused implementation.
Solution: You're providing structured, dense information that the LLM can parse efficiently, leading to more focused and relevant responses.
III. The Evidence
I have three sources of evidence that this is the most effective way to use LLMs -- personal anecdata, academic research, and industry examples.
Personal Results
My Interview With the CTO
I recently had a fun interview with the CTO of a leading bay area AI Startup.
Part of the interview process was an open-ended real-world coding task, to assess how well I could use AI coding tools. (Which was so much more fun and realistic than leetcode...)
I had 45 minutes to write a fairly complex webserver. Spending the first 5 minutes writing a Spec let me finish 20 minutes early, with a perfect implementation.
Here's roughly how I spent my time:
- 5 minutes writing the Spec with the LLM.
- 10 minutes writing the code with the LLM.
- 5 minutes validating the code.
- 20 minutes asking the CTO questions.
Not bad, eh?
My Day-To-Day
In my own development:
- Before Spec: I would often spend 2-3 hours implementing something, then realizing I built the wrong thing
- After Spec: I spend about 10-20 minutes planning each feature, and 1 hour implementing correctly
- Time saved: I estimate that I have a ~60% reduction in feature development time, and I come out with a better result far more often.
In my personal experience, implementing my simple cursorrule has saved me literally days of back-and-forth with LLMs.
Academic Evidence
Academia seems to be catching on -- Recent research on LLM-assisted development emphasizes that specifications are "the missing link" in making LLM code generation reliable (Pullum et al., 2020).
Industry Validation
If you prefer an industry example, how about OpenAI? They seem to have noticed this pattern too. Their new Deep Research mode pauses to ask clarifying questions, tightening the problem definition before spending extra compute. Instead of torrenting answers, it builds understanding first. Imagine your coding assistant doing likewise: a quick interrogation that locks down scope, constraints, and must-haves, so the next burst of code is laser-focused instead of encyclopedic.
This differs from conventional AI-assisted development wisdom, which treats LLMs as code generators to be used when you're uncertain. "I need to implement X, let me ask Claude to write it." But this approach misunderstands both LLMs and good software development.
The magic isn't in avoiding the LLM until you have requirements. The magic is in using the LLM to help you discover what your requirements actually are.
As another example, Shopify's approach to their Auto Write feature began with a comprehensive Spec that aligned AI capabilities with merchant needs.
The pattern is becoming clear: successful AI features start with clear requirements, not clever prompts.
IV. The Critique
"gotta go fast"
A common objection, "But I'm prototyping/in a hackathon/need to move fast!"
Even for prototypes, 5 minutes of Spec saves hours of refactoring.
*It doesn't matter how quickly you can create something if it's useless.**
Garbage-in, Garbage-out
Of course, this does require you to give valid input.
It requires you to be somewhat present at the wheel.
But that's precisely why the conversation matters. The LLM doesn't write your Spec in isolation; it interviews you, challenges assumptions, and iterates based on your feedback.
V. Final Thoughts
In the age of AI-assisted development, every dev will become their own product manager.
The hardest part isn't writing the code anymore -- it's knowing what code to write. LLMs are incredibly powerful at the former. The Vibe Specs pattern ensures we don't abdicate responsibility for the latter.
Start your next feature with a Spec. Let your AI help you write it. Watch as your development velocity increases, your code quality improves, andโmost importantlyโyour ability to context-switch without losing your mind returns.
The future of AI-assisted development isn't about better code generation. It's about better requirement articulation. LLM -> Spec -> Code. This is the way.
Try It Now (5 Minutes)
- Copy the cursor rules
- Open your IDE
- Type: "Help me create [your next feature]"
- Watch the magic happen
LLM -> Spec -> Code.
This is the way.
Share Your Story
Tried vibe speccing? I'd love to hear about it:
- ๐ฆ Tweet your experience: @linkbechtel #VibeSpecs
- ๐ง Email: luke@lukebechtel.com
The best stories will be featured in a follow-up post (with permission).
FAQ
Does this work with ChatGPT/Claude/other AI tools?
Yes! While the examples use Cursor, the Spec-first approach works with any AI coding assistant:
- ChatGPT: Add the rules to Custom Instructions
- Claude: Include in your Project instructions
- Windsurf/Continue/Cody: Add to their respective config files
- Raw API calls: Include in your system prompt
The key is making the Spec request automatic, not optional.
How is this different from traditional documentation?
Traditional documentation is written after implementation to explain what was built. Specs are written before implementation to clarify what should be built. Think of Specs as a conversation with your future self (and your AI) about intent, while docs are a record of what actually happened.
What if I'm working on existing code?
Even better! Specs are incredibly valuable for modifications:
- "Refactor auth system" โ Spec clarifies which parts change and which stay
- "Fix performance issue" โ Spec defines success metrics and constraints
- "Add feature to legacy code" โ Spec documents assumptions and integration points
The AI can analyze existing code and help write Specs that respect current architecture.
Isn't this just waterfall development with extra steps?
No! This is still iterative. The difference:
- Waterfall: Spend weeks on massive requirement docs, then code for months
- This approach: Spend 5-10 minutes per feature, iterate on Spec as you learn
- Specs can be updated mid-implementation when you discover new constraints
- Each feature gets its own mini-Spec, not one giant document
How detailed should Specs be?
Match detail to complexity and risk:
- Simple bug fix: 3-5 bullet points
- New feature: 1-2 pages
- Architecture change: 2-5 pages with diagrams
- Greenfield project: Start with high-level Spec, create sub-Specs for each component
Rule of thumb: If explaining to a new team member would take 5+ minutes, write a Spec.
What if the AI writes a bad Spec?
That's exactly why you review it! Common issues:
- Too vague: Ask for specific success criteria
- Too complex: Break into smaller features
- Wrong assumptions: Correct them before coding starts
- Missing context: Add domain knowledge the AI lacks
Remember: You're the architect, the AI is your drafting assistant.
Can I use this for non-coding tasks?
Absolutely! I use it for blog posts.
This pattern works for any complex task:
- Writing blog posts (Spec = outline)
- Creating presentations (Spec = key messages)
- Planning projects (Spec = project charter)
- Designing systems (Spec = design doc)
The principle remains: clarify intent before execution.
How do I convince my team to adopt this?
Start with yourself:
- Use it solo for a week
- Share a particularly good Spec/result with your team
- Offer to write Specs for shared features
- Track your velocity improvement
- Let results speak for themselves
Don't mandate it -- let people opt in as they see the benefits.
What about truly exploratory coding?
Sometimes you genuinely don't know what you're building until you build it. For true exploration:
- Write an "Exploration Spec" that defines what you're trying to learn
- Set time bounds and success criteria for the exploration
- After exploring, write a proper Spec for the real implementation
Even exploration benefits from lightweight structure.
Do Specs slow down hot fixes?
For true emergencies, skip the Spec. But after the fire is out:
- Write a retroactive Spec documenting what you did and why
- Use it to plan the proper fix (hot fixes are rarely the best solution)
- Prevent similar emergencies by addressing root causes in the Spec
Most "emergencies" aren'tโthey're just poorly defined problems.
Where do I store Specs in my project?
The suggested structure:
.cursor/
โโโ scopes/
โ โโโ feature-name.md # Committed specs
โ โโโ .local/ # Git-ignored experiments
โ โโโ experiment.md
But adapt to your team's workflow. The key is consistency and discoverability.
References & Further Reading
Academic Research:
- Dreossi, T., et al. (2024). "Specifications: The missing link to making the development of LLM-based software more trustworthy". arXiv preprint.
- Pullum, L., Freeman, L., & Huang, C. (2020). "Verification and Validation of Systems in Which AI is a Key Element". Systems Engineering Body of Knowledge.
- Batarseh, F. A., Freeman, L., & Huang, C. H. (2021). "A survey on artificial intelligence assurance". Journal of Big Data, 8(1), 1-30.
- Hand, D. J., & Khan, S. (2020). "Validating and Verifying AI Systems". Patterns, 1(3), 100037.
Industry Resources:
- Downie (2024). "Product requirement document generation using LLM task oriented". GitHub Gist.
- Alward, R. (2024). "Master the Blueprint: LLM Prompts for Perfect Product Requirements Documents (Spec)". Medium.
- Shoffstall, S. (2025). "Revolutionizing Product Development: How AI is Transforming the Spec Process". Medium.
Tools & Frameworks:
- Magical PM - AI-powered product management platform
- GoGPractice.io - LLM-assisted product development guide
- Mustafa Kapadia's Substack - Writing product requirements with AI