One 2025 review, Vibe Coding vs. Agentic Coding: Fundamentals and Practical Implications of Agentic AI by Sapkota, Roumeliotis and Karkee, defines agentic coding as a mode of AI-assisted software development in which autonomous or semi-autonomous software agents are delegated substantial cognitive and operational responsibility: interpreting a high-level goal, planning and decomposing it into sub-tasks, using tools and resources (compilers, test runners, version control, APIs) to execute them, and iterating based on feedback, with minimal continuous human intervention. On that review’s account, the developer’s role shifts from low-level implementer to system-level supervisor and goal-setter: specifying objectives and constraints, monitoring execution traces and outputs, and validating results before integration.
Usage
In the same review’s taxonomy, which contrasts it with vibe coding, agentic coding is characterized by moderate-to-high AI autonomy, hierarchical planner–executor architectures (often with specialized sub-agents such as a coder, tester, reviewer, and fixer coordinated by a planner), sandboxed or containerized execution environments, persistent memory across multi-step tasks, and an integrated validation pipeline that automatically synthesizes and runs tests rather than relying on a human to invoke them. The review’s named examples of agentic coding platforms include Codex, which can run git diff, apply patches, and generate pull requests automatically; Google’s Jules, which clones and analyzes a repository, modifies code, and commits changes to a new branch for review; and Claude Code, built with explainability and oversight features that let a developer audit changes, trace reasoning, and roll back unsafe actions.
What It Looks Like in Practice
The account above is taxonomic — it describes what agentic coding is designed to be. A large-scale observational study, Agentic coding and persistent returns to expertise, reports what roughly 400,000 Claude Code sessions between October 2025 and April 2026 actually consisted of, and several of its findings qualify the picture.
The supervisor role is real but narrower than “monitoring execution”. Measuring who makes which decisions, that study finds people making about 70% of planning decisions — what to do, which approach, what counts as done — and the agent about 80% of execution decisions: which files to change, what code to write, which commands to run. The split is between what and how, not between doing and watching.
The work is also less exclusively code than the definition suggests. Sessions divide across nine work modes, of which roughly 56% write, fix, test or orchestrate code; 17% operate software (deploying, configuring, running pipelines, monitoring); 14% plan or work out how an existing system behaves; and 13% produce data analysis or prose documents. Over the seven months observed, the share of sessions spent debugging fell by nearly half while usage shifted toward more end-to-end agentic work.
The scale of delegation per instruction is measurable: a typical session runs about four turns, and each user prompt sets off around 10 agent actions on average, occasionally over 100, with about 2,400 words of agent output per turn.
What that study adds to the risk picture is a finding about who benefits. Session success rises with the user’s task-specific expertise — verified success 15% for novice-rated sessions against 28–33% for intermediate and above, as adjusted rates comparing sessions matched on work mode, task-value band, month, subject and occupation group, and excluding sessions judged to have no clear goal — while occupation separates outcomes much less, with every one of the ten largest occupations landing within seven points of software engineers on code-producing sessions. The authors’ reading is that a coding background is becoming less relevant to successful programming while command of a domain is not. Note that these are transcript-based measures from one vendor’s own product, and that the study observes no real-world outcomes.
What the Practice Demands
A practitioner account, Effizientes Agentic Coding, approaches the term from the working conditions rather than the taxonomy, and draws the boundary more sharply than the definition above: on its reading AI-assisted software development is not agentic coding, and a coding agent treated as a chatbot inside the IDE yields no large efficiency gain, because the constant exchange keeps the developer’s attention on the conversation. The gain it identifies comes from the agent working unattended until a required end state is reached, which leaves the developer free to do something else — summarized there as not babysitting the AI.
The condition that makes this possible is a description precise enough that the developer need not
be present, and that post’s central claim is about what such a description contains. Implementing
by hand involves a continuous stream of decisions made implicitly and often unreflectively — where
a class goes, what a method is named, how tests for this code are structured — because that is how
it has always been done or because it seems obvious; none of that is available to a model unless it
is said. The work of development is recast accordingly as making those decisions in advance and in
the open, at several levels of abstraction: the system and the context the feature sits in, user
personas, the feature definition from the user story, acceptance criteria, technical constraints,
and where it matters the required class and method names. Prompts of several dozen lines are
described there as unremarkable. That post also attributes dissatisfaction with agent output to
missing context rather than to model capability, which it holds is adequate for most coding tasks,
and sorts context by scope: what can be derived from the existing codebase by pointing at a
particular class, what holds project-wide and belongs in an AGENTS.md file, and what is specific
to the task and belongs in the prompt.
Its second condition is a feedback signal the agent can act on without a human: static analysis, linters, and above all test coverage, so that the result is semantically and not merely syntactically correct. That post holds end-to-end tests the most valuable kind and argues an agent can produce good ones alongside the implementation where writing them by hand would have been too laborious, and that a test-first workflow transfers directly — asking for a failing test before the fix or feature, which then goes green.
On review it reframes the question from whether a human reviews to when: skipping code review does not remove the review, it moves it onto staging or production and onto a product owner, and a defect found there costs a full pipeline run to correct. The difficulty of reviewing AI-generated code is attributed there not to AI but to how reviews were already handled, with AI only amplifying it — large pull requests touching dozens of files along no clear line are not sensibly reviewable regardless of who wrote them. The practices it recommends are continuous with pre-AI advice: slice stories small, break them into implementable tasks, change one thing per pull request, review synchronously with colleagues, and review promptly and in batches.
Finally it treats non-determinism as something to use rather than tolerate. Repeated prompts give varying results, which that post attributes to temperature and calls a feature of language models; its argument is that the development process was never deterministic either, since different people and the same person at different times arrive at different solutions, and that the variation occasionally produces an approach the developer would not have reached — while code once generated is deterministic like any other.
In the Agentic AI Guide
The chapter on agentic coding in the Chinese-language Agentic AI Guide (智能体AI 权威指南) frames the term as going beyond code generation: the AI takes part as an autonomous agent across the whole lifecycle of requirements understanding, architecture planning, code writing, and debugging and fixing. It organizes the subject as a progression — first the paradigm shift from vibe coding to agentic coding, then how the agent loop works (single-step iteration, concurrent scheduling, stop sequences and the context window), then a comparison of common coding-agent tools by their operating surface, permission model and instruction files, then a development methodology it calls the P-D-E-R loop combined with spec-driven and test-driven development, and finally engineering practice: human oversight models, checkpoint mechanisms and compound engineering.
In an AI Agent Architecture Book
A chapter on agentic coding in the Chinese-language online book AI Agent 架构：从单体到企业级多智能体 (AI agent architecture, from monolith to enterprise multi-agent systems) draws the line against code completion rather than vibe coding. Completion, on its account, works at the cursor within the current file, leaves the human to decide what gets written, and can neither run code nor iterate on feedback; agentic coding spans the whole codebase and its cross-file dependencies, lets the agent decide what to write, runs code and tests, and revises from the results. Its summary is that completion types out what you have in mind, while agentic coding implements what you ask for. The flow it describes runs from understanding the requirement through analysing the codebase, planning, writing code, running tests in a sandbox and fixing iteratively, to submitting a commit or pull request.
The chapter treats understanding the codebase as one of the hardest parts: a codebase cannot be put into a context window whole, so the relevant code has to be selected, which it proposes doing by combining keyword and semantic search and by building dependency graphs. It holds that code an agent generates must run in an isolated environment — not as an option but as a requirement — recommends editing by unique text anchors rather than line numbers, and adds a guard against fix loops in which repairing one failure breaks another. Among the pitfalls it lists are overflowing the context window, an agent changing tests or test data so that tests pass while the code is wrong, adding dependencies freely, and operating on a dirty Git state. Most of its code is labelled as conceptual illustration; the excerpts it quotes from a real codebase come from the Shannon agent system.
In a Practitioner Talk
A Japanese-language conference talk, AIエージェントのキホンから学ぶ「エージェンティックコーディング」実践入門, defines agentic coding (エージェンティックコーディング, which it also glosses as AI coding) as a way of developing software that makes use of coding agents, with an LLM as the reasoning engine. Like the architecture book above, it draws the line against code completion: with completion the human drives and the AI navigates, with a coding agent the AI drives and the human navigates. It explains a coding agent as an AI agent whose environment is the codebase and which keeps choosing among its tools on the basis of what it has perceived. The talk traces three common failures — the agent building something other than what was asked, code it reports as “done” that does not run, and ignored rules or scattered duplicate code — to the agent not having been given enough information to plan, a means to check its own work, or a mechanism that controls its actions. It answers them with three principles of its own: define what to build, make self-verification systematic, and grow the rules that must be kept, putting whatever must always be obeyed into a rule-based mechanism such as hooks rather than leaving it to prompts.
When It Applies
The Sapkota, Roumeliotis and Karkee review holds that it suits feature-level or even simple application-level tasks where correctness, traceability, and automation matter more than exploratory speed: end-to-end feature implementation, complex multi-file refactoring, system migrations, and CI/CD pipeline automation. On that review’s account it assumes an execution environment that can safely grant an agent write access and tool use (a sandbox or container with resource and namespace isolation), and the review identifies risks distinct from vibe coding: reduced human oversight can lead to skill atrophy in developers who stop engaging with implementation details, and autonomous changes across multiple modules can propagate errors silently if the agent lacks rollback mechanisms or observability hooks. The review presents it as complementary to, rather than a replacement for, vibe coding — suited to the implementation and operational phases of a project that vibe coding’s exploratory prototyping feeds into.
Related Terms
Vibe Coding, AI Coding Agent, Harness Engineering, Agent Harness, AGENTS.md