What Is Vibe Coding

The idea

You describe what you want. The model writes most of the code. You read the diff, run it, and decide what stays. The "vibe" is the conversation. The engineering is still yours: scope, tests, review, and shipping.

Andrej Karpathy popularized the phrase in 2025: fully giving in to the tools, forgetting the code exists, and iterating by talking to the model. That is the extreme. This course teaches a safer version that still moves fast: you stay in the loop on every slice.

In practice, a user works like this: open a real folder in an agent editor or CLI agent, write one goal, attach the files that matter, ask for a plan, let the agent edit a small piece, read the patch, run a command, then commit or revert.How You Work is the full session guide.Tools is how you pick the editor or agent.

Vibe coding vs writing every line

When it works well

• Boilerplate: CLI setup, CRUD, tests, config, docs.
• Well-known patterns: a FastAPI route, a pytest file, a Pandas clean-up script.
• Refactors with a clear target: "extract this function, keep the tests green."
• Explaining unfamiliar code: "what does this module do, in 8 bullets."

When you should slow down

• Security, auth, payments, or anything that handles secrets.
• Unclear product: if you cannot describe done, the model will invent a product.
• Large rewrites across many files with no plan.
• Code you cannot read yet. Use the AI as a tutor, then write a smaller version yourself.

A tiny example

You could type this Python yourself. You can also prompt: "Write a function that returns the unique words in a sentence, sorted, ignoring case."

def unique_words(text: str) -> list[str]:
    words = text.lower().split()
    return sorted(set(words))

print(unique_words("Vibe vibe coding Coding"))
# ['coding', 'vibe']

Your job after generation: check the types, empty input, punctuation, and whether split() is enough. That review step is the skill.

What a user actually does

Forget the slogan. Here is the work, in order, every time:

1. Name the outcome — one sentence a teammate would accept as “done.”
2. Point at files — the module to change and the test that will prove it.
3. Constrain — language, no extra packages, files that are off limits.
4. Generate a small slice — not the whole product.
5. Read, run, keep or throw away — the chat summary is not evidence.

Key takeaways

• You direct. The model drafts. You own the outcome.
• It shines on boilerplate and clear, local changes.
• It fails when the goal is vague or you skip review.
• Next, learn the session rhythm in How You Work, pick a tool, then set up a practice folder.