Vibe coding vs agentic engineering: what's the difference?

Vibe coding means you prompt an AI and accept the output once it looks finished. Agentic engineering uses the same AI agents inside a system: a spec, tests, hooks, a review gate and a person who merges. Same model, same AI. The difference is a closed loop around it, and that loop decides whether the code survives production.

We work this way every day. AI writes all of our code today, and a senior is accountable for what reaches production. This article follows a LinkedIn carousel Filip posted in May 2026, with the code we run behind each claim.

What is vibe coding, and what is agentic engineering?

Andrej Karpathy coined "vibe coding" in February 2025: you give in to the vibes and forget the code even exists. Simon Willison draws the line clearly in his Agentic Engineering Patterns guide: "I use the term agentic engineering to describe the practice of developing software with the assistance of coding agents." Vibe coding, in his narrower sense, is unreviewed, prototype-quality code. Agentic engineering is code brought to a production standard, with review and verification.

The top results for this question stop at the definition. Here is the difference as we see it in a repository:

Why is working code not the same as production software?

AI broke the syntax barrier. Anyone can describe what they want and get code that runs. That is real, and we use it every day.

But working code and production software that runs your business are two very different things. Production software has users who type the wrong thing, data that must not leak, payments that must add up, and a next developer who has to understand it. A demo has none of that. It only has to work once, on one laptop, while someone watches.

Our longer take on that gap, for founders, is in Vibe coding to production: what the prototype is missing.

What breaks without a system around the AI?

Six things, in the order they usually bite:

• No closed loop. The output goes straight to "accept". Nothing runs it against a test before a person decides.
• No guardrails. The agent can run any command it thinks is useful, including the ones you would never allow.
• No boundaries. No architecture rules, so every session invents its own structure.
• No learning. AI can't learn from its own mistakes without a system. The same bug comes back next week, because nothing turned last week's fix into a rule.
• Accepting output that looks finished. A green-looking UI is not a passing test suite.
• No expert judgment. Nobody who understands the domain is steering toward the right result.

None of these is a model problem. A stronger model makes the output look even more finished. The fix is around the model, not inside it.

What does a closed agentic loop look like?

In our repositories one task runs through one loop: spec, AI agent, gate, fix, merge. It is wired by wizrd, our internal Claude Code plugin and CLI (not public). The design rule sits at the top of the dispatcher:

# Deterministic on purpose: code decides WHAT to take and WHEN it is done, models only do the work.

The gate is a bash script, gate.sh. It runs the repository's own typecheck, lint, test and build scripts, then a red-proof check: new tests must fail on the base branch, or they prove nothing. Exit 0 is green, exit 1 is red. A model never grades this part.

The same gate runs inside the agent's session as a Claude Code Stop hook. When the agent tries to finish while checks are red, the hook blocks the stop and hands it the failures. Shortened:

bash "$HARNESS/loop/gate.sh" "$type" "$tree" "$base" "$out" "$W" && exit 0
jq -n --arg r "Executable checks are red. Fix this before you finish:
$(head -c 3000 "$out")" '{decision: "block", reason: $r}'

After the gate comes a fresh reviewer, a model call with read-only tools, told that it did not do the work and that its job is to try to refute it. One line keeps it honest:

[ "$mrc" != 0 ] && [ "$verdict" = pass ] && verdict=fix   # a red executable check is never overruled to pass

Findings go back into the same agent session. That is the "fix" arrow. When the reviewer reports the same finding twice in a row, the loop stops and a person gets the task with that finding attached. The whole loop, stage by stage, is in Harness engineering in practice: from issue to PR.

Is anyone outside your repos doing this?

Yes, at a much bigger scale. On February 11, 2026, OpenAI described a product its team built with Codex: roughly a million lines of code, about 1/10th of the time by their estimate, and zero lines of manually written code. Their point matches the carousel's: not better prompts, a better system around the same AI everyone has. Rules, linters, structural tests and feedback loops.

What is the real difference between the two?

Put the two products side by side a few months after launch.

Same AI in both columns. One has a system, the other does not. The model you rent is the same one your competitors rent, so it cannot be your advantage. What you build around it can.

How do you move from vibe coding to agentic engineering?

Start with the gates, not with a smarter agent. In the order we would add them:

Each step closes one of the six gaps above. Rules give boundaries. Hooks give guardrails. Red-proof tests and the gate close the loop. And when the same mistake shows up twice, it becomes a new rule or check, which is how the system learns instead of the model.

We collected the first four in a small public repository, the Claude Code production starter: agent rules, hooks, a CI gate with red-proof tests, AI review and a launch checklist. MIT licensed. Two details worth reading before you copy hooks: Claude Code hooks that silently do nothing and red-green TDD with AI agents.

Is your team vibe coding or engineering?

A quick self-test. Tick what your repository has today.

Want this system in your repository?

We set up this kind of loop inside a team's own repository as part of AI-native SDLC for development teams. Since 2023 we have delivered 15+ production projects. A senior plugs into your repository and pull requests on day one.

Built a product with Lovable, Cursor or Claude yourself and now it has to hold up? That is a different path: see help for vibe coders.

We get back to you within two business days, and together we pick what to fix first.

If you'd rather talk first, book a 15-minute meeting with Filip.

Which of the six gaps hurts your team most right now?

Frequently asked questions

What is the difference between vibe coding and agentic engineering?

Vibe coding means prompting an AI and accepting output that looks finished. Agentic engineering uses the same AI agents inside a system: a spec, tests, hooks, a review gate and a person who merges. The model is the same. The system around it decides whether the result survives production.

Is agentic engineering the same as agentic coding?

Mostly the same idea. Agentic coding usually means an AI agent that edits files and runs commands on its own. Agentic engineering adds the discipline around it: what counts as done, which checks must pass, and who is accountable for what reaches production.

What is an agentic loop in software development?

A loop where the agent works, a machine checks the result, and a red check sends the finding back to the agent until it passes. Ours runs spec, agent, gate, fix, merge. The gate is plain code with exit codes, so a model cannot talk a red check into green.

Is vibe coding bad?

No. It is a fast way to try an idea or build a demo. It becomes a problem when a demo starts to run a business: real users, real money, real data. That is where you need tests, guardrails and a person who understands the code.

How do I move a team from vibe coding to agentic engineering?

Start with the gates, not the agent: agent rules in the repository, hooks that block dangerous commands, a Stop hook that refuses "done" while checks are red, and a CI gate with tests that must fail before the fix. The public Claude Code production starter has all four.