↓ Skip to main content
sdd.sh
sdd.sh
  1. Articles/

Agentic Coding 101: When Your AI Plans, Builds, Tests, and Ships

·1423 words·7 mins·
Table of Contents

Most engineers still think of AI coding as advanced autocomplete. They’re missing the paradigm shift.

“Autocomplete mode” describes roughly 80% of how developers currently use AI coding tools. You’re writing a function, Copilot suggests the next line, you tab to accept. You open a chat pane, describe a bug, the model suggests a fix, you apply it. You stay in the loop at every step. The AI is a sophisticated suggestion engine — faster and more capable than a code search, but fundamentally reactive. It waits for your next move.

Agentic coding is something else entirely. You give the AI a task and it runs until the task is done — or it hits a genuine decision point and asks for guidance. It reads your codebase. It runs your tests. It sees the failures. It makes fixes. It runs your tests again. It may spawn sub-agents to handle parallel workstreams. You’re not tabbing to accept suggestions; you’re reviewing the completed work.

This isn’t a bigger Copilot. It’s a different paradigm.

What Makes Something Actually Agentic
#

The term gets abused. Cursor adds an “agent mode” and calls itself agentic. GitHub Copilot announces “autopilot” and implies autonomy. But labeling a feature “agentic” doesn’t make it so.

True agentic coding requires three things:

1. Tool use. The model must be able to take actions beyond generating text. Reading files, writing files, running shell commands, executing tests, making API calls, searching documentation. An AI that can only output text can describe what code to write. An AI with tools can write and run it.

2. Long-horizon planning. A real agentic task spans dozens of steps. The model must maintain a coherent plan across the full task — not just the next token, not just the next line, but the entire arc from current state to goal. This demands genuine working memory (long context) and explicit planning behavior, not just a chain of suggestions.

3. Autonomous iteration. When tests fail, the agent doesn’t stop and ask “what should I do?” It reads the failure output, identifies the root cause, makes a fix, and runs tests again. The loop continues until the task succeeds or the agent hits a decision it can’t resolve without you.

IDE plugins that suggest multi-file edits and call it “agentic” are missing items 2 and 3. They’re multi-file suggestion engines. Better than single-file suggestion engines, but not agents.

The Agentic Loop
#

The core pattern is straightforward:

1. Understand → read relevant files, check tests, understand constraints
2. Plan → decompose the work, identify dependencies, estimate scope
3. Implement → write code following your conventions and patterns
4. Verify → run tests, check types, validate against requirements
5. Fix → address failures and iterate back to step 4
6. Report → summarize what was done and why

This loop runs autonomously. You hand off a task, the agent runs the full cycle, and you come back to a summary of completed work. For well-defined tasks with good automated tests, you often don’t need to intervene at all.

The quality of each step depends on three things: the capability of the underlying model, the quality of context available to the agent, and the tooling available for execution and verification.

The Stack You Need
#

A capable model. Not every model can run a reliable agentic loop. The limiting factor is usually instruction-following quality on long, multi-step tasks and tool-call accuracy. A model that hallucinates tool arguments or loses its plan halfway through will fail on anything non-trivial. As of May 2026, Claude Opus 4.7 is the reference for agentic coding: 87.6% SWE-bench Verified, one-third the tool errors of its predecessor in agentic loops, and native multi-agent coordination for parallel workstreams.

Context about your codebase. Generic Claude knows how to write code. It doesn’t know your conventions, your architecture, your testing patterns, or your service boundaries. This is what CLAUDE.md is for. A well-written CLAUDE.md tells the agent what it needs to know to make decisions your team would endorse: which patterns to use, which to avoid, where the key files are, what the testing strategy looks like. An agent without this context will write technically correct code that doesn’t fit your codebase.

Tools for execution. The agent needs to read and write files, run shell commands, execute tests, and optionally make MCP calls to external systems. The richer the toolset, the more complete the verification loop. An agent that can run your test suite catches its own bugs. An agent that can only edit files cannot.

Claude Code is the reference implementation of this stack. Terminal-native (full shell access), built on Opus 4.7, ships with CLAUDE.md support, and has native MCP integration for extending the tool surface. It was designed for the agentic loop from the ground up — not retrofitted with agent features on top of an autocomplete engine.

When to Use Agentic Mode
#

Not every coding task benefits from an agentic approach. A useful heuristic:

Strong candidates for agentic mode:

  • Well-defined tasks with clear acceptance criteria (ideally a passing test suite to aim for)
  • Work that spans multiple files or requires understanding existing code structure
  • Tasks with mechanical structure that doesn’t require creative product judgment
  • Anything that benefits from automated verification (tests, type checks, linters)

Real examples: migrating an API endpoint from REST to GraphQL, adding a new data model and wiring up CRUD operations, writing comprehensive tests for a module that has none, refactoring code to match updated conventions, implementing a spec from a requirements document.

Poor candidates for agentic mode:

  • Ambiguous tasks (“improve the dashboard”)
  • Tasks requiring significant creative or product judgment (“design the auth flow”)
  • Work that can’t be automatically verified (“write better documentation”)
  • Very small and specific changes (“fix the typo on line 47”)

For poor agentic tasks, regular AI assistance — chat, inline suggestions, a quick prompt — is faster and more appropriate. Your judgment needs to stay in the loop.

Common Pitfalls
#

Too wide a permission scope. An agent with unconstrained write access will make changes you didn’t anticipate. Define what it can and can’t touch. Claude Code’s permission system — allow/deny lists, cautious mode — exists for this reason. The discipline of scoping permissions is also good practice: it forces you to be explicit about what you’re actually asking for.

No CLAUDE.md. An agent writing code without codebase context defaults to generic best practices. It will use patterns wrong for your stack, import the wrong libraries, and miss conventions that matter to your team. This is the most common reason agentic coding underdelivers. Investment in a good CLAUDE.md compounds across every task you run.

Vague task specification. “Fix the bug” is not a task. “The UserSync service fails when the upstream API returns a 429. Fix it to retry with exponential backoff up to 3 times, with unit tests” is a task. Agentic coding amplifies your specification quality — precise spec, good output; vague spec, variable output.

Skipping verification. The power of agentic coding comes from automated feedback loops. If you hand the agent a task with no automated tests, it can’t self-verify. Either it writes its own tests (good, adds time) or it delivers code that might be subtly wrong. Test coverage pays off most in agentic workflows, because it’s the mechanism by which the agent proves its own work.

Your First Agentic Task
#

If you haven’t run a full agentic task with Claude Code, here’s a good first experiment:

  1. Write a CLAUDE.md for your most active repository — three paragraphs covering the stack, the main conventions, and what to avoid.
  2. Find a module with low or no test coverage.
  3. Give Claude Code a specific target: “Add comprehensive unit tests to src/payments/processor.ts. Aim for at least 80% line coverage. Run the tests to verify. Don’t modify the implementation files.”

Watch it read the module, plan the test cases, write the tests, run them, find the failures, fix them, and iterate. When it finishes, review what it produced.

That’s the loop. That’s agentic coding.

The engineers who internalize this workflow in 2026 aren’t writing less code — they’re shipping more of it. They’ve learned to specify tasks precisely, verify them with automated tooling, and review the output rather than producing it line by line. The bottleneck shifts from implementation speed to specification quality. That’s a shift worth making.

Sources:

Related