Start vibe coding with a written boundary
Use natural language to make a first working version, while keeping the scope, acceptance bar, and change history explicit. Speed comes from shortening the loop, not from removing review.
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Start vibe coding with a written boundary”?
Use natural language to make a first working version, while keeping the scope, acceptance bar, and change history explicit. Speed comes from shortening the loop, not from removing review.
The brief is the first safety gate. AI can generate a lot before you notice the requirement drift. A short brief with states, constraints, and a finish line keeps the collaboration pointed at the same result.
Write the smallest version that can be tested by another person today.
Accepting “it runs” as evidence that the product is done.
The following four failure types recur repeatedly in AI collaboration, all rooted in the same cause: constraints never made it into the context.
Misunderstanding Rework
AI starts writing the moment it gets requirements, producing 200 lines before realizing it misunderstood. Worse, it modifies 7 files before discovering the approach was wrong — reverting each one is extremely costly.
Tech Stack Drift
AI picks different frameworks in different conversations: Express today, Fastify tomorrow. Databases oscillate between MongoDB and PostgreSQL. Without a locked tech stack, the project drifts and loses consistency.
Well-Intentioned Destruction
AI cleans up code it considers redundant during refactoring, and you only discover that code was useful after the fact. Well-intentioned cleanup becomes a destructive operation.
Permanent Technical Debt
You ask for a complete auth system; AI suggests "start with a simple login and add OAuth later." That "later" never arrives, and the simple code becomes permanent technical debt.
The same request — "Build me a login" — leads to completely different outcomes with and without rules. Click "Next Step" to advance both timelines simultaneously.
There are three common ways to communicate constraints to AI. Click to switch and see whether the same constraint ("use PostgreSQL for the database") remains in effect at three different points.
frontmatter controls when it applies
---
alwaysApply: true # auto-applies to all conversations
---
# Development Constraints & Config Standards
The following are important user constraints. Please follow them strictly.true for global coding standards; false for on-demand files like writing style guides, to avoid polluting the coding conversation context.
Three files in xs_vibe_rules
rule-opensource.mdc: Main development standards, 14 chapters covering the full workflowwriting-style.mdc: Writing style guide, manually referenced on demandsecrets.mdc: API key and credentials template in placeholder form
To use, simply place them in your project's .cursor/rules/ directory.
itshen/xs_vibe_rules · Open-source repo for this series
The complete rule set is fully open source (MIT License). Fork it, place it in your project's .cursor/rules/ directory, then trim and adjust it to your own tech stack — and you've got your first version of an AI collaboration standard.
The value of rules lies not in quantity but in each one solving a real problem. Every time AI makes the same mistake again, turn it into a rule — that's the foundational method of this entire series. Whether constraints hold is determined by the injection mechanism: writing "you must" ten times still loses to a Rule file that auto-loads every turn.
Source material: This series is based on the author's open-source repository itshen/xs_vibe_rules, containing Cursor Rules and design thinking distilled from multiple real projects.
Turn the feeling in “Four Typical Failure Types” into a judgment
“The following four failure types recur repeatedly in AI collaboration, all rooted in the same cause: constraints never made it into the context” points out that AI has lowered the bar for making something usable. The skill readers need is noticing what is wrong and turning that feeling into an actionable requirement.
Watch the user's next action, not just the surface
Turn “AI starts writing the moment it gets requirements, producing 200 lines before realizing it misunderstood.” into observable questions: does the user know what happened, what to do next, and how to recover from an empty or failed state? Does the hierarchy make the important information visible first?
- rule-opensource.mdc : Main development standards, 14 chapters covering the full workflow
- writing-style.mdc : Writing style guide, manually referenced on demand
- secrets.mdc : API key and credentials template in placeholder form
Pretty is not the same as usable
Apply “The value of rules lies not in quantity but in each one solving a real problem.” to a second screen or flow. Record one moment of hesitation and the user action after the change; observable behavior is stronger evidence than polish alone.
From “Four Typical Failure Types” to “Misunderstanding Rework”
“Four Typical Failure Types” grounds the problem in “The following four failure types recur repeatedly in AI collaboration, all rooted in the same cause: constraints never made it into the context”. “Misunderstanding Rework” then moves it toward “AI starts writing the moment it gets requirements, producing 200 lines before realizing it misunderstood. Worse, it modifies 7 files before discovering the approach was wrong — reverting each one is extremely c…”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
For experience work, turn abstract impressions into user actions: did the person understand the state, find the next step, recover from an error, and want to continue?
- “Four Typical Failure Types”: The following four failure types recur repeatedly in AI collaboration, all rooted in the same cause: constraints never made it into the context
- “Misunderstanding Rework”: AI starts writing the moment it gets requirements, producing 200 lines before realizing it misunderstood. Worse, it modifies 7 files before discovering the approach was wrong — reverting each one is extremely c…
- “The closing point”: secrets.mdc : API key and credentials template in placeholder form
The final “The closing point” brings the discussion to “secrets.mdc : API key and credentials template in placeholder form”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.