Have you ever found during Vibe Coding development that the code produced by AI is full of logical loopholes, making you doubt your life while fixing it?
In traditional development, Spec is justice. But when collaborating with AI, we are more like “directors”.
To make that talented but occasionally “crazy” AI actor put on a good show, you need two powerful tools: EARS (Script Logic) and BDD (Acceptance Stills).
EARS: Turning Requirements into “Logic Blocks”
You must have met this kind of PM, writing requirements like: “The system needs to be easier to use”, “Processing speed needs to be fast”. This is a disaster when writing code.
EARS (Easy Approach to Requirements Syntax) simply put, is to transform these “vague adjectives” into “precise instructions”.
EARS is like top-tier Prompt Engineering, forcing you to speak in closed logic. The main 5 sentence patterns allow you to “lock down” requirement boundaries at any time:
| Type | Description |
|---|---|
| Ubiquitous | The system shall... (Like breathing, must be obeyed at all times). |
| Event-driven | When [event happens], the system shall.... |
| Unwanted Behavior | If [bad thing happens], the system shall... (This is the soul of Error Handling). |
| State-driven | While [in a specific state], the system shall.... |
| Optional Feature | Where [feature is included], the system shall.... |
EARS helps you set strict rules
Making it impossible for AI to “talk nonsense with a straight face” logically.
BDD: Turning Tests into “Movie Scripts”
If EARS is a rigorous contract, then BDD (Behavior Driven Development) is a “flesh and blood story”. It doesn’t test a == b, it tests “what the user feels has happened”.
The syntax used by BDD is called Gherkin (Pickle, meant to be crisp and refreshing!), and the core trilogy is as follows:
| Syntax | Description |
|---|---|
| 🎬 Given (Background) | Setting the scene before shooting (e.g.: Having 100 dollars in pocket). |
| ⚡ When (Action) | The moment the director yells Action (e.g.: Ordered a spicy squid). |
| ✅ Then (Result) | The ending seen by the audience (e.g.: Received fragrant squid, wallet has 60 dollars less). |
Through this “storytelling” method, even non-engineers can communicate with us, and AI can also understand your true intent through these “examples”.
What is the difference between EARS vs BDD?
These two perform their own duties, and combining them is truly “invincible”.
| Feature | EARS (Requirement Syntax) | BDD (Behavior Driven) |
|---|---|---|
| Core Spirit | Precise Definition (Eliminate Ambiguity) | Consensus & Verification (Storytelling) |
| Like writing… | Legal Clauses | Movie Scripts |
| Main Audience | PM, Architect, Rule Maker | Engineer, QA, AI Assistant |
| Pain Point Solved | “What you made is not what I thought!” | “The logic is right, but it’s unusable!” |
Simply put: EARS helps you set the rules, BDD helps you verify the results.
EARS Advanced Application: Vibe Coding in Action
We directly stuff EARS rules and BDD scripts into the Prompt for AI to develop.
You can try giving instructions like this when developing “E-wallet Deduction”:
# Task: Please help me implement deduction API
## EARS Logic (Please strictly follow):
- [Event-driven]: When a request is received, the balance must be verified.
- [Unwanted]: If the balance is insufficient, return 400 error code 'INSUFFICIENT_FUNDS'.
- [State-driven]: While the wallet is in 'Frozen' state, reject all deduction.
## BDD Acceptance Script (For Jest testing):
Scenario: Deduction failed due to insufficient funds
Given User balance is 50 dollars
When Received request to deduct 100 dollars
Then API should return HTTP 400
And Error code should be 'INSUFFICIENT_FUNDS'
Try throwing this to AI, and the generated Code won’t deviate too far from the goal!
Conclusion
Whether in daily development or Vibe Coding, EARS and BDD are artifacts for improving efficiency.
EARS helps you set strict rules, BDD helps you confirm the performance results.