What is the difference between agentic coding and vibe coding?
Agentic coding and vibe coding differ in what a person checks before accepting code that an AI wrote. In agentic coding, a person directs a coding agent through a planned task, reads its changes, and runs checks on them. In vibe coding, a person accepts the AI's code unread and judges it by using the app.
Both approaches can use the same coding agent. The difference sits in what the person adds around it, from checks written before the agent starts to review after it finishes. Some sources define agentic coding by the agent's autonomy instead. In that sense, a person who accepts an agent's code unread is vibe coding with an agentic tool.
Vibe coding suits software where a broken path costs little, e.g. a prototype that only its author runs. Agentic coding suits code that customers depend on or that other people will change later.
A third term, agentic engineering, names the wider discipline of building software with coding agents while keeping engineering practices. It differs from vibe coding in the same way, because a person reviews and tests the agent's output before it merges.
What is vibe coding?
Vibe coding is a way of building software in which a person describes the goal to an AI and accepts its code without reading it. Wikipedia's entry credits the term to Andrej Karpathy, who coined it in February 2025.
The work runs as a loop. The person writes a prompt, the AI changes the code, and the person tries the app. An error goes into the next prompt, and a change that looks right is accepted.
The only check is one look at the app, on the path the person tried. Vibe coding bugs usually sit on paths that nobody tried, e.g. a second user account. Nothing in the loop states what must stay true, so a later prompt can break what worked before. Code that grows through many unread changes can also turn into AI slop, which looks finished but is bloated or poorly tested.
What is agentic coding?
Agentic coding is building software by giving a coding agent a defined task and checking its work before anyone relies on it. The agent does most of the editing and running, and the person owns the goal and the checks.
A typical agentic coding task runs in 5 steps:
- The person writes the task and the checks the result must pass, sometimes as a short spec, the core of spec-driven development.
- The agent reads the relevant files and returns a plan, and the person approves or edits it. This approval point is a form of human-in-the-loop control.
- The agent edits the files and runs the tests. In test-driven development, the failing tests exist before the code does.
- The person reads the diff in code review, even when the tests pass.
- A continuous integration and delivery (CI/CD) pipeline runs the checks again, usually on a fresh machine, before the change merges.
The term also has a wider sense, based on autonomy. Some vendor glossaries use it for work that an agent plans and carries out with little human input. A 2025 review by Sapkota and colleagues contrasts the two on that basis. It treats vibe coding as conversational work driven by prompts, and agentic coding as work "with minimal human intervention." This page uses the narrower sense, in which a person plans the task and checks the result, because that is where the two differ in what gets verified.
How is agentic engineering related to agentic coding?
The two agentic terms overlap. When people separate them, agentic coding usually names one person's work with an agent on a single task. Agentic engineering names the wider practice around that work, e.g. the tests and review rules that apply to changes from any agent.
Simon Willison's guide to agentic engineering draws the line with vibe coding at review. He keeps the term vibe coding for unreviewed code of prototype quality, not for code that its author has brought up to a production standard.
When should a team use agentic coding or vibe coding?
Here is an illustrative example. Acme Co. sells furniture online, and a developer at Acme gets the request "Let customers edit their delivery address during checkout." The developer uses both approaches:
- The developer builds a clickable prototype by vibe coding on a throwaway branch, tries it once as a guest, and shows it to the product team.
- Nobody reads the prototype's code, which costs little because the branch is deleted after the demo.
- For the real change, the developer writes 2 checks first, one that the address saves and one that the cart keeps its items.
- A coding agent returns a plan that touches 3 files, and the developer approves it.
- The agent edits the code and runs the checks. The second check fails with the message "The address saved, but the cart emptied."
- The agent changes the address handler until both checks pass, and the developer reads the diff before it merges.
The prototype may have had the same bug, but no customer ever used it. Vibe coding fit the demo, and agentic coding fit the code that customers would use. The choice depends on who runs the code and what a missed bug would cost them.
This example is simplified. A real team would also run the checks again in its pipeline before the merge.
Can agentic coding and vibe coding be used together?
The two approaches are often used on different parts of the same work. A common pattern uses vibe coding to explore an idea and agentic coding to build the version that customers use. Mixing them does not remove the limits of either approach:
- Unread code stays unread. Code accepted without reading keeps its gaps when a project changes approach. If a prototype becomes the product, someone has to read it and add tests, or its shortcuts become technical debt.
- Agent-written checks share the agent's gaps. Tests that an agent writes from the same prompt as the code tend to miss the same cases. Teams that test AI-generated code add checks that the agent did not write.
- Review can turn into approval. A person who receives more diffs than they can read may approve them unread, which turns agentic coding back into vibe coding.
A run with gaps does not establish that the whole app works, whichever approach produced the code.
How do agentic coding and vibe coding compare?
The two approaches differ on these points:
| Point | Vibe coding | Agentic coding |
|---|---|---|
| How the goal is stated | A prompt that describes the result | A task with checks, sometimes a written spec |
| Who reads the code | Nobody | A person, in code review |
| Main check | One look at the app on one path | Tests, review, and pipeline runs |
| Where tests come from | Usually none exist | Written first or with the change |
| Speed to a first version | Faster, with fewer steps | Slower, because of review and checks |
| Where it fits | Prototypes and throwaway tools | Code that customers use or others maintain |
| Main risk | Bugs on paths nobody tried | Checks that share the agent's gaps |
| Skill it needs | Describing what the app should do | Reading code and designing checks |
Both approaches can produce working software, and both can ship a bug. The difference is how much evidence stands behind a change when it merges.
FAQs
Do both approaches use the same coding agents?
Both approaches can use the same coding agents, because the approach depends on what the person adds around the agent's work. Vibe coding accepts the output after one look at the app. Agentic coding adds checks before the agent starts and reviews the diff before it merges.
Which approach needs more tests?
Agentic coding needs more tests, because tests are one of the main ways it checks what the agent built. Some of them should come from outside the agent, because the agent's own tests tend to miss the same cases as its code. Vibe coding usually has few tests or none, and a look at the app takes their place.
Is agentic coding slower than vibe coding?
Agentic coding is usually slower to a first version, because a person writes the task, reads the diff, and waits for checks. Vibe coding skips those steps. The time it saves can return later as technical debt, when someone has to change code that nobody has read.
Who reads the code in each approach?
In vibe coding, nobody reads the code, and the person judges the work by using the app. In agentic coding, a person reads each change in code review before it merges. When diffs arrive faster than the person can read them, that review can turn into unread approval.