Vibe Coding

Write Better Prompts

A good prompt names the goal, the files, the constraints, and what done looks like.

The four-part prompt

  1. Goal — one sentence of what should exist when you are done.
  2. Context — which files, functions, or docs to use.
  3. Constraints — what not to touch, libraries, style, tests.
  4. Done — how you will check: command, test name, or UI behavior.

Weak vs strong

Weak

Make a notes app and make it good.

Strong

Add a CLI notes app in notes.py.

Goal: `python notes.py add "buy milk"` saves a note,
and `python notes.py list` prints them one per line.

Context: empty repo, Python 3.12. Use argparse.
Store notes in notes.json in the project root.

Constraints:
- Do not add dependencies.
- Keep functions small and typed.
- Include tests in test_notes.py.

Done: pytest -q passes, and both commands work.

Prompt patterns that work

PatternWhenExample opener
ImplementYou already know the design"Add function X in file Y that..."
Plan onlyMore than one file"Do not write code. List steps and files."
ExplainYou are lost in a module"Summarize this file. Then list risks."
FixYou have an error"Here is the command, traceback, and expected result."
ReviewAfter a generation"Review this diff for bugs, extra files, and secrets."

Be specific about shape

If you care about the API, show it. Models copy examples more reliably than adjectives like "clean" or "simple."

Implement this exact function signature and keep it:

def parse_tags(raw: str) -> list[str]:
    """Split a comma-separated tag string, strip spaces, drop empties."""

Example: parse_tags("python, ai, ") == ["python", "ai"]

One goal per prompt

"Add login, redesign the homepage, and migrate the database" is three projects. Split them. The model will otherwise touch everything and finish none of it well.

If a prompt needs more than a short paragraph of constraints, the task is too big. Plan first, then implement one step.

How you write a prompt in the editor

  1. Type the four parts in the chat box. Do not send a one-liner and hope.
  2. Add @ mentions for the files in Context (or name the paths in a CLI agent). If you cannot name them, explore first.
  3. Send. If the model asks product questions, answer them in the next message — do not say “just pick.”
  4. If the reply is a plan, approve or correct it. If it already started coding and you asked for a plan, say “stop, plan only.”

Keep a scratch note of your four parts. Copy it into chat. After a week you will type them from memory.

Try it yourself

Rewrite this weak prompt using the four parts: “Fix my Python script, it doesn’t work.” Assume the script is total.py and the error is a TypeError when summing strings.

Show solution
@total.py

Goal: sum the numbers in a list of digit strings without crashing.
Context: total.py, function total(values: list[str]) -> int.
The command `python -c "from total import total; print(total(['1','2']))"`
should print 3. Right now it raises TypeError.

Constraints: do not add dependencies; keep the function name.

Done: that command prints 3, and pytest -q passes if tests exist.

Key takeaways

  • Goal, context, constraints, done.
  • Show the API or example output. Do not only say “make it nice.”
  • One change per prompt. Split the rest.
  • You write the four parts. The agent fills the files. You still review.

FAQ: Write Better Prompts

Common questions about this page.

What is vibe coding?

Vibe coding is building software by directing an AI in natural language while you review, test, and own the result. The StudyGrid Vibe Coding course teaches the workflow, prompts, and habits that make it work.

Should I run vibe coding prompts examples locally for better learning?

Yes. Use the browser editor on StudyGrid for a quick check, then Download the example and run it on your computer. Local runs show real errors and the real toolchain, which is one of the fastest ways to learn vibe coding prompts in this Vibe Coding AI lesson (Write Better Prompts).

How do I vibe code the right way?

Give one clear goal, attach the files that matter, ask for a plan first, review every diff, run tests, then commit a small slice. The How You Work lesson is the session guide. Best Practices is the full playbook.

How does a user actually work with vibe coding?

You open a real project in an agent editor or CLI agent (Cursor, VS Code + Copilot, Claude Code, and similar), write one goal, attach two or three files, ask the agent to plan then implement a small slice, read the diff, run tests yourself, and commit. You are the director. The model drafts. The How You Work lesson walks through a 30-minute session. The Tools lesson is the stack picker.

Is vibe coding only for experts?

No. Beginners can use it to learn faster if they read the generated code. Experts use it to move quicker on boilerplate while keeping architecture and review in their hands.

What tools do I need for vibe coding?

You need an agent that can read your project, edit files, and show a diff — for example Cursor, VS Code with GitHub Copilot, Claude Code, Codex CLI, Continue, or Windsurf — plus Git for undo and a language you can read (this course uses Python). A browser chatbot is not enough. The Tools lesson compares the stacks. Setup covers the checklist.

Which AI coding tool should I use for vibe coding?

Pick one stack and stay with it for a project. Cursor is a common agent editor. VS Code plus GitHub Copilot fits if you already work there. Claude Code and Codex CLI are terminal agents. Continue, Windsurf, Zed, and JetBrains AI Assistant also work if they can apply a diff. Do not hop tools on a dirty tree.

Is the Vibe Coding course free?

Yes. The full Vibe Coding course on StudyGrid (studygrid.in) is free. Open the header menu, start at What Is Vibe Coding, then How You Work and Tools, and follow Next through the project and cheatsheet.