What is agentic coding?

What agentic coding actually is (and how it differs from autocomplete)

For most of the last few years, AI in the editor meant autocomplete: you type, a model predicts the next few lines, you accept or reject. It is single-shot and stateless — the model has no plan, takes no actions, and never checks whether its suggestion was right. Useful, but fundamentally a faster keyboard.

Agentic coding is a different thing. An AI coding agent is given a goal and access to your repository plus real tools — a shell, a file editor, a test runner, sometimes a browser or a package manager. It then works toward the goal in a loop: it plans an approach, edits across multiple files, runs commands, reads the output, and decides what to do next. The distinction that matters is agency over a feedback loop. Autocomplete guesses; an agent acts, observes the consequences, and corrects itself.

This is what people mean when they name tools like Claude Code, Cursor's agent mode, GitHub Copilot's agent, or coding with Gemini. Under the hood they share the same shape: a capable model wrapped in a loop that lets it use tools and see results. The interesting engineering questions are almost never about the model — they are about the loop, the context you feed it, and the checks you put around it.

How the AI agent loop works

Strip away the branding and every coding agent runs roughly the same cycle. Plan: the agent reads the goal and enough of the codebase to form an approach — which files to touch, in what order. Edit: it makes concrete changes, usually as a series of targeted diffs rather than one giant rewrite. Run: it executes something to test its work — the build, a unit test, a linter, a script. Observe: it reads the output, including failures and stack traces. Iterate: it uses what it observed to make the next edit, and repeats until the checks pass or it runs out of road.

The loop is the whole point, because it lets the agent recover from its own mistakes. When a compile fails, it reads the error and fixes it. When a test breaks, it sees the assertion and adjusts. This self-correction is why an agent can take a vague request and return something that actually runs — and it is exactly why the quality of your feedback signals determines the quality of the output. An agent with a fast, comprehensive test suite converges on correct code. An agent with no tests converges on code that merely looks correct and compiles, which is a much more dangerous place to be.

Two things constrain the loop. The first is context — the agent can only reason about what it can see, so a sprawling, undocumented, inconsistent codebase makes it guess. The second is the stopping condition. An agent stops when its checks pass, so if your checks are weak, it stops early and confidently. Most bad agentic outcomes trace back to one of these two, not to the model being dumb.

A concrete example workflow

Say you need to add rate limiting to an internal API. A realistic agentic workflow looks like this. You give the agent a specific goal — 'add per-tenant rate limiting to the /reports endpoint, 100 requests per minute, return 429 with a Retry-After header' — and point it at the relevant service. That specificity matters: 'add rate limiting' invites the agent to invent scope; the detailed version constrains it.

The agent plans: it locates the middleware layer, finds where tenants are resolved, and identifies the existing test file. It edits: it adds a limiter, wires it into the middleware chain, and writes tests for the limit, the reset window, and the 429 response. It runs the test suite, sees two failures because the limiter's clock isn't injectable and a test can't advance time, and fixes that by refactoring to accept a clock. It reruns, everything passes, and it hands you a diff.

Now the real work starts, and it is yours. You read the diff. The happy path is fine. But you notice the limiter uses in-memory state, which silently breaks across multiple instances behind a load balancer — a correctness bug the tests never caught because they run in one process. You also spot that Retry-After is hardcoded rather than computed from the window. Neither is hard to fix, but neither would have surfaced without a human who understands the deployment topology. That gap — a working-looking change that misses the context the agent couldn't see — is the entire subject of the next section.

The 80% problem

The 80% problem is the practitioner's name for the defining frustration of agentic coding: the agent gets you roughly 80% of the way to a finished change astonishingly fast, and the remaining 20% — correctness under real conditions, edge cases, error handling, security, performance, and code that a human will still understand in six months — is slow, unglamorous, and unavoidably human. This is experience talking, not a measured statistic, but it is close to universal among engineers who have used these tools in anger.

The trap in the number is that the last 20% is not 20% of the effort. It is often most of the effort, because it is the part that requires judgement, whole-system context, and knowing what the tests don't test. An agent will happily produce a plausible implementation of a distributed lock, an auth check, or a migration — and plausible is precisely the failure mode, because it passes casual review and breaks in production. The faster the first 80% arrives, the stronger the pull to wave the rest through.

There is a second-order cost too. If you accept agentic output uncritically, the 20% you skipped compounds. Inconsistent patterns accumulate, abstractions drift, and the codebase becomes harder for both humans and future agents to reason about — which makes the next round of agentic work worse. The 80% problem is not a reason to avoid agents. It is a reason to be honest about where the time actually goes and to spend your engineers' attention on the 20% that only they can do.

Is agentic coding a trap?

Honest answer: it becomes a trap if you skip the guardrails, and a genuine multiplier if you add them. The trap is not the technology — it is the incentive it creates. Agents make it cheap to produce large volumes of code that looks done, and cheap production of plausible code is exactly the thing a healthy engineering org should be suspicious of. The live debate on Hacker News — engineers going back to writing by hand after two years of vibe coding, others noting how uncomfortably close vibe coding and serious agentic engineering have become — is really an argument about where the guardrails go, not about whether the tools work.

You fall into the trap when you treat the agent's output as trustworthy by default: no tests worth the name, review that skims a 600-line diff, no evals, no shared standards, and velocity measured in merged pull requests rather than working software. Under those conditions agentic coding will quietly lower your quality bar while feeling productive, which is the worst combination.

You avoid the trap by refusing to let the agent set the quality bar. Standards — a defined way this codebase does things — give the agent rails and give review a checklist. Tests and evals turn the agent's stopping condition into something you actually trust. Real human review stays non-negotiable, sized to the risk of the change, not the size of the diff. Do those and agentic coding is one of the better leverage improvements available to an engineering team. Skip them and the skeptics on the threads are right about you specifically.

How to adopt agentic coding well

The teams that get real value from agentic coding treat it as an engineering practice, not a tool purchase. Start with a golden path: a documented, opinionated way your codebase does common things — how you structure a service, handle errors, write tests, name things. Agents follow patterns extremely well, so a clear golden path is the highest-leverage thing you can give them. It also makes their output reviewable, because reviewers are checking against a known standard rather than judging every choice from scratch.

Invest in the feedback signals the loop depends on. Fast, meaningful tests are what let an agent self-correct toward correct code instead of merely-compiling code. Where correctness is fuzzy — anything involving an LLM, a heuristic, or a judgement call — build evals so 'it works' is a measurement, not a vibe. This is the single biggest difference between teams the agents help and teams the agents hurt.

Then put review at the diff, not the tool. Add hooks that run your linters, type checks, and tests before a human ever looks. Keep human review mandatory and scale its depth to risk: a copy change gets a glance, an auth or migration change gets a senior engineer reading every line and thinking about failure modes the agent couldn't see. Finally, measure the right thing — defects and rework, not raw output. If you want a structured version of all this wired into your own repos and CI, that is the shape of an internal AI coding workflow engagement, and it is mostly standards and review design, not model selection.