Vibe coding vs agentic coding: who verifies the code

Vibe coding is accepting whatever the AI generates without reading the code; agentic coding (or agentic engineering) is delegating the execution to coding agents while you keep the judgment: what gets built, how it gets checked, who reviews it and who answers for it if it fails. The tool can be exactly the same. What changes is who verifies.

If you build software with AI and you are not sure which of the two you are doing, the table and the questions below will tell you in a minute.

Vibe coding vs agentic coding at a glance

	Vibe coding	Agentic coding (agentic engineering)
What you do with the code	You accept it without reading it	You delegate it, but you read the diff or check it with tests
How you ask	One sentence in the chat, and you see what comes out	A brief with a goal, limits, an acceptance criterion and a way to check it
Who verifies	Nobody, or you trying it by eye	The tests and a review you do yourself
What you hand over	Something that seems to work	Something you can explain and that fails visibly if it breaks
If it fails in production	You have no idea where to start looking	There is a test or a spec that says what should have happened
Where it fits	Prototypes and throwaway things	Anything other people will use or maintain

What is vibe coding and who came up with it?

Vibe coding is a way of programming with AI where you stop looking at the code. Andrej Karpathy coined it in a tweet on 2 February 2025: “There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists”^[1].

What he described was very concrete: he always hits “Accept All”, he no longer reads the diffs (the list of lines the agent changed) and he pastes errors into the chat with no comment. And he set its ceiling himself: “not too bad for throwaway weekend projects”, reasonable for disposable projects^[1].

Notice that the definition revolves around no longer looking at the code, not around using AI or around it being a bad thing. That is why using a coding assistant does not make you a vibe coder by itself: what does is no longer reading what it hands back.

Where does “agentic coding” come from, and how does it relate to vibe engineering?

The names on the other side are not settled yet. In February 2026, Karpathy said his favorite name for the contrast was agentic engineering: “agentic because the new default is that you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight”^[2]. In other words, you almost never write the code directly: you orchestrate agents that write it and you supervise. The “engineering” part was there to stress that it is a craft you can learn^[2].

Earlier, in October 2025, Simon Willison had proposed vibe engineering for the same ground: against “irresponsibly building software through dice rolls, not caring what code is produced”, the responsible use of assistants by experienced engineers, with tests, planning, documentation and review^[3].

Agentic coding, agentic engineering and vibe engineering overlap and nobody has standardized them, so it pays to hold on to the practice and not the label. And if the comparison you are after is vibe coding vs software engineering: software engineering is the whole craft (understanding what is needed, designing, testing and maintaining), vibe coding is a way of producing code that skips that part, and directed agentic work is still doing engineering, with agents typing for us.

Which one are you doing? Four questions

Answer them about the last thing you built with AI:

Did you read the diff before accepting it?
Could you explain to someone what that change does and why?
Is there something, a test or an automatic check, that would turn red if it broke?
Do you know which data or permissions it touches?

If you answered no to almost all of them, you were vibe coding, and that is fine as long as little is at stake. The trouble comes when that code stays around and someone else depends on it.

The difference already shows in how you ask for things. An example message, made up for illustration:

Vago: "Hazme el login con Google."

Dirigido: "Añade login con Google en la ruta /auth. No toques el modelo de
usuarios. Está listo cuando un usuario nuevo se crea una sola vez aunque
pulse el botón dos veces, y hay un test que lo comprueba."

In English: the vague one says “Build me the Google login”; the directed one says “Add Google login on the /auth route. Don’t touch the user model. It’s done when a new user is created only once even if they click the button twice, and there is a test that checks it.”

The second one is better because it has an acceptance criterion, the condition that has to be met to call the task done, and you can check it without trusting a feeling. How much you can hand over to an agent depends on how much you can check, and I develop that in the delegation gap between using AI and truly delegating. And if you want that criterion to survive from one session to the next, you write it down: I explain it in how to turn the spec into the team’s memory with spec-driven development.

Are prompt engineering and context engineering the opposite of vibe coding?

No, they measure something else. Prompt engineering and context engineering are about how you feed the model: what you tell it and what it sees at each step. Vibe coding versus agentic coding is about whether you verify what comes out. They are two different axes.

You can give an agent a perfect context and accept everything without reading, which would be very well-fed vibe coding, or write mediocre prompts and review every diff, which is already directed work. Good context helps the agent get it right, but it does not replace checking. Each axis has its own guide: prompt engineering patterns for developers and context engineering, the skill of governing what the model sees.

When does each one fit?

Vibe coding fits a prototype or a script you are going to throw away, as long as it does not touch other people’s data or money and you rewrite it if it moves forward. Directed agentic work is what you need when someone else is going to use the result, when it has to be maintained, or when you will have to answer for what it does.

In both cases we answer for the result. The only thing that changes is whether we have a way to show that it works. If you want to practice that part, we work on it with exercises in the course Design Patterns for AI Agents.

Sources

«Vibe coding» — Andrej Karpathy (X) — tweet of 2 February 2025 that coins the term, with “Accept All”, unread diffs and “throwaway weekend projects”.
Karpathy’s retrospective (X) — tweet of 4 February 2026 where he proposes “agentic engineering”.
Vibe engineering — Simon Willison — proposal of 7 October 2025 (tweet).

Frequently Asked Questions

What is vibe coding in one sentence?

Programming with AI by accepting the result without reading the code. Andrej Karpathy defined it in February 2025.

Are vibe coding and agentic coding the same thing under another name?

No, although they often use the same tools. In vibe coding you accept the result without reading it; in agentic coding you delegate the writing, but you define the goal and the acceptance criterion, and tests or a review verify the result before it is considered good.

Is vibe coding the same as vibe engineering?

Almost the opposite. Simon Willison proposed “vibe engineering” to separate the responsible use of coding assistants, with tests, planning, documentation and review, from vibe coding, which he described as building software by rolling the dice without caring what code comes out.

Can a junior do vibe coding?

For learning and for prototypes, yes. The risk is that, without experience, you lack the means to judge what you accept, so it pays to build the habit of reading the diff of what matters to you, asking for a test alongside every change and asking the agent to explain whatever you do not understand.