How Claude Code Actually Works: The Agentic Loop, Not Autocomplete

Autocomplete predicts the next few tokens from the file you're looking at. Claude Code does something structurally different: it runs a loop — decide what to do, do it with a real tool, look at what actually happened, decide what to do next — until the task is done or it needs you. Here's what that loop actually looks like, tool call by tool call.

Autocomplete vs. an agent

	Inline autocomplete	Claude Code (agentic)
Input	Current file, cursor position	Your request, plus whatever it chooses to read
Action	Predicts next tokens	Chooses and executes tools: read, search, edit, run commands
Feedback	None	Sees command output, test results, errors — and reacts
Scope	One file, one cursor	Any number of files, your terminal, your git history
Stops when	It emits a suggestion	The task is verified done, or it needs your input

The difference that matters is the feedback loop. Autocomplete has no way of knowing if the code it suggested even compiles. Claude Code can run pytest, see a failure, read the traceback, fix the function, and re-run the tests — without you doing anything in between.

The loop, concretely

Every task cycles through three phases:

1. Gather context — read a file, grep for a symbol, check test output
2. Take action — edit a file, run a command, stage a commit
3. Verify — did the edit apply, did the tests pass, did the command exit 0

Given "fix the failing tests," a plausible sequence:

1. Bash    -> run the test suite, see what fails
2. Read    -> open the file the failing test exercises
3. Grep    -> find other callers of the broken function
4. Edit    -> apply the fix
5. Bash    -> re-run the tests
   still failing?  -> back to step 2
   passing?        -> report what was wrong and what changed

Nothing here is scripted — it's what emerges from feeding each tool result back into the next decision. That's the mechanical definition of "agentic": the next action is a function of the last observation, not a fixed script.

Two details explain behavior that otherwise looks mysterious. Edit requires a prior Read — it won't blindly rewrite a file it hasn't looked at this conversation. And Edit is exact-string replacement, not a diff or regex — if the snippet it's trying to match isn't verbatim present, the edit fails outright rather than silently applying something close-enough.

Permission modes: the safety/autonomy dial

Handing a model shell access is powerful and genuinely risky, so Claude Code gates it with permission modes:

• Auto — reads, edits, and shell commands run without prompting; a separate classifier model reviews actions in the background and blocks risky categories (force-pushes, prod deploys, curl | bash). Default on Pro/Max/Team.
• Manual — asks before every edit and command. Default on Enterprise.
• Accept edits — reads and file edits run free; good for fast iteration you'll review with git diff afterward.
• Plan — research and propose, but zero edits until you approve.
• Bypass permissions — nothing gated, ever. Isolated containers only, never your primary machine.

The dimension that actually matters is reversibility. A file edit is cheap to review and cheap to undo — Claude Code snapshots files before editing specifically so you can revert with /rewind. A force-push or a production migration is a different category entirely, which is why even the most permissive modes still gate that class of action separately.

Where it remembers things

Sessions don't share memory by default — each one starts with a fresh context window. What persists is whatever you put in a CLAUDE.md at your project root (read at the start of every session), plus whatever Claude saves to auto-memory as it learns your project. If you want it to reliably know "we use pnpm, not npm," write it down — don't rely on having mentioned it three sessions ago.

---

I wrote a longer, interactive version of this — with a walkthrough diagram of the loop, the full permission-mode reference, and a practice quiz — here: Claude Code Fundamentals