Blog

Vibe coding and agentic coding differ in who proves the work right

The two terms are used as if they meant one thing. They differ in what happens after the code is written, not in which tool you open.

A line drawing of two paths: a straight dashed line with no checkpoints, and a loop with four checkpoints.

Picture the same job done twice: an AI builds one web page in a single afternoon. The code that comes back may even look identical. What separates vibe coding from agentic coding is not the code that gets written. It is what happens after.

The two terms get used as if they meant one thing, coding with an AI. They are two ways of working, and they give very different results once someone has to depend on the code. We build client websites with Claude Code and Codex every day, so here is where we think the line falls, and when to use which.

Vibe coding originally meant not reading the code

The term comes from a post by Andrej Karpathy in February 2025. He described a way of programming where you “fully give in to the vibes” and “forget that the code even exists”: press Accept All every time, stop reading the diffs, paste error messages back to the AI with no comment. He also said it suits throwaway weekend projects.

So the original meaning is narrow: writing without checking, and without caring what the code looks like. As the term spread, people began using it for any coding with an AI. That is where the confusion starts, because using an AI and reading every line is not the same as not reading at all.

Agentic coding is a loop with a check that can fail

Agents such as Claude Code and Codex work in a loop. They read the existing code, make a plan, edit files, run real commands such as a type check, the tests and a build, read the output and keep fixing until it passes. A person sets the goal and the limits, and reads the result before it ships.

What makes it agentic is not that the AI acts on its own. It is that the loop contains a check that can really fail. Without one, the agent just keeps writing, the same as before but faster. Three things have to exist.

  • A written goal: what you want, why, and what must not happen, kept in a file the agent reads every time, such as AGENTS.md or CLAUDE.md.

  • Checks that can fail: commands that tell you when something broke, such as a type check, the tests and a build.

  • A person who reads the diff before it merges and answers for what ships.

The difference is who proves the work right

The same tool can be used either way. The difference is what proves the code right once it is written.

A diagram comparing two loops. Vibe coding goes from prompt to accept all, run and ship, and loops back to the prompt when an error appears. Agentic coding goes from goal and rules to plan, edit, run checks, a person reading the diff and ship, and loops back to edit when a check fails.
The two loops. On the left, running it and seeing whether it breaks is the proof. On the right, checks and a reader come before it ships.

Ask three questions about a piece of work that has just been finished.

Who says it is done

In vibe coding, it is the feeling that the screen looks fine. In agentic coding, it is a passing check and a diff someone has read.

What stops a wrong change

In vibe coding, it is your own eyes. If it breaks somewhere you cannot see, such as a calculation, a user’s permissions or a case that rarely happens, nobody knows until somebody hits it. In agentic coding, it is the checks written beforehand and the person reading the diff.

What the next person finds

That person is often you in three months. In vibe coding you find code nobody has read. In agentic coding you find code someone has read, a rules file, and tests that tell you what broke.

An example from our own site

The desktop PageSpeed score of this site sat between 45 and 57 because of the 3D scene on the home page. PageSpeed’s lab has no GPU, so the browser has to create WebGL in software, which takes about a second just to make the context and blocks the page for all of it. WebGL’s failIfMajorPerformanceCaveat option does not catch that case either.

For the mobile score, the first guess anyone makes is that the intro runs too long. Take the first suggestion, press Accept All, and it is done in five minutes and looks fixed. We measured instead. The full intro at 2.8 seconds, a short one at 1.6 and a compressed one at 1.9 all gave the same score. The guess was wrong.

That measurement went into the project’s AGENTS.md as one sentence: do not shorten the intro for the score. Whoever picks the work up next, person or agent, does not have to run it again. The GPU problem was fixed at its cause, by letting a small Web Worker try to create WebGL instead of the page, and report back whether the machine has a GPU.

There is a flip side. We once built a price estimate page and took it off the same day, because in use it did not do what we needed. Agents make it much cheaper to build something and to take it back out, but no check will tell you which page should exist. That is still a person’s call.

Which one, and when

Vibe coding is not bad. When the thing is a prototype you will throw away, a personal tool that bothers nobody when it breaks, or an idea you are testing before deciding to build it for real, speed is worth more than care. The line is whether anyone has to depend on the code, including yourself in three months.

When money, user data or access rights are involved, or the code will be changed for a long time, use agentic coding. Know that it is not a shortcut. Writing the rules file, building the checks and reading the diffs take real time, and agents still slip: they can make a test that is too weak pass instead of meeting the intent, or change more than they were asked to. So the checks have to be good enough, and the diffs small enough for a person to read.

Where to start without buying anything

  1. Write one rules file. Say what this code must not do, with the reason, and add a line each time the same mistake happens twice.

  2. Make one command that checks everything, and make sure it can fail. Break something on purpose and see whether it notices.

  3. Read the diff before every merge. If it is too big to read, ask the agent to split the work into smaller pieces.

That is why we read every line that goes on a client’s site. Not because we distrust the AI, but because someone has to answer for what ships.

More articles

See all articles

ติดต่อContact

Want a website designed like this?

Tell us your brief and we'll reply with a scope and the package that fits.