Vibe coding vs agentic coding: they measure different things

What is the difference between vibe coding and agentic coding?

People treat these as rival methods. They are not, because they answer different questions. Vibe coding answers: how much do I look at the code? Agentic coding answers: how much does the tool do on its own before it comes back to me?

Vibe coding is a stance. Andrej Karpathy coined it in February 2025 for a way of working where you give in to the flow, accept the AI’s changes and do not read the diffs. Agentic coding is a capability. An agent is software that calls a language model with your request and a set of tools, runs the tools the model asks for, and feeds results back until the goal is met. For the definitions in full, see what is vibe coding and what is agentic coding. This page is about how they relate.

How do the two fit together?

Draw two lines. One runs from “I review everything” to “I review nothing.” The other runs from “the tool suggests, I do” to “the tool does, I supervise.” Every way of working with AI lands somewhere on that grid, and the four corners have names, whether or not people use them.

The bottom right corner is where most of the current excitement, and most of the risk, sits. A tool such as Claude Code, which Anthropic describes as an agentic coding tool that reads your codebase, edits files and runs commands (Claude Code overview), can be used in either bottom corner. The tool does not decide. You do, by whether you read what it did.

That is why “vibe coding vs agentic coding” has no single winner. A better question is which corner fits the task in front of you.

Why did Karpathy propose “agentic engineering”?

A year after he coined “vibe coding,” Karpathy said the practice had moved on. As The New Stack reported in February 2026, he wrote that programming through LLM agents was increasingly becoming a default workflow for professionals, with more oversight and scrutiny. His preferred new name was “agentic engineering”: agentic because you are no longer writing the code directly most of the time but orchestrating agents who do and acting as oversight, and engineering to stress that there is an art, a science and real expertise to it (The New Stack).

So the two terms are partly a split of the same activity by seriousness. Vibe coding keeps its original meaning: casual, forgiving and suited to projects where a mistake is cheap. Agentic engineering names the disciplined version: same agents, but with specs, tests and review. Simon Willison, who has written widely on the subject, uses the same word for patterns of working with coding agents such as Claude Code and OpenAI Codex (Agentic Engineering Patterns). The terminology is still settling, so expect people to use these words loosely.

Which approach fits which task?

A rule that holds up: autonomy should rise with how well you can verify the result, and fall with how bad a wrong result is. If tests or a visible outcome prove the task is done, give the agent room. If you cannot tell whether it worked, keep it on a short leash.

How do you keep control when the agent does the work?

Using an agent does not mean giving up supervision. The tools have controls for it, and the right set depends on the corner you want to work in.

• Plan before edits. Claude Code’s plan mode lets it research and propose changes without editing your source; approving the plan switches to a mode where it starts editing (permission modes). Other tools have similar read-only or planning modes.
• Choose how often it asks. The same page describes modes that auto-approve file edits or allow only pre-approved tools. Pick the strictest one that does not make you click through every step.
• Give it a check to run. Anthropic’s guidance for Claude Code is to give the agent a way to verify its own work, such as tests (best practices). The principle comes from Anthropic’s earlier agent guide, which says agents should gain “ground truth” from the environment at each step, such as tool results or code execution, and pause for feedback at checkpoints, with stopping conditions such as a maximum number of iterations (Building effective agents).
• Watch the first minute. Claude Code’s documentation advises pressing Esc the moment the agent drifts, and after two failed corrections clearing the session and writing a better prompt.
• Make undo cheap. Commit before a big task. Claude Code also offers a rewind menu that restores code, conversation or both to an earlier point.
• Separate development from production. An agent should never hold the keys to the live database. The July 2025 Replit incident, in which an agent deleted a production database during a code freeze, is the standard reminder (The Register).

What does a good brief for an agent look like?

The agentic style rewards a different prompt from a casual chat. A chat prompt can be loose because you will react to each reply. An agent may run for minutes and touch many files, so the brief has to carry the goal, the limits and the finish line.

Goal: [one sentence describing the end state, not the steps]

Context: [where the relevant code lives; anything not obvious from the code]

Constraints:
- Only change files in [folder or list]
- Do not add new dependencies
- Do not touch [migrations / config / secrets]

Done means:
- [a test or command that must pass]
- [a behavior I can check by hand]

Process:
1. Read the relevant code and write a short plan. Stop and wait for my approval before editing.
2. After approval, work in small steps and run the check after each one.
3. If the check fails twice in a row for the same reason, stop and tell me what you tried instead of trying a third time.

When finished: list the files you changed, summarize why, and say what you did not verify.

The same brief works with vibe coding habits if you choose not to read the diff. It will still reduce the chance of an unwelcome surprise. The parts that decide quality, a written goal and a checkable finish, belong to spec-driven development. The way the agent uses what you give it is covered in context engineering.

How should a beginner approach the choice?

1. Start with a small project and an agent in the casual corner. Let it build, and judge the running result. This is vibe coding with an agent, and it teaches what the tool can do.
2. Add one control at a time. First commit before each task. Then ask for a plan. Then ask for a test that proves the feature.
3. Move toward review as stakes rise. When strangers will use it, begin reading the diffs of the risky parts.
4. Name your corner for each task. Before you prompt, say to yourself: autonomy high or low, review light or close. It takes five seconds and prevents most nasty surprises.

If you need a small project to practice on, pick one from the board of app ideas, such as a tool that finds which of your abandoned repositories is closest to finished, and see how far a plan-first run gets. The terms will matter less than the habit.