What Is Agentic Coding? From Vibe Coding to Agentic Engineering (2026)

Agentic coding means handing an AI agent a whole task instead of prompting it line by line. The agent plans the change, edits the files, runs the tests, fixes what broke, and hands you back a result to review. This is now how most software gets written: in JetBrains' August 2026 survey of 15,000+ professional developers, 90% use a coding agent at least weekly and 68% use one daily.

The vocabulary has been scrambling to keep up with that shift. "Vibe coding" captured the 2025 moment when you could describe software and accept whatever came back. "Agentic coding" describes what the tools can actually do now, and "agentic engineering" is Andrej Karpathy's 2026 name for the discipline of using them well. In this guide we'll walk through what each term means, how the agent loop actually works, what the adoption data says (along with the counter-evidence), and a six-step workflow that holds up in production.

What Is Agentic Coding?

Agentic Coding Definition

Agentic coding is building software by giving an AI coding agent a goal, then letting it read the codebase, plan the change, edit files, run commands and tests, and iterate until the goal is met or it needs a decision from you. Your job is to review at the boundaries rather than type every line.

Those four verbs (plan, execute, test, iterate) are the whole test: a tool that only does the second one is an assistant, not an agent. The term itself has been around since Anthropic launched Claude Code in February 2025 and called it "our first agentic coding tool." What changed since then is that the tools grew into the name, and running with minimal human intervention went from research goal to default setting.

Coding Agents vs Coding Assistants

The easiest way to tell an agent from an assistant is the unit of work. An assistant completes the line you're typing, or answers a question you paste into a chat, and then you take that snippet and run it yourself. An agent works at the level of a task ("make the invite flow email new members, and cover it with tests") and runs the code itself.

Three ingredients make that possible. The agent has tools, so it can read and write files, run shell commands, execute the test suite, and sometimes drive a browser. It has a loop, so it can act, look at what happened, and decide the next step without waiting for another prompt. And it has a stopping condition: the tests pass, the task gets blocked, or a budget runs out. Remove any one of the three and you're back to an assistant. If you want to see how that loop gets built and bounded, our harness engineering guide covers it in depth; the short version is Agent = Model + Harness.

Agentic Coding vs Vibe Coding: The Real Difference

The two terms get used interchangeably, and mixing them up hides the most important decision you make when building with AI. Vibe coding, as Karpathy originally described it in February 2025, means accepting every suggestion and never reading the diffs. That's not a category of tool; it's a decision not to review.

Agentic coding, on the other hand, is a category of tool: a system that can plan, execute, and verify on its own. You can vibe code with an agent by letting it run and accepting whatever comes back, and you can use the same agent carefully, reading every plan and every diff before anything lands. The autonomy lives in the tool, but the scrutiny lives in you. Here's how the three terms compare on the axes where they genuinely differ:

Notice where most people actually sit: the middle column. They run an agent, skim what it produced, and merge. The adoption numbers later in this guide show how normal that has become, and the counter-evidence section shows why it deserves more suspicion than it gets. For the longer story of what accept-all does to a codebase, see when vibe coding breaks down.

Agentic Engineering: Karpathy's Name for Doing It Professionally

The vibe coding term got its official correction a year later, from the person who coined it. On February 4, 2026, Karpathy quoted his own original post:

Today (1 year later), programming via LLM agents is increasingly becoming a default workflow for professionals, except with more oversight and scrutiny. The goal is to claim the leverage from the use of agents but without any compromise on the quality of the software. Many people have tried to come up with a better name for this to differentiate it from vibe coding, personally my current favorite "agentic engineering".

His two reasons for picking the name double as a definition. It's "agentic" because "you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight." And it's "engineering" because "there is an art & science and expertise to it. It's something you can learn and become better at."

Floor and Ceiling

He expanded on the idea at Sequoia's AI Ascent that April and later wrote it up himself. In his framing, vibe coding raises the floor, because almost anyone can now describe software into existence. Agentic engineering raises the ceiling: it's "the professional discipline of coordinating fallible agents while preserving correctness, security, taste, and maintainability." He also spelled out what that discipline looks like day to day: designing specs, supervising plans, inspecting diffs, writing tests, creating evaluation loops, managing permissions, isolating worktrees. Hold onto that list, because it becomes the workflow at the end of this guide.

Simon Willison, who had been calling roughly the same idea "vibe engineering" since late 2025, switched to Karpathy's term and added the most honest observation anyone has made about it. The line between the two modes used to be obvious, he wrote in May 2026: "vibe coding is the thing where you're not looking at the code at all." It isn't obvious anymore, because "as the coding agents get more reliable, I'm not reviewing every line of code that they write anymore." Engineers have a name for that pattern: normalization of deviance. Every time the agent gets it right without supervision, you trust it a little more, and eventually you trust it at exactly the wrong moment.

Where "Agentic Development" Fits

You'll also run into agentic development and agentic software development, which are the platform-vendor and analyst versions of the same shift. Google launched Antigravity in November 2025 as an "agentic development platform" whose agents "autonomously plan, execute, and verify complex tasks across your editor, terminal, and browser," and analysts now describe agents collaborating across the whole development lifecycle with people remaining accountable for the outcome. Underneath the branding, every version of the phrase describes the same arrangement: agents do the executing, and humans own what ships.

How Agentic Coding Works: The Agent Loop

Whether it lives in your terminal, your IDE, or a cloud sandbox, every agentic coding tool runs some version of the same seven-step loop, and knowing the steps tells you exactly where to step in.

1. Goal. You hand over a task: "Add rate limiting to the public API, 100 requests a minute per key, with tests."
2. Context. The agent reads the repo: relevant files, the AGENTS.md and rules files, recent commits, existing tests. This step decides whether it follows your conventions or invents new ones.
3. Plan. It works out which files change, in what order, and what the tests will assert. Most tools show you the plan if you ask; the good ones show it by default.
4. Act. It edits files and runs commands: install a dependency, write the middleware, add the test.
5. Observe. It runs the tests, the type checker, the linter, maybe a browser, and reads the output. This is the step that separates an agent from a text generator.
6. Iterate. Red tests send it back to step 4, green tests move it forward, and a blocked step (missing credential, ambiguous requirement) comes back to you.
7. Hand back. You get a diff or a pull request with a summary of what changed and why, and the agent stops.

So where do humans still fit? Mostly at the top of the loop. When Anthropic analyzed about 400,000 Claude Code sessions in June 2026, it found people made roughly 70% of the planning decisions but only 20% of the execution decisions. The same study measured verified success at 15% for novices against 28% to 33% for experienced users, which is worth sitting with for a second: the agent does the typing, but the outcome still depends heavily on who's directing it.

Two variations are worth knowing. Background agents (Codex cloud, Copilot coding agent, Cursor's background agents, Jules) run steps 2 through 7 in a sandbox and hand you back a finished pull request. Loop engineering goes further still, adding an outer loop that finds the next piece of work on its own, so the agent works through a backlog rather than a single task. Both count as agentic coding; they just differ in how far you are from the chair.

The Agentic Coding Tools of 2026 (and How Fast They Moved)

The tooling went from one research preview to a crowded market in about fifteen months. Claude Code shipped in February 2025, and by that summer OpenAI's Codex, GitHub's Copilot coding agent, Google's Jules and Gemini CLI, and Cursor's background agents were all live alongside it. AWS Kiro and Google Antigravity landed late in the year, and by May 2026 Claude Code's dynamic workflows were fanning single tasks out across whole fleets of parallel subagents. The tools have consistently moved faster than the words we use for them.

Market share has been just as volatile. Here's JetBrains' survey data, January against mid-2026:

Ranking these tools is a different article (our tools comparison stays current for exactly that), but one trend matters here: by mid-2026 every major vendor ships an agent, and the agent, not the autocomplete, is now the product.

What the Data Says: Adoption Is Real, Delegation Is Not

The adoption story looks settled. The delegation story doesn't. Even at Anthropic, the company building the most-used agent, more than half of surveyed engineers say they can fully hand off only a fifth of their work or less. We think of this as the delegation gap, and it explains more about agentic coding in 2026 than any other number.

Put those numbers together and the picture is remarkably consistent. Nearly everyone runs an agent every week, yet barely a fifth of pull requests ship without a human touching them, and the people closest to the best tools still keep their hands on almost everything. The industry, in other words, is living in the middle column of the comparison table: agents everywhere, verification uneven.

The Counter-Evidence Worth Taking Seriously

If we only quoted adoption surveys, this would be marketing, so here is the strongest evidence on the other side. METR runs the cleanest experiment in the field: randomized trials where experienced open-source developers work on real issues with and without AI. In the February 2026 update, developers using the tools were still measurably slower (about 18%, with wide error bars) while insisting they were faster. That gap between how fast AI feels and how fast it measures is the entire case for verification.

The security numbers point the same way. Veracode's Spring 2026 report tested more than 150 models and found only about 55% of generation tasks produced secure code, a pass rate that moved, in their words, "from approximately 55% to approximately 55%" year over year while syntax correctness climbed past 95%. Newer models have gotten much better at writing code that runs, and no better at writing code that's safe.

None of this means agentic coding doesn't work. It means output has been growing faster than the checks on it, which is exactly what you'd expect when the cheap half of the loop (acting) gets automated before the expensive half (verifying). We went deep on that shift in the 2026 code-quality data; the short version is that a better model raises what an agent can do, while the harness around it decides what actually ships.

An Agentic Coding Workflow That Holds Up

Take Karpathy's list of what agentic engineers do and put it in order, and you get a six-step workflow where each step closes one of the failure modes above. The commands differ from tool to tool; the shape doesn't.

1. Write the spec first. A task with acceptance criteria gives the agent a definition of done and gives you something to check the result against. Vague goals produce confident wrong answers. This is spec-driven development, and it's the step most people skip.
2. Give the agent context it can't guess. Your conventions, your architecture, the patterns to copy, the files it must not touch. An AGENTS.md and scoped rules do this once instead of once per prompt.
3. Review the plan before the diff. Planning is where humans still make most of the decisions, and redirecting an agent at step 3 of its loop is far cheaper than at step 7. Every major tool has a plan or read-only mode; use it on anything bigger than a one-file change.
4. Constrain what it can do. Permission prompts for destructive commands, a separate worktree or branch, a token or time budget, and no production credentials in the sandbox. Autonomy without boundaries is how an agent deletes a database.
5. Verify with machines first. Tests, types, lint, and a security review on every change in CI, plus evals for any AI feature the agent touched. The agent's own green run is evidence, not proof, so the gate has to live outside the agent.
6. Review the diff at the boundary. Not every line in real time, which Willison admits nobody does anymore, but every diff before merge, with the spec open next to it. This is the step that keeps agentic coding from sliding back into vibe coding.

If you're wondering which of these you actually have in place, the AI coding maturity model is a five-minute self-assessment. Most teams discover they're strong on steps 2 and 5 and missing 1, 3, and 6.

Common Agentic Coding Mistakes (and the Fixes)

We see the same five mistakes in nearly every agentic-coding post-mortem, our own included, and each one traces back to a skipped step.

• Accept-all at scale. Vibe coding with an agent that can touch forty files. The fix is step 6: a diff review before every merge, with the spec beside it.
• Trusting the agent's own tests. An agent that writes both the test and the code can get both wrong in the same direction. The fix is step 5: gates in CI that the agent doesn't control.
• Context-free agents. With no AGENTS.md and no rules, every task reinvents your conventions, and you end up with the duplication GitClear measured. The fix is step 2.
• Delegating the planning. Humans still make most of the planning decisions, and success tracks expertise, so handing over a one-line goal and walking away inverts the part of the loop you're best at. The fix is steps 1 and 3.
• Unbounded autonomy. Production credentials in the sandbox, no budget, no worktree isolation. The fix is step 4, set up before the first task rather than after the first incident.

The thread running through all five: agentic coding isn't a model you buy, it's a loop you run, and the loop is only as good as the gates you put in it. Closing that gap is what agentic engineering means in practice, and it's a skill you can learn.

Frequently Asked Questions

Have more questions? See our full FAQ →