What is agentic coding?

When Stack Overflow surveyed developers in mid-2025, 84% were using or planning to use AI tools, but only 31% were using AI agents (Developer Survey 2025). Andrej Karpathy, who named "vibe coding" in February 2025, put the change bluntly a year later: coding agents "basically didn't work before December and basically work since" (quoted by Simon Willison, February 2026).

Use has moved faster than delegation. When Anthropic surveyed 132 of its own engineers and researchers, they reported using Claude in 59% of their work, yet more than half said they could "fully delegate" only between 0 and 20% of it (Anthropic, December 2025). That gap is what this guide is about. What decides whether agentic coding pays off is how much an agent is trusted to do unwatched, and what evidence proves it did the job. Tools, models and prompts matter only where they move those two numbers.

The vocabulary has not kept up either. Agentic coding, agentic engineering, agentic software engineering and vibe coding are used interchangeably in some places and as opposites in others. This guide separates them, explains how coding agents work and where they fail, summarises what the independent evidence says, and covers what changes when a whole organisation adopts the practice, drawing on re:cinq's work with around a hundred developers at Odevo.

What is agentic coding?#

Agentic coding means handing a coding task to an AI agent that can take actions in a development environment, then supervising the result. The definitions in use agree on the essentials:

Sources accessed 11 September 2026.

There is a goal stated at a higher level than a single edit. The agent has tools: it can read and write files, search the codebase and run commands. It works in a loop, choosing its next step from what the last one returned. And it gets feedback from the environment: compiler errors, test results, linter output or a screenshot. Anthropic's engineers made the same point in their 2024 guide to building effective agents: an agent needs "'ground truth' from the environment at each step (such as tool call results or code execution)."

What the definitions leave out

Several popular definitions describe agentic coding as agents working "with minimal human intervention". That describes what the tool can do on its own, and says nothing about how carefully a person checks the output, which is the part that decides whether the code is fit to ship. The terminology section below returns to this distinction.

How does a coding agent work?#

A coding agent has two parts: a large language model, and the harness around it that lets the model act. Harness is the settled term for the second part — Claude Code, Codex and OpenCode are all harnesses, and the model inside is swappable. Willison's definition: "a piece of software that acts as a harness for an LLM, extending that LLM with additional capabilities" (How coding agents work, March 2026).

The loop and its tools

The harness offers the model a set of tools: file operations, search, shell commands and web access. The model picks one, the harness runs it and returns the result, and the model decides what to do next. The loop ends when the model judges the task done, which is a weak point. Anthropic's best-practice guide warns that "Claude stops when the work looks done," and recommends giving the agent "a check it can run: tests, a build, a screenshot to compare" (Claude Code best practices).

Context: the scarce resource

Language models are stateless, so everything the agent knows about your project has to be in its context window, and quality drops as that window fills. Anthropic's engineering team calls this context rot: "As the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases." The advertised size overstates what is usable, because the system prompt, the tool definitions and every tool result are charged to the same budget: Anthropic's documentation is explicit that "everything in the request counts toward the context window", tool definitions included. Every MCP server a team connects adds its definitions to every context from then on. Michael Czechowski measured the effect in a Claude Code session in early 2026: system prompt, tool definitions, memory files and the compaction buffer left "approximately 55k tokens — not the theoretical 200k" for work (The Autocompact Cliff). Frontier windows have since grown to a million tokens, and Anthropic does not publish Claude Code's system prompt, so plan around the proportion rather than the number. Deciding what the agent sees, and when, is called context engineering.

Instruction files and MCP

Two mechanisms shape what the agent knows before it starts:

• Instruction files. A file the agent reads at the start of every session, holding build commands, conventions and warnings: CLAUDE.md for Claude Code, or the open AGENTS.md that OpenAI released in August 2025. They work best short, and Anthropic's guide suggests asking of each line: "Would removing this cause Claude to make mistakes?"
• The Model Context Protocol (MCP). An open standard, released by Anthropic in November 2024 and donated to the Linux Foundation a year later, for connecting agents to external systems such as issue trackers and browsers. Every connected tool adds definitions to the context, so more tools are not better.

Permissions and sandboxes

An agent that can run shell commands can also delete files or leak secrets, so every harness has a permission model. The default is to ask before risky actions, and in practice people stop reading the prompts: Anthropic reports that "Claude Code users approve 93% of permission prompts" (March 2026), a pattern its engineers call approval fatigue. The controls have moved well past ask-or-allow. Claude Code takes allow, ask and deny rules written per tool, per command pattern, per file glob and per domain, so a team can remove a tool from the agent's context entirely, block reads of .env files, or limit web fetches to named domains. Anthropic is candid that these are text matching rather than a security boundary — a deny rule on rm will not stop a script that deletes the same file — and points instead at its OS-level sandbox, which enforces filesystem and network limits for every command and its child processes. Cloud agents such as GitHub's coding agent and OpenAI's Codex sit at the far end of the same spectrum: each task runs in an isolated environment and arrives as a pull request.

From autocomplete to agents: a short history#

Agentic coding grew out of four years of fast change in what AI coding tools could do, and in the benchmarks used to measure them.

GitHub Copilot's technical preview in June 2021 brought model-written suggestions into the editor, and ChatGPT made conversational coding help mainstream in November 2022. The step towards agents came with benchmarks that asked models to fix real issues in real repositories: when SWE-bench appeared in October 2023, the best model, Claude 2, resolved "a mere 1.96% of the issues."

Cursor shipped an early agent in November 2024, the same month Anthropic open-sourced MCP. Anthropic released Claude Code on 24 February 2025, calling it "our first agentic coding tool", and OpenAI's Codex and GitHub's Copilot coding agent arrived in May 2025.

The length of task an agent can finish, its performance on what the field calls long-horizon work, has grown steadily too. METR measures a model's time horizon, the length of task in human expert time that it completes with 50% reliability, and reported in March 2025 that this had been "doubling approximately every 7 months for the last 6 years", while cautioning that a horizon of a given length does not mean tasks of that length can be delegated. Benchmarks have their own limits: in February 2026 OpenAI stopped reporting SWE-bench Verified after an audit found "at least 59.4% of the audited problems have flawed test cases that reject functionally correct submissions."

Agentic software development: what the work looks like#

Brittany Ellich, an engineer at GitHub, defines agentic software development as "the practice of systematically delegating well-scoped, clearly-defined tasks to AI coding agents while you focus on development work that requires more human judgment" (November 2025). Practitioners' workflows differ in tooling and converge on a few habits.

The habits experienced practitioners share

• Plan before code. Anthropic's guide advises separating "research and planning from implementation to avoid solving the wrong problem," with a sensible exception: "If you could describe the diff in one sentence, skip the plan."
• Give the agent a check it can run. Tests are the agent's main source of truth about whether it has succeeded, which is why test-driven development has come back into fashion.
• Keep each session small. Mitchell Hashimoto, co-founder of HashiCorp and more recently author of the Ghostty terminal, advises developers to "break down sessions into separate clear, actionable tasks. Don't try to 'draw the owl' in one mega session" (February 2026).
• Fix the harness when the agent fails. Hashimoto calls this "harness engineering": "anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again." The fix might be a line in the instruction file, a linter rule or a test.

Codebases that agents can work in

The environment matters as much as the prompt. Ivan Velichko, who generated tens of thousands of lines of production code with agents in a month, puts a number on it: "Running agents against a 'bare' codebase (without a dev environment) removes about 90% of their usefulness" (January 2026). An agent that cannot build, run and test the software is guessing. Work that is well specified and easy to verify suits delegation; work that depends on unwritten knowledge about the system suits it least, which is one reason gains are smaller in large, old codebases (see the evidence section below).

When the team changes its process

Individual habits only go so far if the team's process was designed for hand-written code. Dominic Warchalowski, a lead engineer at Odevo and by his own account one of the company's most sceptical engineers about AI, told our podcast that his team first tried agents inside their existing Kanban flow and found that a pull request for every small ticket "is not going to work." His conclusion: "you have to design it around the agentic way of working instead of the other way around" (A former AI sceptic on agentic delivery). His team now keeps a hub repository holding the epics, stories, rules and skills that every service repository uses, with the database schema as the reference so agents do not "eat up a ton of context" looking through the code for the truth.

Where coding agents fail#

Agents fail in recognisable ways, and the same patterns turn up everywhere from vendor documentation to our own training. Knowing them in advance is most of the difference between a developer who trusts an agent appropriately and one who is burned once and never tries again.

Sources as linked: Böckeler on pushing AI autonomy and re:cinq on validation and accountability. The Warchalowski quotes are from the Waves of Innovation podcast; transcripts are machine-generated and lightly cleaned.

These are failures of a capable system. As Amy Heineike of Tessl put it on our podcast, when a model lacks the right information "they kind of tell you what they wish the right answer would be" (Evals, reducing hallucinations and AI-native development). The output is fluent whether or not it is right, and more instructions do not reliably fix that: Heineike has seen that "if you give it a really detailed discussion of the task that you want to do, it will tend to ignore most of the instructions," and that rule files accumulate rules that "become contradictory to each other."

This is why re:cinq teaches failure modes at the start of its training, before the more impressive capabilities: developers who have seen an agent go wrong in a safe setting recognise it when it happens on real work.

Vibe coding, agentic engineering and agentic software engineering#

Several terms are used for overlapping things and are not synonyms. Agentic coding names the tool; vibe coding names a way of working with it, defined by how little the person checks. Agentic engineering names the professional discipline built around the agent, and agentic software engineering is mostly a research field. All of them were coined within about eighteen months of each other:

Quotations and dates as linked. Agent-oriented software engineering, a field from the 1990s about building multi-agent systems, is separate and older.

The distinction that matters in practice is verification. You can vibe code with an agent, and you can use the same agent with full engineering discipline; what separates the two is whether anyone reads and tests the result. Willison made the point in March 2025, when the phrase was already being applied to any AI-assisted programming: if you reviewed, tested and can explain the code an LLM wrote, "that's not vibe coding, it's software development" (Not all AI-assisted programming is vibe coding).

What makes the disciplined version engineering is the system built around the agent: instruction files, specifications and skills that shape the attempt, which Böckeler calls guides, and tests, linters and review that catch what it got wrong, which she calls sensors (Harness engineering for coding agent users, April 2026). Her conclusion is about where people fit: "A good harness should not necessarily aim to fully eliminate human input, but to direct it to where our input is most important." The engineer's own work moves to either end of the agent's: deciding what to build, and verifying what got built. Addy Osmani argues that this favours senior engineers, whose judgement is what the agent lacks, and raises the risk of skill atrophy earlier in a career (the evidence on skills is below).

Vibe coding has legitimate uses: a prototype that shows a product idea in an afternoon is worth having even if the code is thrown away, and at Odevo people outside engineering build small internal apps under a rule that the company's head of product operations keeps repeating to them: "you build it, you own it". The trouble starts when vibe-coded software meets production. Warchalowski's verdict on our podcast was that "vibe coding in a brownfield project, I think that is the worst thing that you could do." The best-known cautionary tale is from July 2025, when SaaStr founder Jason Lemkin ran a public vibe coding experiment on Replit and the platform's agent deleted his production database during a code freeze (Lemkin). In Stack Overflow's 2025 survey, 72% of respondents said vibe coding was not part of their work.

What the evidence says about productivity and quality#

The evidence is mixed, and it depends on who is measured, on what, and how. Most of it also predates today's agents.

Controlled experiments and the perception gap

The most cited study is METR's randomised trial from early 2025. Sixteen experienced open-source maintainers worked on 246 real issues in repositories they knew well, with and without AI tools: "When developers are allowed to use AI tools, they take 19% longer to complete issues." They had expected a 24% speed-up and, afterwards, still believed they had been sped up by 20% (METR, July 2025). METR warned against reading this as proof that AI slows developers down in general, and said in February 2026 that the effect had probably moved in AI's favour since. What survives is the gap between felt and measured speed.

Gains depend on the task and the codebase

Research led by Yegor Denisov-Blanch at Stanford, drawing on the git histories of more than 100,000 engineers, found that AI's productivity effect varied sharply by task: simple work on new code gained most, complex work on existing code gained least.

A 2026 study co-authored by Denisov-Blanch is closer to the agentic era. It followed one company's "2x mandate" across 802 developers and nearly 200,000 pull requests: throughput per developer reached "2.09x the pre-mandate baseline" by April 2026, and "per-reviewer load roughly doubled and automated review overtook human review" (arXiv 2607.01904).

The amplifier

DORA's 2025 research, based on nearly 5,000 survey responses, found that AI adoption goes with higher delivery throughput and with more delivery instability. Its central finding is that "AI's primary role in software development is that of an amplifier": it "magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones" (2025 State of AI-assisted Software Development).

Quality, security and skills

• Maintainability. GitClear's analysis of 211 million changed lines found copy-pasted lines rising from 8.3% to 12.3% between 2020 and 2024, while lines associated with refactoring fell from 25% of changes in 2021 to under 10% (GitClear, 2025). The trend coincides with AI adoption without isolating it as the cause.
• Security. Veracode's spring 2026 tests of more than 150 models put the security pass rate at around 55% (Veracode, 2026). This is raw model output that nobody reviewed.
• Learning. In a randomised trial of 52 mostly junior engineers learning a new Python library, those who used AI assistance scored 50% on a follow-up quiz against 67% for those who coded by hand (Anthropic, January 2026). It measured immediate understanding, with a chat assistant rather than an agent.

The pattern across the studies is that agents speed up work which is easy to specify and verify, in codebases with good tests, and move the constraint to review, integration and product decisions.

Agentic coding for enterprises#

For an enterprise, buying the licences is the easy part. The hard parts are getting hundreds of engineers to change how they work, governing agents that act on real systems, absorbing the review load and knowing whether it is paying off.

Access is not adoption

Gartner forecasts that 90% of enterprise software engineers will use AI code assistants by 2028, up from less than 14% in early 2024 (July 2025), and use and effective use are different things. Pini Reznik warns that a mandate "usually backfires, because it arrives as pressure without any of the support that would make the pressure fair" (Why AI Adoption Is a Leadership Problem). re:cinq's AI Adoption Ladder places agentic coding at stages 2 to 4, where the bottleneck moves from education to review at AI speed and then to context, security and ownership.

People

Resistance is rarely one thing, and governance barriers, stalled motivation and worries about professional identity each need a different response. Drifting accountability needs a firm line: "the AI cannot go on the chopping block. Whatever the tooling contributes, the developer owns the output" (Why Your Engineers Are Resisting AI). Running many agent sessions at once has also led to burnout: Elliott Beaty of Fruition told our podcast about "sending developers home for like a full week" to recover.

Security and governance

A coding agent reads untrusted text, from issues, dependencies and web pages, and it can act. Willison's "lethal trifecta" names the dangerous combination: access to private data, exposure to untrusted content and the ability to communicate externally. An agent with repository secrets, a web search tool and permission to push code has all three, and The Spec Is the Attack Surface explains why better prompts do not patch it: "LLMs process instructions and data in the same channel." The controls that follow are sandboxed execution, credentials scoped to the task, separate development and production systems, human approval before merge, and treating repository content as input that can carry instructions.

Review, cost and measurement

When code is cheap to produce, reviewing it becomes the scarce activity, and the 2x mandate study above found per-reviewer load roughly doubling. Past a certain rate of AI authorship, review stops working as a quality gate and starts slowing output without adding much coverage. Anthropic's documentation puts the average enterprise deployment of Claude Code at "around $13 per developer per active day and $150-250 per developer per month" (Manage costs). Because self-reports overstate gains, judging the investment needs delivery metrics and pull-request data from before and after the rollout.

What it looked like at Odevo

Odevo, a Swedish property management platform, engaged re:cinq to move its engineering organisation of around 100 developers to agentic coding. About half of them were hesitant about AI at the start. The programme ran a pilot cohort first, then the rest in cohorts, failure modes first. By the measures in the case study, agentic coding usage across the engineering organisation rose by 400%, and the share of developers hesitant about AI fell from about half to none.

How to get started with agentic coding#

For an individual developer

• Start with work you can verify. A bug with a reproduction or a failing test is a better first task than a new feature. Give the agent the check and let it iterate.
• Let the agent build and run the software. A working development environment turns guessing into testing.
• Plan, then keep sessions small. Agree a plan for anything non-trivial, give the agent one piece at a time, and start a fresh session when it goes in circles.
• Grow the instruction file from mistakes. Add a line when the agent repeats an error, and delete lines that stop earning their place.
• Read every diff you ship. The failure modes above are a list of what to look for.

For a team or engineering organisation

• Ask whether coding is the bottleneck. If work waits in review, QA or product decisions, faster coding will lengthen those queues.
• Run a pilot cohort. A small first group surfaces practical problems, such as development environments, before they reach everyone.
• Teach behaviour and failure modes along with the tools. Benedikt Stemmildt's advice on our podcast is to "focus on that behavioral change and not on kind of like, this is the tool and this is how it works."
• Put guardrails in place before scaling. Sandboxes, scoped credentials and merge policies are cheaper to set up for ten engineers than to retrofit for a hundred.