Agentic coding
Last verified: June 2026· definition
Where autocomplete suggests the next line and chat answers a question, an agentic coding tool takes a goal — “add pagination to this endpoint and cover it with tests” — and works it: reading the codebase, making edits across files, running the test suite, reading the failures, and trying again. Claude Code, Cursor’s agent mode, and Copilot’s agent are the mainstream examples.
The quality of the result depends far more on the environment than on the prompt. An agent with fast tests, strict types, clear module boundaries, and a good context file behaves like a competent engineer. The same agent in a codebase with none of those thrashes, because it has no feedback signal to correct against.
The commonly cited “80% problem” captures the failure mode: an agent gets a task most of the way there quickly, and the last stretch — the edge cases, the integration, the bit that has to actually be right — takes longer to review and repair than writing it would have. That gap narrows as the codebase gets more agent-ready, and widens when it isn’t.
The codebase is the real input
The strongest predictor of whether an agent succeeds on a task is not the prompt but the environment it works in. Fast, reliable tests give it a feedback signal it can act on. Strict types turn a class of mistakes into immediate errors rather than silent bugs. Clear module boundaries mean a change stays local instead of rippling. A codebase with slow flaky tests and loose typing gives an agent almost nothing to check its work against, and it will confidently produce plausible code that does not work.
Review changes shape more than volume
When an agent produces a large, coherent-looking diff, the failure mode of review shifts. Reviewers skim structurally sound code more readily than messy code, and machine-written code is almost always structurally sound. The practices that hold up are requiring the agent to show test evidence, keeping changes small enough to actually read, and reviewing intent against the diff rather than reading the diff on its own terms.
Where agentic coding genuinely struggles
Tasks with unstated context are the persistent weak spot — anything depending on why a decision was made, undocumented conventions, or knowledge that lives in someone’s head. Agents also struggle where the definition of done is ambiguous, because they optimise for the checkable signal, and where a change requires holding a large amount of distributed context at once. Well-bounded tasks with clear verification are where the technique earns its keep.
Common misconceptions
MythAgentic coding replaces the need to understand your codebase.
RealityIt raises the value of understanding it. Someone has to judge whether the change is correct and whether the approach was right, and that judgement requires exactly the context the agent lacks.
MythBetter prompting is the main lever on quality.
RealityTest quality, type coverage, and module boundaries matter more. Prompting improvements plateau quickly; environment improvements compound across every task the agent attempts.
MythMore autonomy is always better.
RealityAutonomy is useful in proportion to how well the task can be verified. On work with a clear pass/fail signal it is powerful; on ambiguous work it produces confident output nobody can efficiently check.
Frequently asked questions
What is the difference between agentic coding and autocomplete?
Scope and control flow. Autocomplete suggests the next fragment and a human accepts or rejects it, keeping the human in the loop continuously. An agentic tool takes a whole task, plans it, edits across multiple files, runs tests, reads failures, and iterates until it believes it is done. The human moves from approving each line to specifying the goal and reviewing the result, which is a meaningfully different activity.
How do I make our codebase work well with coding agents?
Prioritise the feedback loop. Fast reliable tests are the single most valuable investment, because they are what the agent uses to check itself. After that: strict typing so errors surface immediately, clear module boundaries so changes stay contained, and written conventions the agent can read rather than infer. These are the same properties that make a codebase pleasant for humans, which is why the work rarely feels wasted.
Should we let agents commit directly?
Treat agent output the way you treat output from a capable new engineer who does not yet know your system: it goes through review. The volume is higher and the code looks more polished than its correctness warrants, so the review gate matters more, not less. Direct commits are defensible for narrow, well-tested, low-blast-radius changes, but as a default policy it removes the control that makes the rest safe.
Go deeper
What is agentic coding?
Agentic coding is letting an AI coding agent plan, edit across files, run tools and tests, and iterate in a loop toward a goal — powerful for the first 80% of a change, and quietly expensive on the last 20% if you skip standards and review.
Agentic codingIs your codebase ready for AI agents?
Agents don't fail randomly on a repo — they fail predictably on the same things that slow down human engineers: fuzzy boundaries, missing tests, undocumented conventions. Readiness is just those weaknesses paid down deliberately.