For roughly a decade, "AI in the editor" meant one thing: a model that finished the line you were already typing. Inline completion was, and remains, a genuinely useful tool. It shortens the distance between intent and keystrokes, and it does so without asking you to change how you work. You stay the author. The model is a fast, occasionally inspired, occasionally wrong, typing assistant sitting just behind your cursor.
Agentic coding is a different tool altogether, not a faster version of that one. Instead of suggesting the next token, an agent reads a codebase, forms a plan, runs commands, edits files, observes the results of those edits, and iterates toward a goal you described in a sentence or two. The unit of work becomes the task rather than the line. That shift sounds incremental, but it relocates the engineer from the keyboard to the review seat, and it moves the hard problem from writing code to trusting it.
This is the first article in a series on engineering with Claude Code. Before we get to context, permissions, extension and orchestration, we need a shared model of what the category actually is, and why treating an agent as "autocomplete with ambition" leads people to use it badly. So this piece is the orientation: the loop the agent runs, what it is good and bad at, and the new skills it asks of the people driving it.
Two different tools, not two grades of one
The distinction needs stating precisely, because the language we use ("AI coding") collapses two things that behave nothing alike.
Inline completion is reactive and local. It responds to your immediate context (the few hundred lines around the cursor) and proposes a continuation. It has no goal of its own, takes no actions in the world, and cannot tell whether its suggestion compiled, let alone whether it was correct. You are the loop: you accept, reject, edit, and move on. The model never finds out how the story ended.
An agent is goal-directed and situated. You give it an objective, say "add pagination to the orders endpoint and update the tests", and it operates with agency: it explores the repository to understand the conventions, decides on a sequence of steps, makes edits across several files, runs the test suite, reads the failures, and adjusts. It closes its own loop, and that is the real difference: one completes text, while the other pursues an outcome and checks whether it got there.
An autocomplete engine answers the question "what comes next?" An agent answers "how do I get this done?" and then tries to do it. Treating the second like a chattier version of the first is the most common way teams get poor results from a capable tool.
Neither is strictly better. Inline completion is unbeatable for the tight, in-flow editing you do when you already know exactly what you want to write. An agent earns its keep on the work you would rather delegate: the broad, mechanical, or exploratory tasks where describing the goal is faster than performing every keystroke yourself.
The agent loop
Everything an agent does is a variation on a single cycle. It gathers context, forms a plan, takes an action (an edit or a command), observes what happened, and corrects. Then it repeats until the goal is met or it gives up and asks you. The loop is simple to draw and worth getting into your head, because most of the skill of working with an agent is the skill of intervening at the right point in it.
┌─────────────────────────────────────────────┐
│ │
v │
┌──────────┐ ┌────────┐ ┌──────────────┐ │
│ GATHER │────>│ PLAN │────>│ ACT │ │
│ context │ │ a step │ │ edit / run │ │
└──────────┘ └────────┘ └──────┬────────┘ │
^ │ │
│ v │
│ ┌──────────────┐ │
│ │ OBSERVE │ │
│ │ tests, output │ │
│ └──────┬────────┘ │
│ │ │
│ ┌─────────────────────┴──────┐ │
└────────────│ CORRECT (goal met? loop) │──────┘
└────────────────────────────┘
│
v (done, or stuck → ask the human)Two properties of this loop matter more than the rest. First, the agent observes its own actions: when it runs the tests and reads a stack trace, it is feeding the result back into the next plan. That feedback is the source of most of its power and most of its surprises. Second, the human stays in the loop as its supervisor, choosing the goal, watching the actions, and stepping in when the agent's correction is heading somewhere wrong. The later articles in this series are, in effect, about controlling each stage of this cycle: shaping gather with context, gating act with permissions, widening it with extensions, and running several loops at once with orchestration.
What it is genuinely good at
The honest way to evaluate an agent is by the shape of the task, not the difficulty of the underlying problem. Agents excel where the work is broad, well-specified, and verifiable, even if it is voluminous:
- Multi-file changes. "Rename this concept across the codebase, including call sites, tests and docs" is tedious and error-prone by hand and a natural fit for something that can search, edit, and re-check exhaustively.
- Boilerplate and scaffolding. A new endpoint that follows three existing endpoints, with the matching tests and wiring, is a pattern-completion task at the scale of files rather than lines.
- Exploration. "Where is the rate limiting actually enforced, and what happens when it trips?" An agent can trace a path through an unfamiliar codebase and report back far faster than a cold read.
- Migrations and mechanical refactors. Moving from one library, API version, or convention to another is repetitive, rule-governed work, which is exactly where tireless iteration beats human patience.
- "Do X across the repo." Anything that is conceptually simple but physically spread out plays to the agent's reach and its willingness to verify each instance.
The common thread is that these tasks have a checkable definition of done. The agent can run something (a test, a build, a search) and the loop can close. When the goal is verifiable, the agent's habit of observing its own work becomes a strength.
Where it struggles
The failure modes are the mirror image of the strengths, and they are predictable enough to plan around:
- Ambiguous intent. If the goal is underspecified, the agent will not pause to wonder what you meant the way a careful colleague might. It will pick an interpretation and build on it confidently. Vague input produces plausible, fully-formed, wrong output.
- Deep, novel design. Genuinely new architecture, the kind that means holding competing constraints in tension and inventing a structure with nothing to imitate, is not pattern completion. Agents are weakest precisely where there is nothing to pattern-match against.
- Silent, confident wrongness. This is the one that worries me most. An agent can produce code that is clean, idiomatic, well-commented, and subtly incorrect, and it will present that code with exactly the same calm assurance as code that is right. There is no tremor in the output to warn you. Confidence is not correlated with correctness, and the polish actively works against your scepticism.
None of these are reasons not to use the tool. They are reasons to use it with your eyes open: to specify carefully, to keep the hard design decisions for yourself, and never to mistake a confident diff for a correct one.
The new skills this demands
This is the part that catches experienced engineers off guard. Your existing skills still matter, but the agent changes which of them is on the critical path. The bottleneck used to be production: how fast and accurately you could turn intent into working code. With a capable agent, production is cheap. The bottleneck moves to specification and verification: saying precisely what you want, and confirming that what came back is actually right.
Four skills move to the foreground.
Specifying intent precisely. A loose prompt is the single biggest cause of disappointing results. "Make the API faster" invites guesswork; "add a cache to the product lookup, keyed by SKU, invalidated on write, with the existing tests still passing" gives the agent a target it can actually aim at and check itself against. The discipline of writing a clear, constrained brief (something good engineers already do for colleagues) becomes a core daily skill rather than an occasional one.
Reading and reviewing diffs critically. The agent's output is a change set, and your job is to review it as you would a pull request from a fast, prolific, slightly overconfident teammate. That means reading for what is not there as much as what is: the missing edge case, the test that asserts the happy path only, the silent change to a default. Diff literacy, the ability to scan a change and sense where the risk is concentrated, is now a primary skill rather than a code-review afterthought.
Verifying behaviour, not trusting output. Reading the diff is necessary and not sufficient. The only reliable signal is observed behaviour: run it, test it, exercise the edge that worried you. The agent claiming the tests pass is a claim; you watching them pass against the cases you care about is evidence. Building the habit (and the harness) to verify rather than trust is the difference between an agent that accelerates you and one that quietly accumulates defects.
Steering rather than typing. Working well with an agent feels less like writing and more like directing: setting the goal, watching the early moves, redirecting before a wrong plan compounds, and knowing when to take the keyboard back for the one tricky function that is genuinely yours to write. The skill is interruption with judgement: catching a bad trajectory at step two rather than reviewing the wreckage at step ten.
Taken together, these mark a real shift in the engineer's role: from author to something closer to director and reviewer. You are still wholly responsible for the result. You are simply responsible for it in a different posture, describing, supervising, and verifying rather than typing every character. For senior engineers this is mostly good news, because specification, review and verification are exactly the skills experience sharpens. The risk is for anyone who outsources the judgement along with the typing.
Trust is the bottleneck now
If you take one idea from this article into the rest of the series, make it this one: the constraint on agentic coding is now how confidently you can trust the code, not how fast you can produce it. Typing speed has stopped mattering. Verification, meaning the ability to know that a change is correct, safe, and complete, is the scarce resource, and almost everything else in engineering practice now arranges itself around protecting it.
A short, deliberately generic session shows the shape of a single turn through the loop. The exact wording and tool names vary, and you should read the actions as illustrative rather than a literal transcript:
> add pagination to the orders endpoint and keep the tests green
Plan
1. read the orders route & its current tests
2. find how pagination is done elsewhere in the repo
3. apply the same pattern to /orders
4. update the tests, then run the suite
Exploring ... reads routes/orders, finds an existing
cursor-pagination helper used by /invoices
Editing ... routes/orders (+ limit / cursor params)
tests/orders.test (+ two pagination cases)
Running ... the test suite
14 passed, 1 failed < orders returns full list on bad cursor
Correcting ... handle the invalid-cursor case, re-run
15 passed
Done. Review the diff before you merge — note the default
page size I chose (25); confirm that matches your API contract.Notice what the human still owns in that exchange. The goal was a human decision. The default page size was an assumption the agent surfaced. Surfacing it is good behaviour, but confirming it is your job. And "the tests pass" is the agent's report, not your verification; the responsible next move is to read the diff and exercise the endpoint yourself. The loop did the work. The trust is still yours to grant.
That is the thread the rest of this series pulls on. If trust is the bottleneck, then everything worth doing is about earning it deliberately: shaping the context the agent reasons over so its plans are grounded; setting permissions so its actions are safe by construction; extending it with tools and project knowledge so it works the way your codebase expects; and automating and orchestrating it so that verification scales alongside production rather than falling behind it. The next article starts where the loop starts, with context, and why for an agent it is less an input to the product than very nearly the product itself.
NK