What’s the Difference Between Vibe Coding, Vibe Engineering, and Agentic Coding – and Why Does It Matter?

Three labels now compete to describe the same visible act, typing a request to a model and getting code back, and the one you pick quietly decides what you are willing to ship.

Where vibe coding actually started

Andrej Karpathy coined vibe coding in February 2025, describing a mode where you fully give in to the vibes and forget that the code even exists. The point was never careful review. You say what you want, you keep what runs, and you move on. It became practical because models wired into editors got good enough to hold a tight feedback loop together without a human reading every line.

Simon Willison later sharpened the definition to something testable: if you review every line the model writes, you are not vibe coding. That single criterion moves the boundary away from which tool you use and onto whether you actually verify the output.

Vibe engineering points the other way

In October 2025, Willison proposed vibe engineering for the disciplined opposite of that. Here experienced engineers move faster with LLMs while staying fully accountable for what the software does in production. The work rewards the habits senior developers already prize: automated tests the agent can run in a loop, a written plan before any code exists, documentation the model can read instead of guessing at, and tight version control so a bad change is trivial to trace and revert. None of it is loose. You end up researching approaches, defining success criteria, reviewing generated diffs almost constantly, and managing what amounts to a squad of fast, literal-minded interns that will cut corners the moment you stop watching. The name is deliberately half a joke, and Willison has since noted the field is drifting toward agentic engineering as the label that survives.

Vibe coding and vibe engineering are not two products. They are two postures toward the same tools, separated by how much responsibility the human keeps.

Agentic coding is machinery, not mood

Agentic coding sits on a completely different axis.

Where the two vibe terms describe your posture, agentic coding describes what the tool mechanically does. An agent breaks a task into steps, decides the next action, calls external tools, inspects the intermediate result, and rewrites its own plan when something fails. Claude Code, OpenAI’s Codex CLI, and Gemini CLI all shipped during 2025 around exactly this loop, and most current AI coding tools now treat it as the baseline rather than a feature. The model is no longer completing a line; it runs a goal-seeking process that edits files, executes the test suite, reads the errors, and tries again.

This is why the categories overlap instead of competing. You can vibe code through an agent by rubber-stamping whatever the loop returns, or practice vibe engineering with that same agent, and the distinction still holds inside a WordPress native AI abilities API where the model calls your registered functions directly.

A WordPress example makes it concrete

Picture exposing a small REST endpoint that returns a customer’s most recent order. Vibe coding means prompting the agent, dropping the output into your plugin, and shipping the moment the response looks correct. Vibe engineering with an agentic tool means the same request, wrapped in the checks a senior developer would never skip:

add_action('rest_api_init', function () {
    register_rest_route('shop/v1', '/last-order/(?P<id>\d+)', [
        'methods'             => 'GET',
        'callback'            => 'shop_get_last_order',
        'permission_callback' => function () {
            return current_user_can('manage_woocommerce');
        },
    ]);
});

An agent can produce that in seconds. What vibe engineering forces is the permission_callback, a unit test for the unauthorized request, and a review of the SQL the callback runs before any of it merges. Drop the capability check and you have shipped broken authorization, which is precisely the exposure created when a store becomes an AI-accessible API and every route is reachable by a model. The speed is real; the accountability is the part you consciously keep or throw away.

Why the label decides what you ship

Choosing a term is really choosing a level of verification, and that has to scale with the stakes. A throwaway script that reshapes a CSV can be pure vibe coding with no consequence worth naming. A checkout flow cannot, and neither can running local LLMs against live customer data. The real trap is carrying the loose posture into high-stakes code without noticing the handoff, because an agentic loop feels productive even during the runs where nothing is being checked. A ten-minute review that catches a missing nonce is cheaper than the weekend of incident response it prevents.

Speed without verification is just technical debt collecting interest at a faster rate.

Reading the room before you prompt

Decide which mode you are actually in before the next prompt leaves your keyboard. If the honest answer is vibe coding, keep it on low-stakes, disposable work where a wrong result costs minutes and nothing else. If the answer is production, treat the agent as a very fast junior whose debugging output still has to be read and whose work still has to be reviewed, and you keep most of the speed while losing most of the cleanup.

Common questions