Vibe Coding

The Vibe Coding Workflow

Explore, plan, implement a small slice, review the diff, test, then commit. Repeat.

The loop

  1. Explore — read the files that will change. Ask "what already exists?"
  2. Plan — for anything non-trivial, demand a step list. Approve it.
  3. Implement — one slice. One feature, one bug, one refactor.
  4. Review — read the diff like a PR. Reject extra files and mystery logic.
  5. Test — run the command you named as "done."
  6. Commit — save the working slice. Then start the next loop.

If a slice takes more than about 20 minutes of back-and-forth, the slice is too big. Cut it in half.

Explore before you generate

Before writing code, list:
1. Files that already do something similar
2. The function or class I should change
3. Tests I should run
4. Anything you would need to invent (ask me instead)

Small slices

Bad slice: "Build the whole CLI." Better slices:

  • Parse arguments only, print help, no storage.
  • Add JSON storage for add.
  • Add list and a test.
  • Handle missing file and empty list.

Each slice ends with tests green and a commit.

When the vibe goes wrong

SymptomDo this
Files you did not ask forRevert, tighten constraints, retry
Same bug after 3 triesPaste the failing test; stop re-prompting the whole feature
Model rewrites style everywhere"Do not reformat unrelated code"
You cannot follow the diffAsk for a summary, then revert and plan smaller

A one-loop example

# 1. Explore
"Read notes.py. How are notes stored today?"

# 2. Plan
"I want a delete command. Do not code. List files and steps."

# 3. Implement
"Implement only `python notes.py delete INDEX` as in the plan.
Do not change add or list."

# 4. Review
"Show me the diff summary and any risk."

# 5. Test
pytest -q
python notes.py delete 0

# 6. Commit
git add notes.py test_notes.py
git commit -m "Add notes delete command"

How you run the loop at the keyboard

Do not keep the six steps in your head as a slogan. Map them to clicks:

  1. Explore — new chat, @ the likely file, “do not edit.”
  2. Plan — same thread, “do not write code.” You reply with answers.
  3. Implement — “implement step 2 only. Files allowed: …”
  4. Review — open the diff UI. Scroll every file. Then ask for a review if you want a second pass.
  5. Test — switch to the terminal. Run the done command. Paste failures back.
  6. Commit — you stage named files. You write the message. Then you start a new chat for the next slice.

A good user session is quiet: short prompts, a small diff, a green terminal, a commit. A bad one is a long chat and a dirty tree. Shrink the slice.

Try it yourself

You wanted delete. The agent also rewrote add and added a config class. Where did the loop break, and what do you do now?

Show solution

Implement was too wide, or you skipped “files allowed.” Restore add and the extra file. Prompt: “Implement only delete INDEX in notes.py. Do not change add or list.” Then review, pytest, commit.

Key takeaways

  • The workflow is the product. Prompts are just the interface.
  • One slice, one review, one test run, one commit.
  • Revert early. Retrying a giant mess costs more than starting the slice over.
  • New chat when the goal changes. Same chat while you finish one slice.

FAQ: The Vibe Coding Workflow

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 workflow 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 workflow in this Vibe Coding AI lesson (The Vibe Coding Workflow).

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.