Guide · Enterprise vibe coding

Vibe coding vs agentic engineering: the same agents, held to different standards.

Both hand the typing to AI. Vibe coding judges the result by whether it seems to work. Agentic engineering plans the work, delegates it to agents, and verifies every change before it ships.

A year after coining “vibe coding”, Andrej Karpathy picked “agentic engineering” as his favourite name for the disciplined version: people orchestrating coding agents and acting as oversight. This guide explains both, the loop and practices that separate them, and what the evidence says about each.

Updated · 8 sources

judged by feel

Vibe coding

Describe, accept every change, run it, paste the error back. The code itself is never read.

  • No plan beyond the prompt
  • Success means “it seems to work”
  • Changes accepted unread
  • Right for throwaway work
judged by evidence

Agentic engineering

Write the goal and the checks first, let agents do the work, and accept only what passes tests and review.

  • A plan and acceptance tests up front
  • Success means the checks pass
  • Every change reviewed and explainable
  • Right for software people depend on
AI agentsWho types the codeAI agents
The feeling that it worksWho decides what “done” meansTests, specs and a reviewer
Prompts and retriesWhat a person doesPlans, delegates, verifies, reviews
OptionalVersion controlEvery change a reviewable diff
Paste the error backWhen it breaksA failing test names the cause
UnclearAccountabilityA named engineer merges and owns it

Vibe coding vs agentic engineering: what is the difference?

In vibe coding vs agentic engineering, AI agents write the code in both; the difference is oversight. Vibe coding accepts changes without reading them and stops when the app seems to work. Agentic engineering — the name Karpathy backed in February 2026 — has a person plan the work, orchestrate agents to do it, and verify each change with tests and review before it ships.

Twelve months of vocabulary

How vibe coding turned into agentic engineering in a year.

Both terms were popularised by the same person, a year apart, and the gap between them was filled by practitioners drawing a line between prototyping and professional work.

  1. Feb 2025Vibe codingKarpathy: “fully give in to the vibes … forget that the code even exists.”
  2. Mar 2025The line is drawnSimon Willison: vibe coding means not reviewing the code; reviewed AI-assisted work is something else.
  3. Jul 2025Feel versus measurementA randomised study finds experienced developers slower with AI while believing they were faster.
  4. Oct 2025Vibe engineeringWillison names the disciplined end: professionals who stay accountable for AI-written software.
  5. Feb 2026Agentic engineeringKarpathy: you are “orchestrating agents who do and acting as oversight”.

Karpathy explained both halves of the new name. Agentic, because the new default is that people do not write the code directly “99% of the time” — they orchestrate agents that do. Engineering, because doing that well takes art, science and expertise. The agents did not change between the two terms; the expectations on the person did.

How the work runs

The agentic engineering loop: plan, delegate, verify, review.

Vibe coding loops on errors: run, see what breaks, paste it back. Agentic engineering loops on evidence, with the checks written before the agent starts.

One change, the agentic way
  1. PlanState the goal, the constraints and how success will be checked.
  2. DelegateHand the task to one or several agents, each in its own branch or sandbox.
  3. VerifyTests, type checks, linters and security scans run on every change.
  4. ReviewA person reads the diff and can explain it before it merges.
  5. Ship and watchDeploy to a preview first, then production, with a way back.

What the review or the tests turn up becomes the next plan, so each round leaves the codebase better described and better tested.

What separates them

Vibe coding vs agentic engineering, practice by practice.

Willison’s point in 2025 was that coding agents reward the practices good teams already had. Each one turns an agent’s output from a guess into something checked.

Practices agentic engineering depends on
  • Automated testsAn agent can run them after every change, so “done” is measured rather than felt.
  • Planning in advanceA written plan gives the agent the goal and the reviewer the yardstick.
  • Documentation in the repositoryConventions and context the agent reads before it starts.
  • Version controlEvery change is a diff that can be reviewed, reverted or compared.
  • Continuous integrationThe same checks on every branch, whoever or whatever wrote it.
  • Code reviewA person reads and can explain each change before it merges.
  • Preview environmentsChanges run somewhere safe before production sees them.
  • Knowing what to delegateRoutine, well-specified work to agents; judgement calls to people.
Why oversight matters

What studies say about agents left without oversight.

The case for the engineering half rests on measurement. When AI coding is judged by feel, people misjudge both speed and safety.

19%
slower: experienced developers took longer with AI tools, yet afterwards believed they had been 20% faster
METR randomised study, 2025
11.8%
of one agent setup’s solutions were secure, though 57% worked — 186 tasks from real projects
Zhao et al., SusVibes, 2025
77.5%
of developers say vibe coding is not part of their professional work
Stack Overflow Developer Survey, 2025

How to read the speed figure. The METR study measured 16 experienced developers on 246 tasks in their own mature open-source projects, with early-2025 tools. It does not show that AI makes everyone slower; it shows that self-reported speed-ups are unreliable, which is the argument for measuring.

What people do

What an engineer does when agents write the code.

The work moves up the stack. Each layer is something an agent cannot supply for itself.

The engineer’s layers of work
01
Define the outcomeWhat should exist, for whom, and how you will know it works.
specacceptance tests
02
Shape the contextThe conventions, documents and examples the agent works from.
context
03
OrchestrateSplit the work and run agents on the parts, often in parallel.
agents
04
VerifyMake the checks strict enough that passing them means something.
CIscans
05
Review and ownRead every diff, merge it under your name, and roll it back if needed.
accountability

Will anyone depend on this code after today?

NoVibe coding is fine. Explore, demo, learn — then throw it away.
Yes, engineers own itAgentic engineering. Plans, tests, CI and review on every agent change.
Yes, a business team owns itA governed platform, so the oversight is built into how the app is made rather than left to the team.
On Botminds

How Piper brings agentic engineering to business solutions.

Piper, the Botminds builder, works the agentic way — plan, act, verify — on business solutions rather than codebases. A page or an agent is built in the conversation; a whole solution goes to a dedicated builder that works through it in phases while you watch.

  1. Brief

    Confirmed in the conversation, assumptions stated.

  2. Documents

    Requirements and user stories you can read.

  3. Prototype

    A clickable prototype to approve before building.

  4. Build

    Data, agents, workflows and pages, phase by phase, each checked.

    read back
  5. Repository

    Saved as a package in a repository of its own.

    versioned

The engineering half, built in

  • Approval firstNothing shared changes before your yes; deletes get their own confirmation.
  • Verified changesEach change is read back to confirm it landed, and what was built is tested.
  • ResumableAn interrupted build resumes from its last finished step, with spend tracked.

Oversight without writing code. You steer or stop the build at any point and ask Piper where it stands. Every change runs as you and is recorded. Read the full design in enterprise vibe coding, or compare with a coding assistant in Botminds vs Cursor.

Questions people ask

Vibe coding vs agentic engineering: common questions.

The technology behind itEnterprise vibe codingGoverned apps, built by conversation
What is the difference between vibe coding and agentic engineering?

In vibe coding vs agentic engineering, AI agents write the code in both. Vibe coding accepts their changes unread and stops when the app seems to work; agentic engineering plans the work, orchestrates agents, and verifies every change with tests and review.

What does agentic engineering mean?

Building software by orchestrating AI coding agents rather than typing the code yourself, while staying responsible for the result. Karpathy chose “agentic” for the orchestration and “engineering” for the expertise that doing it well requires.

Who coined the term agentic engineering?

Andrej Karpathy popularised it in a post on X on 4 February 2026, a year after he coined vibe coding. Others had been proposing names for professional work with coding agents; he called “agentic engineering” his current favourite.

Is agentic coding the same as vibe coding?

Agentic coding describes the tool: an agent that edits files, runs commands and iterates on its own. Vibe coding describes an attitude: accepting the result unread. You can use a coding agent either way.

What is vibe engineering?

Simon Willison’s October 2025 name for the opposite of vibe coding: experienced engineers using AI to go faster while staying accountable for the software. It covers the same ground as agentic engineering.

Does agentic engineering make developers faster?

It can, but measure it. In METR’s 2025 randomised study, experienced developers were 19% slower with AI tools on their own projects while believing they were 20% faster. Track cycle time and defects, not impressions.

Is vibe coding dead?

No. It remains a good way to prototype, explore an idea or build something for yourself. What changed is the vocabulary: work that others depend on now has its own name and its own standards.

Do you still need to read the code in agentic engineering?

Yes. Willison’s rule is to commit nothing you could not explain to someone else. Tests and scans narrow what a reviewer must check, but a person still owns the merge.

See it on
your own work.

Bring one process and its documents. We’ll show you the agents, the controls and the record, running on your data.