Claude Code

Claude Code’s design bet is that the shell is the right interface for a coding agent, because the shell is where everything else already is: your test runner, your linter, your version control, your build. Rather than reimplementing those inside an editor, the agent uses them.

Why the terminal turns out to matter

An editor-based assistant proposes a change and hands it to you to verify. A terminal-based agent can verify it itself, because everything needed to verify is a command away. It writes the change, runs the suite, reads the failure, and tries again — a loop that runs without you, and one that converges on tasks where “correct” is machine-checkable.

That difference compounds. For well-specified work with a fast feedback loop — fixing a failing test, migrating a call site, tightening types until the compiler is satisfied — the output arrives closer to reviewable than suggestion-based tools manage, because the obvious errors were already caught and fixed by the agent rather than by you.

It also means the tool inherits your whole environment. If your project has a Makefile, the agent uses it. If your tests take four minutes, the loop takes four minutes. The quality of the agent’s work is bounded by the quality of your feedback signal, which is an unusually honest constraint.

Where it does well and where it drifts

Strongest on tasks with a clear definition of done: a reproducible bug, a mechanical refactor across many files, dependency upgrades, filling in test coverage for an existing module. Here the agent’s ability to iterate against real output is decisive.

Weakest on open-ended design. Asked to “improve the architecture”, it will produce a large, confident, plausible diff that reflects general good practice rather than the specific constraints your system actually operates under. The tool cannot know which of your ugly compromises are load-bearing.

The other drift pattern is scope. Long sessions accumulate context, and an agent that has been working for an hour starts making changes adjacent to the task rather than in it. Short, scoped sessions with a clear finish line produce better diffs than marathon ones.

The security posture is not optional

This is software with file-write and command-execution access to your machine, driven by a model reading text that may include untrusted content — a dependency’s README, an error message, a fetched web page. Prompt injection is not theoretical for an agent with a shell.

The controls that matter, in order: configure permissions deliberately rather than approving everything, run on a branch so git is your undo, never point it at a repository holding production credentials, and review every diff as untrusted regardless of how good the previous ten were. Teams that skip these steps eventually learn why they matter, usually in a way that generates a postmortem.

Cost and access

Claude Code is included in paid Claude plans and is also available with usage-based API billing. The plan route is predictable and the right default for individuals. The API route is worth modelling before committing a team to it: agentic loops are token-hungry by construction, because every iteration re-reads context, and a long autonomous session on a large repository is not cheap.

The lever most teams miss is scoping. An agent given a narrow task with the relevant files named finishes in a fraction of the tokens one given a vague task and a whole repository consumes, and produces a better diff besides. Cost discipline and output quality point the same direction here.

Who should use something else

Developers who want AI assistance without changing how they work should stay in their editor with Cursor or GitHub Copilot. Teams that want an open-source agent they can point at any model — including a self-hosted one — should look at Aider, which occupies a similar terminal-shaped niche without the vendor tie.

Our full walkthrough of setup, permissions and practical workflows is in the Claude Code guide.