What is agentic coding?
Engineering culture and software practice
Agentic coding is delegating multi-step software work to an AI agent that plans, edits files, runs commands and tests, and iterates towards a goal while a person supervises rather than authors. It differs from prompting an assistant for a snippet because the agent acts on the system, which is what makes it a governance question. The practice emerged through 2025; as of September 2026 the term competes with agentic engineering and agentic software development, with no single label yet dominant.
What this means
An ordinary AI coding assistant suggests. You ask, it offers a snippet, and you decide whether to use it. An agentic coding tool acts. You give it a goal, and it plans the steps, changes files, runs commands, executes tests, reads the errors and tries again, looping towards the goal with a person watching rather than typing. The human role shifts from author to supervisor.
That shift is the whole point, and the whole risk. Because the agent operates on the actual system, running commands and changing many files, agentic coding is not just a faster way to write code. It is a question of what the agent is allowed to touch, how its work is reviewed, and who is accountable for a change no human typed.
The term is genuinely unsettled. The practice took shape through 2025 as coding tools moved from suggestion to action, and the vocabulary is still competing: agentic coding, agentic engineering and agentic software development are all in use. As of September 2026 none has clearly won, so this article treats them as near-synonyms for the same working practice.
Why it matters
When a tool can act rather than suggest, the economics of software work invert. Generating a large change becomes cheap; reading and understanding one does not. The bottleneck moves from writing to reviewing, and a team that generates faster than it can review is quietly accumulating risk rather than value.
For a smaller organisation without a dedicated platform team, the governance questions arrive all at once. What should an agent be allowed to touch: a test branch, or the production database. What credentials and secrets does it have access to. Where is the audit trail that shows what changed and why. Who is accountable when a change nobody typed causes an incident. These are not exotic questions; they are the ordinary controls of change management, applied to an actor that is neither a person nor a simple script.
The stakes are practical. Done with discipline, agentic coding can take routine, well-bounded work off people's hands. Done without it, it can push large volumes of plausible, unreviewed change into systems that matter, faster than anyone can check. The difference is entirely in the supervision, and that is a leadership responsibility, not a technical detail.
How it works
Where the term came from
Agentic coding does not have a single coiner. It emerged as a practice through 2025 as coding tools gained the ability to plan and act across multiple steps rather than only autocomplete or answer. The vocabulary grew up with the practice and is still contested: as of September 2026, agentic coding competes with agentic engineering and agentic software development, and usage has not settled on one. This article verifies that plurality rather than asserting a winner.
A citable, non-vendor anchor is the Thoughtworks Technology Radar, an analyst publication that has assessed agentic coding practices across its 2025 and 2026 editions. It notes the industry still lacks a shared definition of agent, cautions against measuring productivity by code throughput, and in 2026 framed the core tension as keeping humans in the loop while managing cognitive debt, sandboxing execution and restraining permission-hungry agents. The academic anchor is the benchmark and evaluation literature on autonomous software engineering, such as the SWE-bench family and the Scale AI SWE-Bench Pro paper.
The loop, and where humans sit in it
The working pattern is a loop: a goal is set, the agent plans, it acts by editing files and running commands, it tests, it reads the result, and it revises. Humans sit at chosen points in that loop rather than inside every step. The design decision that matters most is where those human checkpoints go: at the plan, before anything runs; at the diff, before a change is merged; and at deployment, before anything reaches production. Agentic coding done well is mostly the discipline of placing those checkpoints deliberately.
The review problem
The central difficulty is that generating a large change is now cheaper than reading one. This inverts the traditional balance, where writing code was the slow part. The practices teams use to cope are consistent across serious practitioners: keep tasks small and scoped so a change is reviewable; treat tests as the contract the agent must satisfy; restrict the agent's permissions so it can only touch what the task needs; and require human approval at defined points. Thoughtworks describes wiring deterministic quality gates, compilers, linters and test suites, directly into the agent's loop so failures trigger correction before a human ever reviews.
The governance surface
Because the agent acts on the system, agentic coding raises the ordinary controls of change management in a sharper form: change control over what gets merged and when; provenance of code, meaning a record of where a change came from and why; dependency risk, since an agent may pull in libraries; and secrets, since an agent with credentials is a security surface. Standards bodies already frame the answer. The US National Institute of Standards and Technology publishes the Secure Software Development Framework and, in July 2024, a companion profile for generative AI, SP 800-218A, that extends secure-development practices to AI model development. The SLSA framework, maintained under the Open Source Security Foundation, defines provenance controls, cryptographically verifiable records of who built an artefact, from what sources and by what process, that apply directly to code a human did not type.
The honest state of the evidence
Whether agentic coding helps is not settled, and the numbers move. On the benchmark side, the SWE-Bench Pro paper from Scale AI reported the best model resolving 23.3 per cent of long-horizon tasks in its first version in September 2025; a revised version dated 14 November 2025 reported the best model, Claude Sonnet 4.5, at 43.6 per cent, still well short of the seventy-plus per cent those models reach on easier benchmarks. On the productivity side, the METR randomised trial of July 2025 found experienced developers nineteen per cent slower with AI on familiar code; METR has since labelled that figure historical and, in February 2026, reported changing its design after finding a roughly eighteen per cent slowdown for returning developers using late-2025 tools. The picture as of September 2026 is of rapid capability gains on benchmarks alongside genuine uncertainty about real-world benefit.
How experienced teams handle it
They run agents inside sandboxes with restricted permissions, give them small tasks, and use tests as the gate. They keep a human approval step before anything merges or deploys, and they keep an audit trail so a change can be traced to a prompt, a plan and a person. They resist measuring success by how much code the agent produces, because volume is the thing that most easily hides risk.
Examples
A software team of eight lets an agent handle a well-defined chore: updating a library across the codebase and fixing what the change breaks. They scope it tightly, run it in a sandbox, let the test suite act as the contract, and review the final diff before merging. The agent does hours of mechanical work; the humans keep the approval and the accountability.
A retailer's small team is tempted to let an agent implement a new checkout feature end to end. Because customer payments are involved, they place human checkpoints at the plan and the diff, deny the agent access to production secrets, and require the change to pass security review before deployment. The agent accelerates the drafting; it is never allowed to reach the things that matter unsupervised.
A council department with no platform team wants to use an agent to tidy an internal data script. They allow it only on a copy of the data, in an isolated environment, with no ability to touch live records, and they keep a written note of what it changed and why. The low-stakes setting makes agentic coding sensible; the boundaries make it safe.
Common misunderstandings
The first misconception is that agentic coding is just a faster autocomplete. It is not. An assistant suggests and you author; an agent acts on the system, running commands and changing files, which is precisely why it is a governance matter rather than a convenience.
The second is that the agent's autonomy removes the need for review. The opposite is true. Because generating a change is now cheaper than reading one, review becomes the bottleneck and the main safeguard, not an optional extra.
The third draws the line against agentic AI and the AI agent concept, the closest existing ideas. Agentic coding is not a restatement of what an agent is. Unlike those general-capability terms, this is a working practice: how software work is scoped, supervised, reviewed, bounded and accounted for. The general capability is the ingredient; agentic coding is the discipline of using it on real systems.
The fourth is that it is the same as cowboy coding, just automated. It is nearly the reverse when done properly. Cowboy coding is unstructured shipping without controls; disciplined agentic coding adds more controls, not fewer, precisely because the actor is faster and less accountable than a person.
The fifth is that more generated code means more progress. Throughput is a misleading measure here, because volume is exactly what hides unreviewed risk. Serious practitioners explicitly warn against judging agents by how much they produce.
Risks and boundaries
This is a recent and unsettled term, and this article was written in September 2026. The vocabulary is still competing, with agentic coding, agentic engineering and agentic software development all in use and none clearly dominant, so expect the label and the boundaries to keep moving. The evidence is young and contested: benchmark scores such as SWE-Bench Pro change between versions, and the METR productivity finding has already been reclassified by its own authors as historical.
The term is misapplied when it is used as a synonym for any AI coding, or as marketing for autonomy as an end in itself. It does not describe simple assistant prompting, and it is not a claim that agents can safely be left unsupervised. It also does not remove the last-stretch difficulty that experienced engineers still have to finish. The live debate is how much autonomy is prudent and where humans must stay in the loop; the defensible position as of September 2026 is that autonomy should be earned task by task, bounded by permissions, tests and human approval.
What to do next
First, decide what an agent may touch before you let one run. Draw a clear line between low-stakes, sandboxed, throwaway work and anything touching production, money, personal data or secrets. Agents belong on the safe side of that line until they have earned more.
Second, require a human approval point for anything that matters. At minimum, a person should approve the plan for risky work and the final change before it merges or deploys. Do not let volume of generated change substitute for a review anyone actually did.
Third, insist on an audit trail. You should be able to trace any change an agent made back to a goal, a plan and an accountable person. Provenance is not bureaucracy here; it is how you stay able to answer for your own systems.
Fourth, restrict permissions and secrets tightly. An agent with broad access is a security surface. Give it only what the task needs, and keep it out of live credentials by default.
Fifth, measure the right thing. Judge agentic coding by delivered, reviewed, working change and by whether your team still understands the system, not by how much code the agent produced. Throughput is the metric most likely to mislead you.
FAQs
How is agentic coding different from using an AI assistant?
An assistant suggests code that you author and decide to use. An agent acts on the system, planning, editing files, running commands and testing towards a goal, while you supervise. The agent's ability to act is what makes it a governance question.
Who coined the term, and is it settled?
There is no single coiner. The practice emerged through 2025, and as of September 2026 the term competes with agentic engineering and agentic software development, with no label clearly dominant.
What is the biggest practical risk?
The review bottleneck. Generating a large change is now cheaper than reading one, so unreviewed change can pile up faster than anyone can check it, which is where risk hides.
Does agentic coding actually make teams faster?
The evidence is mixed and moving. Benchmarks improved through 2025 and 2026, but a METR trial found experienced developers slower with AI, a figure its authors now call historical. Treat claims of large gains with caution.
What controls should be in place before agents touch real systems?
Restricted permissions, sandboxed execution, small scoped tasks, tests as the contract, human approval before merge or deploy, and an audit trail linking each change to a plan and a person.
Is this just cowboy coding with a robot?
Done properly it is the opposite. It requires more controls, not fewer, because the actor is faster and less accountable than a human. Without those controls it can indeed become reckless.
Can a small firm without a platform team do this safely?
Yes, on the safe side of a clear line: low-stakes work, isolated environments, no live secrets, and a human approving anything that reaches production or sensitive data.