Claude Code: The Agentic Coding Tool for the Terminal That Actually Ships

Claude Code is Anthropic’s CLI for Claude. The tool runs in your terminal. It can read files, edit files, run shell commands, search the web, and iterate on multi-step coding tasks. The first time I used it, I expected the usual AI assistant experience: helpful but you do most of the work. Instead, I gave it a complex multi-file refactor and watched it work for 10 minutes, then test the result, then fix the test failures, then commit the result. The tool did the work. I reviewed the work. The work was good. After two months of daily use, Claude Code is in my regular rotation. This is what it does, what it does not do, and the trade-offs.

What Claude Code actually does

The tool is a Node.js application that runs in your terminal. The interface is a chat REPL (read-eval-print loop) inside the terminal. The model is Claude (Sonnet by default, Opus if you have a Max plan). The tool can read any file in your working directory, edit any file (with your approval), run shell commands (with your approval), and search the web (with your approval). The approvals are per-action. You see what the tool is going to do before it does it. The tool can do multi-step work autonomously. You give it a task, it works on it, it reports back. The tool respects your project’s git state. The tool will not commit changes without your explicit approval. The tool will not push to remote. The tool will not make destructive changes (rm -rf, etc.) without your explicit approval. The safety model is conservative.

Here are the specific safety mechanisms the tool enforces:

• Per-action approval: every file edit and shell command requires explicit human approval
• Destructive command detection: any command starting with ‘rm’, ‘sudo’, ‘dd’, or ‘mkfs’ requires typed confirmation
• Git safety: the tool will not commit, push, or force-push without explicit approval
• Path validation: the tool cannot access files outside the working directory without explicit approval
• Network isolation: the tool can only make web requests to whitelisted hosts by default
  The safety model is correct.

What “agentic” actually means in practice

Three patterns I use daily. The first is the “multi-file refactor” pattern. I give it a task like “refactor the authentication system to use JWT instead of session cookies” and it works through the change. It reads the relevant files. It plans the changes. It edits the files. It runs the tests. It fixes the test failures. It reports back. The work takes 5-15 minutes for a medium-sized refactor. The quality is high. The follow-up questions work (“why did you change that”, “can you also do X”, “what about edge case Y”). The second is the “explore the codebase” pattern. I give it a question like “how does the billing system work” and it reads the relevant files and explains. The answer cites specific files. The follow-up questions are natural. The third is the “fix the bug” pattern. I give it a bug description and the relevant error output. It reads the code. It proposes a fix. It implements the fix. It runs the tests. It reports back. The work is iterative. The safety net is the test suite. The human review is at the end. The trade-off is that the tool can make mistakes. The mitigation is the test suite and the human review.

What the approval flow actually looks like

The approval flow is per-action, not per-session. When the tool wants to read a file, no approval is needed (reads are free). When the tool wants to edit a file, you see a diff and approve. When the tool wants to run a shell command, you see the command and approve. When the tool wants to make a destructive change (rm, git push –force, etc.), you must type the full path or command to confirm. The approval flow is fast. The approval flow is the right balance. The trade-off is that you have to be paying attention. If you walk away from the terminal while the tool is working, the tool will pause at the first approval. The tool will not auto-approve. The tool is conservative. The tool is correct.

What the model capabilities actually are

The tool uses Claude Sonnet 4 by default. The model is good at code generation, refactoring, test writing, and bug fixing. The model is less good at long-running tasks (over 30 minutes of work) because the context window fills up. The model is less good at tasks that require deep domain knowledge (like “add HIPAA compliance to this healthcare app”) because the model does not have the domain knowledge in its training data. The model is very good at standard web development tasks (Python, JavaScript, TypeScript, Go, Rust, Java). The model is good at system administration tasks (bash, Docker, Kubernetes). The model is good at data engineering tasks (SQL, pandas, dbt). The model is mediocre at embedded systems, kernel development, and other low-level programming. The trade-off is that you need to know when to use the tool and when to do the work yourself. The tool is not a replacement for expertise. The tool is a multiplier for expertise.

What the cost actually is

The cost depends on your Claude plan. The free tier does not include Claude Code. The Pro plan ($20/month) includes Claude Code with Sonnet. The Max plan ($100/month or $200/month) includes Claude Code with Opus. The Pro plan is enough for personal use. The Max plan is needed for heavy daily use. The cost per query is roughly $0.05-0.30 depending on the model and the task complexity. The total monthly cost is hard to predict because it depends on usage. My monthly cost has been $20-50 (Pro plan with occasional Opus upgrades for hard tasks). The trade-off is that the cost is per-use. If you use the tool heavily, the cost goes up. If you use it lightly, the cost stays low. The alternative is to use the Claude API directly, which is more flexible but more work. for most developers, the Pro plan is right. for heavy users, the Max plan is right.

What the integrations actually look like

Claude Code integrates with the editor via a plugin. The VS Code plugin shows the tool’s progress in a sidebar. The JetBrains plugin does the same. The Vim plugin requires a manual setup. The Emacs plugin is in alpha. The integration is read-only (the tool does not edit files via the plugin, it edits via the terminal). The benefit is visibility. You can see what the tool is doing without leaving the editor. The trade-off is that the tool still does its work in the terminal. The editor is just a window. for most developers, use the editor plugin + the terminal side by side. The plugin shows the chat. The terminal shows the file edits.

What I would do differently if I were building this

Three things. The first is to add a “review” mode where the tool proposes changes without making them. The current model is “make changes with approval.” A “review” model would be “describe changes, then wait for explicit ‘go’ from the human.” The benefit is safety. The trade-off is more clicks. The second is to add multi-repository support. The current tool is one repository at a time. Real projects often have multiple repositories. The implementation is straightforward. The benefit is real. The third is to add a “stop and ask” mode where the tool pauses on any uncertainty. The current model is “make a best guess and proceed.” A “stop and ask” model would be “ask before doing.” The benefit is fewer mistakes. The trade-off is more interruptions.

What this means for the AI coding tool space

Claude Code is a credible competitor to Cursor, Windsurf, and other AI coding tools. The terminal-first approach is the right call for developers who live in the terminal. The agentic capabilities are the right call for complex tasks. The safety model is the right call for production use. The combination is a real tool, not a toy. The recommendation: try it. If you live in the terminal, it will fit your workflow. If you prefer a GUI editor with inline suggestions, Cursor or Windsurf is probably a better fit. The tools are complementary. for most developers, use Claude Code for complex tasks and a GUI tool for inline suggestions. The two tools work well together. The combination is more useful than either tool alone. the call is yours. The price is similar. The features are different. The recommendation is to use both.