Insights

Agentic Engineering vs Vibe Coding

Same agents, different ownership. One ships whatever the model wrote; the other ships what an engineer checked.

Vibe coding is building software by prompting an AI and accepting whatever it produces without reading the code, a term Andrej Karpathy coined in February 2025. Agentic engineering is the professional counterpart: coding agents write and run most of the code, but an engineer specifies the work, isolates it, verifies it, and reviews every change before it ships. Both can use the same agents, from Claude Code to Codex. The difference is whether anyone owns the result.

Below: where both terms came from, how "agentic coding" fits between them, and a workflow you can start this week.

Agentic engineering vs vibe coding at a glance#

Vibe codingAgentic engineering
OriginAndrej Karpathy, February 2025Popularized by Karpathy in February 2026
Who reads the codeNobody, by designAn engineer, backed by checks they trust
How work is specifiedA running conversationA task with constraints and a definition of done
Where changes landWherever the tool writesAn isolated branch and worktree per task
How it is verifiedIt seems to workTests, a running app, and review before merge
What you end up withA prototype or personal toolCode someone can explain and maintain
Good forWeekend projects, demos, learningSoftware other people depend on
Main riskBugs and bills nobody understandsReview becomes the bottleneck

Where "vibe coding" came from#

On February 2, 2025, Karpathy named a way of coding where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." In his telling, he accepted every change unread, fed error messages straight back to the model, and worked around bugs it couldn't fix. He also scoped it honestly: fine for "throwaway weekend projects."

The name stuck far beyond that scope. Collins made "vibe coding" its Word of the Year for 2025. Along the way the term stretched to cover any code written with AI help, which is the problem the rest of this post is about.

Simon Willison pushed back early. In Not all AI-assisted programming is vibe coding (March 2025) he defined vibe coding as building software with an LLM "without reviewing the code it writes", and gave his own rule for production work: he won't commit code he couldn't explain to someone else. If you reviewed, tested, and understood the code, he argued, it is just software development, whatever wrote the first draft.

What is agentic engineering, and where did the term come from?#

Agentic engineering is software development in which coding agents do most of the implementation under an engineer's direction and review. For most of 2025 that disciplined end of AI-assisted programming had no name that stuck. Then it settled quickly:

  • October 2025. Simon Willison proposed "vibe engineering" for experienced engineers who move faster with agents while staying accountable for what ships. He later added a note that "agentic engineering" was winning.
  • February 4, 2026. In a one-year retrospective, Karpathy said programming through agents was becoming a default workflow for professionals, with more oversight than vibe coding, and named his favorite term: "agentic engineering." Agentic, because you are "orchestrating agents who do and acting as oversight"; engineering, because it is a craft with depth that you can learn and get better at.
  • The same day, Addy Osmani published Agentic Engineering, arguing that "vibe" signals a casualness that does not belong in production work, and describing the practice as plan first, direct and review, test relentlessly, and own the codebase.
  • February 2026 onward, Simon started Agentic Engineering Patterns, where he defines the term as "the practice of developing software with the assistance of coding agents."

Vendors followed. Kiro's homepage now opens with "Move beyond AI coding to agentic engineering." Simon has also been candid that the line is blurring in his own work, which we come back to below.

Agentic coding vs vibe coding vs agentic engineering#

Part of the confusion is that these terms answer different questions.

TermWhat it describesThe question it answers
AI-assisted codingAny use of a model while programmingIs AI involved at all?
Agentic codingAn agent that edits files, runs commands, and iteratesWho executes the work?
Vibe codingAccepting AI output without reading itDoes anyone review it? No.
Agentic engineeringAgentic coding with specs, isolation, verification, and reviewDoes someone own the result? Yes.

Agentic coding is about the mechanics. Anthropic's best-practices page calls Claude Code "an agentic coding environment": it reads files, runs commands, and works through a problem on its own. Simon's guide explains why that matters: "Code execution is the defining capability that makes agentic engineering possible." An agent that can run the tests can keep going until the code actually passes them.

So "agentic coding vs vibe coding" is not really a contest. Let Claude Code run unattended and merge whatever it produced, and you are vibe coding with an agent. Scope the task, isolate it, make the agent prove the change, and review the diff, and the same agent is doing agentic engineering.

What turns agentic coding into engineering#

None of these practices is new. Simon's vibe engineering post makes the point that agents reward exactly the habits senior engineers already have: automated tests, planning, documentation, version control, CI, and code review. What changes is that each habit now does double duty, keeping the agent on track as well as the team.

  • Specify before you prompt. State the outcome, the constraints, and the command that proves it works. A vague prompt gets a confident, plausible, wrong answer.
  • One task, one isolated checkout. Each task runs in its own Git worktree, or in a container when it touches services or system packages, so parallel agents cannot corrupt each other's files.
  • Reproducible environments. A setup script takes a fresh checkout to a working state, so the agent spends tokens on the task, not on guessing the build.
  • Tests as the feedback loop. Agents iterate against tests. Simon's red/green TDD chapter, which writes a failing test first, is the strongest version of this.
  • Evidence, not claims. "Done" from an agent is a claim. Test output, a running app, and a browser check are evidence.
  • Independent review. A different model reviews the diff before you do, and you read what is left.
  • Teach the repository. When an agent repeats a mistake, put the fix in the repo's agent instructions and review prompt. As Simon's guide observes, the model won't remember the lesson, but your agent setup will if you write it down.

An agentic coding workflow you can start this week#

Here is the loop as Agentastic supports it, though every step also works with plain Git and a terminal.

  1. Write the task as a short spec.

    text
    Fix the rounding error in EUR checkout totals. Constraints: don't change the public Money API; keep USD behavior identical. Done when: `npm test -- checkout` passes and you explain the root cause.
  2. Start it in its own worktree. Launch from Agent Home, or with dev agent create, in a fresh Git worktree. For risky changes, start in plan mode and approve the plan before any edits.

  3. Let the setup script prepare it. .agentastic/setup.sh installs dependencies and copies local config whenever a worktree or container is created. See setup and teardown scripts.

  4. Parallelize only independent work. Run a second agent on an unrelated task. When you are unsure of the approach, send the same task to two agents and keep the better diff.

  5. Watch attention, not terminals. Notifications mark agents that are finished, blocked, or failed, and Shift-Command-U jumps to the next one that needs you.

  6. Check the evidence. Read the test output, then open the app in the built-in browser, which the agent can also drive with dev browser to verify its own UI change.

  7. Get an independent review. From code review, have Codex review a Claude Code diff or the reverse, or run CodeRabbit or Greptile. For a large diff, guided review splits it into chapters, and a line comment can go straight back to the agent.

  8. Merge one result at a time. Open the pull request, let CI run, merge, and rebase the remaining worktrees. Then write down anything the agent got wrong twice.

Once this loop is boring, automate the edges: scheduled agents for recurring chores, and Manager Agents that start and follow up on workers. Our guide to agent orchestration covers those patterns.

Agentic engineering patterns worth borrowing#

A few patterns hold up across agents and tools:

  • Run the tests before anything else. Simon's first run the tests chapter argues that tests stop being optional once agents write the code, and that opening a session by running the suite nudges the agent to keep testing its changes.
  • Plan, then execute. Have the agent propose a plan, correct it, then let it edit. Kiro makes this its centerpiece, turning prompts into specs before any code.
  • Fan out on uncertain work. Two or three attempts in separate worktrees cost less than one long wrong turn.
  • Review across providers. A second model catches different mistakes than the one that wrote the code.
  • Give recurring work a memory. A nightly maintenance agent should know what yesterday's run already handled.

When vibe coding is the right call#

Vibe coding is not a dirty word. Karpathy scoped it to throwaway projects, and Simon has long argued that it lowers the barrier for newcomers building their own tools, and helps experienced developers learn what models can and cannot do. A personal script, a prototype for a meeting, or a one-off data cleanup: go ahead.

The line is software other people depend on. Simon's May 2026 post puts it bluntly: when other people's data is involved, they are the ones hurt by your bugs. His 2025 post adds a money warning: be careful vibe coding against anything billed by usage.

The May post also admits something useful. As agents got more reliable, Simon stopped reading every line of some production code, treating the agent the way he would treat a service another trusted team built, and he worries about the "normalization of deviance" that comes with it. We think that is the honest frontier. The test is not whether you read every line. It is whether someone is accountable and holds evidence: tests, review proportional to risk, and real use.

Where Agentastic fits#

Agentastic is a native macOS workspace built for the engineering side of this split. Every task gets its own worktree by default, or a container when it needs one, setup scripts make each one reproducible, attention routing tells you which agent needs you, and a built-in browser, cross-provider AI review, and pull-request merge sit next to the diff. It runs the agents you already use, including Claude Code, Codex, and Gemini, and is free. It is also macOS only and closed source.

If you are choosing tools, start with what an agentic IDE is and the best agentic IDEs in 2026. For running several agents at once, see the multi-agent IDE. For the whole line from issue to merged pull request, see the AI software factory.

Sources#

Frequently asked questions#

What is agentic engineering?#

Agentic engineering is building software with coding agents that write and run most of the code, while an engineer specifies the work, isolates it, verifies it, and reviews every change before it ships. Andrej Karpathy popularized the term in February 2026 as the professional counterpart to vibe coding.

What is the difference between agentic engineering and vibe coding?#

Vibe coding means accepting AI-generated code without reading it, which is fine for throwaway projects. Agentic engineering uses the same agents but keeps engineering discipline: a clear spec, an isolated workspace per task, tests, and review before merge. The difference is whether someone owns the result.

Is agentic coding the same as vibe coding?#

No. Agentic coding describes what the tool does: an agent edits files, runs commands, and iterates. Vibe coding describes what you do with the output: accept it unread. You can vibe code with an agent, or practice agentic engineering with one.

Who coined the term vibe coding?#

Andrej Karpathy coined vibe coding in a post on February 2, 2025, describing a style where you stop looking at the code and accept changes without reading the diffs. Collins named it its Word of the Year for 2025.

What does an agentic coding workflow look like?#

Write the task as a short spec with a command that proves it works, start it in its own Git worktree, let a setup script prepare the environment, and let the agent iterate against tests. Then check the evidence, get an independent review, and merge through a pull request.

What are agentic engineering patterns?#

They are repeatable practices for getting reliable work out of coding agents, such as test-first development, running the existing tests before any change, planning before editing, one isolated worktree per task, and review by a different model. Simon Willison collects many of them in his Agentic Engineering Patterns guide.

About the Author

Adel Ahmadyan

Builds Agentastic.dev, the native macOS multi-agent IDE.