Vibe coding vs agentic engineering: same models, different results

Two people open the same tool with the same model. One describes an app, accepts every change, pastes errors back in until the screen looks right, and ships it by the evening. The other writes a short spec, lets the agent plan, has the plan challenged, runs the checks and has a second model review the diff. Both say they “built it with AI”. Six weeks later, only one of them can still change their code without fear.

The difference has a name now. The first is vibe coding. The second is what Andrej Karpathy, who coined the first term, proposed calling agentic engineering. The models are the same. What changes is everything around them.

What vibe coding actually means

Karpathy’s original post, on 2 February 2025, described “a new kind of coding” where you “fully give in to the vibes, embrace exponentials, and forget that the code even exists”. He was explicit about the scope: “throwaway weekend projects”. He wrote that he accepts every change and no longer reads the diffs, pastes error messages back in with no comment, and when a bug won’t go away, works around it or asks for random changes until it does.

The term escaped its origin fast. Collins named it word of the year for 2025, and within months “vibe coding” meant almost any use of AI to write code, which made it useless for discussion. So it helps to go back to the original meaning: you accept code you haven’t understood, and your only check is whether the thing appears to work.

Professional developers mostly don’t do this at work. In Stack Overflow’s 2025 survey, 72% said vibe coding is not part of their professional work and another 5% said so emphatically.

What agentic engineering adds

On 4 February 2026, almost exactly a year later, Karpathy offered “agentic engineering” as his favourite name for the professional version. “Agentic” because the new default is that you are not writing the code directly 99% of the time. “Engineering” because there is an art, a science and expertise to it. The stated goal is to get what agents offer without any compromise on the quality of the software.

In practice that discipline is a short list of things vibe coding skips:

1. A spec or at least acceptance criteria written before code.
2. A plan that someone, or something, challenges before implementation.
3. Checks that the system runs, not the agent: build, tests, the criteria as commands.
4. A reviewer that is not the writer, reading the actual diff.
5. Limits on rounds, time and money, with a person called in for real decisions.

None of these make the model smarter. They make its mistakes visible early and cheap.

	Vibe coding	Agentic engineering
Input	A wish in a chat	A spec with checkable criteria
Who reads the code	Nobody	A reviewer agent, and a person where it matters
Definition of done	“It looks like it works”	Commands that pass, evidence recorded
Errors	Pasted back until they disappear	Traced to a cause, fixed, covered by a check
Good for	Prototypes, one-off scripts, learning	Code that lives, scales or touches users’ data
Main risk	Hidden bugs and security holes	Up-front time on the spec

Why vibe-coded software breaks later

The code an agent writes when nobody is reading is not worse because the model is careless. It is worse because nothing pushes back on it.

Security is the clearest example. Veracode tested more than 100 language models on 80 code completion tasks chosen to have known security pitfalls. In 45% of test cases the models introduced vulnerabilities from the OWASP Top 10. Java was the worst, with a failure rate over 70%. And the larger and newer models were not meaningfully better at security than the smaller ones. If your process relies on the model getting security right by itself, it will be wrong close to half the time on exactly the code where it matters.

The other problem is slower. Vibe-coded projects accumulate code that nobody understands, so every change is another round of “paste the error back in”. The prototype was fast. The fifth feature is slow, and the tenth is a rewrite.

The same model, three setups, three results

The clearest evidence I have that process matters more than the model is a benchmark I ran and published. One task: rebuild a mobile game from a video of someone playing it, with no hints afterwards. The same model wrote code in all three setups. What changed was what happened around it.

One task, same writer model, three setups

Wall-clock time to finish

Data as a table

	Value
Claude Code alone	3.7 h
Claude plus one review at the end	4.2 h
Two independent plans before code	1.5 h

Claude alone left about 13 bugs, counted by hand by playing the game. One review at the end cut that to about 7 but made the run longer, because the plan was already set and the review rounds went into pulling it back. When two models wrote independent approaches before any code existed and only the material disagreements were resolved, the run took 1.5 hours, processed 34 M tokens instead of 389 M, and finished with no broken mechanics.

It is one task, and I describe its limits in the write-up of the review loop. But the direction is consistent with everything else I see: the cheapest place to catch a mistake is before the code exists.

When vibe coding is the right choice

I don’t think vibe coding is bad. It is a tool with a narrow use, and inside that use it is excellent.

When to vibe code and when to engineer

Data as a table

Item	Cost of a mistake	How long the code lives
Demo for a meeting	Low	Hours
One-off data script	Low	Hours
Internal dashboard	Low	Years
Payment flow	High	Years
Auth or user data	High	Years
Prototype to test idea	High	Hours

Prototypes that exist to answer a question, scripts you run once, a demo for tomorrow’s meeting, learning a new framework: vibe code all of it. The bottom right corner is the interesting one. A prototype that tests a risky idea can be vibe coded, but only if you commit to throwing it away. The failure is not vibe coding. It is a vibe-coded prototype quietly becoming the product.

How to move from vibe coding to agentic engineering

You don’t need a platform to start. You need a few habits, added in this order because each one makes the next one cheaper.

1. Write the criteria first. Three to ten lines on what done means, each with a command that proves it. See acceptance criteria an agent can’t talk its way around.
2. Ask for a plan before code. Read it, or have a second model read it and list only the points where it disagrees. Most bad starts die here.
3. Let the system run the checks. The agent may claim tests pass. The build and the test runner decide. A Stop hook that refuses to end the turn while checks fail does this in Claude Code.
4. Separate the writer from the reviewer. A different model, or at least a fresh context, reads the diff and the evidence. More in why the writer can’t be the reviewer.
5. Put limits on everything. Rounds, time, spend, and a rule that sends a stuck run to a person.

This is more work up front than typing a wish into a chat. It is a lot less work than the fifth feature on a codebase nobody understands. And it is the version that scales: one engineer with a spec and a good harness can keep several agents busy on real products, which vibe coding never allows, because a vibe coder can only watch one screen.

My bet is that within a couple of years “agentic engineering” will just be called engineering, the same way “web development” stopped needing the word “web”. The models will keep getting better. The teams that ship will be the ones that put checks around them.

Questions

What is the difference between vibe coding and agentic engineering?

Vibe coding means accepting AI-written code without reading or verifying it. Agentic engineering uses the same models inside a process with specs, automatic checks, independent review and limits, with the developer acting as orchestrator and reviewer.

Who coined vibe coding?

Andrej Karpathy, in a post on 2 February 2025. About a year later he proposed “agentic engineering” for the professional, supervised version of building software with agents.

Is vibe coding bad?

No, it is fine for prototypes, demos and one-off scripts where a mistake is cheap and the code won’t live long. It becomes a problem when that code turns into a product without anyone reading or testing it.

Is AI-generated code secure?

Not by default. Veracode found that models introduced OWASP Top 10 vulnerabilities in 45% of security-sensitive tasks, and bigger models were not much better, so security has to come from checks and review rather than from the model.