What Makes a Coding Tool an “Agent”?
Most AI coding tools work like autocomplete. You type a line, the tool predicts the next few characters, and you accept or reject. That is code completion. It responds to what you are doing right now.
An agent works differently. You describe a goal (“fix the failing auth tests”) and the tool figures out the steps on its own. It reads your test output, locates the broken code, writes a fix, runs the tests again, and keeps going until they pass. The key difference is autonomy. A completion tool waits for your next keystroke. An agent takes your objective and executes against it.
How Does the Agentic Loop Work?
Regardless of which tool you use, every AI coding agent follows the same basic cycle. Anthropic calls it the agentic loop, but the pattern is universal.
The loop has three phases that blend together. First, the agent gathers context by reading your files, error logs, and project structure. Then it plans and acts, editing files or running commands. Finally, it verifies the result by checking test output, build status, or linter results. If verification fails, it reads the error and loops back to the planning phase.
When you ask Claude Code to refactor an authentication module, it might read 15 files, edit 6, run the test suite 4 times, and fix 3 intermediate errors before finishing. A single prompt kicks off dozens of tool calls under the hood.
Here is what a typical agent interaction looks like in the terminal:
# You give Claude Code a task
$ claude "fix the failing tests in src/auth"
# Claude reads the test output
> Running npm test...
> Found 3 failing tests in auth.test.ts
# Claude traces the failures to source code
> Reading src/auth/middleware.ts
> Token validation doesn't handle expired tokens
# Claude makes a fix and re-runs
> Editing src/auth/middleware.ts
> Running npm test...
> 2 tests passing, 1 still failing
# Claude reads the remaining failure and iterates
> Missing mock for refresh endpoint
> Editing tests/auth.test.ts
> Running npm test...
> All 3 tests passingEach step feeds information into the next. The agent does not need you to say “now run the tests” or “now read that file.” It recognizes what is needed based on what it learned in the previous step.
When Should You Use an Agent?
If the task requires switching between more than two files or running a verification step to confirm the change worked, an agent will save you time. Debugging a test failure that requires reading error output, tracing it to a source file, and applying a fix is exactly the kind of multi-step workflow agents handle well.
Code completion is still faster for single-file work. Writing a function body, filling in boilerplate, generating a type definition. Those tasks do not need the overhead of a full agentic loop. They need fast inline suggestions.
A practical way to think about it. Tasks with clear success criteria (tests pass, build succeeds, linter is clean) give the agent a stopping condition it can verify. Tasks without measurable outcomes (“improve the codebase”) leave the agent guessing when to stop.
What Can Agents Not Do Yet?
Agents handle implementation tasks well when the goal is specific and the outcome is testable. They struggle with decisions that require business context or team knowledge.
Choosing between a monorepo and multi-repo setup, deciding which database fits your access patterns, evaluating whether a migration is worth the operational cost. Those decisions depend on information the agent does not have access to. An agent can execute a migration once you have decided to do it. It cannot tell you whether you should.
They also degrade on unbounded prompts. “Add input validation to the /users endpoint and write tests for it” gives the agent a target and a verification path. “Make the API more secure” does not. The more specific your prompt, the better the result.
The rest of this course walks through Claude Code’s agent system from the ground up. The next lesson covers how Claude Code’s four building blocks fit together before you start configuring anything.