Stop Treating Claude Code Like a Chat Window

By RJ Militante · April 2026

The prompting fundamentals — role, context, command, format — apply everywhere. Claude.ai, ChatGPT, Gemini, all of it. What follows is specific to Claude Code, which changes the stakes considerably.

The simplest way to explain Claude Code is this: Claude.ai and Claude Code use the same model. The difference is that Claude Code has a body.

When you use Claude.ai, the model generates text. You read it, keep what you want, discard the rest. The cost of a bad output is a few seconds of reading. When you use Claude Code, the model reads your files, writes code, executes terminal commands, and makes sequential decisions across your codebase — all on your behalf. The cost of a bad output is a diff you have to hunt down and undo.

The principles from structured prompting still apply. The consequences of ignoring them are just steeper.

Where to run Claude Code

Claude Code lives in the terminal. You can also access it through the desktop app or directly in Claude.ai, but the terminal version is the most capable — it can read your files, run commands, and interact with your actual project.

If you're new to the terminal, VS Code is a good starting point. It gives you a file explorer alongside the terminal so you can see what Claude Code is doing to your project in real time. Open VS Code, go to File → Open Folder, pick a project folder, then Terminal → New Terminal. Type claude and you're in.

Once you're comfortable with that, most experienced users eventually move to the raw terminal. Either works. The underlying capability is the same.

Permissions

When you open Claude Code, it starts in default mode: it will ask before editing files and ask before running any shell commands. That's the safe starting point.

Pressing Shift+Tab cycles through permission modes:

• Default — asks before edits, asks before shell commands
• Accept edits on — edits files automatically, still asks before shell commands
• Plan mode — no code written until you explicitly say to proceed (more on this below)

There's a fourth mode you have to opt into explicitly by launching with claude --dangerously-skip-permissions. That enables bypass permissions, where Claude Code can edit files, install packages, and run commands without asking for approval on each one. Most regular users eventually work here because the constant confirmation prompts slow things down significantly, and in practice Claude Code isn't going to delete your project without being told to. But if you're just starting out, stay on accept edits until you have a feel for how it operates.

The context window and context rot

Claude Code's context window is the budget for a session — everything you say, everything it says back, every file it reads, every line of code it generates, all of it counts against the limit. For Claude Code that limit is one million tokens. You can check where you stand at any time with /context.

The more important concept isn't the hard limit — it's what happens well before you hit it. As a session grows, Claude Code gets progressively less effective. The longer the conversation, the more noise is competing with your actual instructions. This is context rot, and it starts degrading output quality long before you run out of tokens.

The practical rule: reset your context often. Do it with /clear. A fresh session in Claude Code is nothing like starting a new chat in Claude.ai, because Claude Code isn't relying on the conversation to know what's going on — it can just look at your codebase. All your files are still there. The CLAUDE.md is still there. The context of the code itself doesn't disappear when you clear the chat.

A rough threshold to work by: once you're past 15–20% of the context window, ask yourself whether you really need to stay in this session. If there's something you want to carry forward, ask Claude Code to write a brief summary of where things stand, copy it, and paste it into the new session. That's usually faster than working with a degraded context.

For ongoing visibility, set up a status line. Run /status-line and ask it to show your current folder, model, and context window percentage. It will appear at the bottom of your terminal and you won't have to run /context manually. You can also use /rewind to step back through previous sessions if you need to recover something from before a /clear.

CLAUDE.md — your standing prompt

Claude Code reads a CLAUDE.md file at your workspace root at the start of every session. This is the highest-leverage thing you can set up. It's a persistent INSTRUCTIONS + CONTEXT block that loads automatically before you say anything.

A good CLAUDE.md covers what projects exist in the workspace, what the tech stack is, key conventions, and the things Claude should never do without being asked.

# Workspace

## Projects
- `sofi-backend` — Spring Boot REST API, Java 21
- `sofi-ai-ui` — React frontend
- `agnx-systems` — business site and blog

## Standards
- Java: Google Style Guide with AGNX overrides (see coding.md)
- Commits: one logical change per commit, explain the why not the what
- No dead code — delete it, don't comment it out

## Hard rules
- Never modify files outside the scope of the current request
- Never skip tests without being told to
- Never add docstrings or comments to code you didn't change

Write it once, stop re-explaining your workspace every session. When you start a new project and ask Claude Code to scaffold it, it will often generate a CLAUDE.md for you. Review what it wrote and edit it to match what you actually care about — the auto-generated version is usually a starting point, not a finished document.

Less is more here. Every line in CLAUDE.md should be something that applies to essentially every prompt. If it only applies to a specific task, put it in that task's prompt instead.

Plan mode — before any code is written

For anything non-trivial, ask for a plan before code gets written. This is one of the highest-leverage habits to build early.

You can do this explicitly in any prompt:

Before writing any code, describe the changes you'd make to implement
JWT authentication in this Spring Boot app. List the files you'd touch
and what you'd change in each. I'll tell you to proceed once I've reviewed it.

Or you can use plan mode (Shift+Tab to cycle to it), which puts Claude Code into a state where it will think through the approach and ask clarifying questions before doing anything. In plan mode, when it presents a plan, you'll see options to approve it, approve with bypass permissions, or send it back for refinement with "ultra plan" — which runs a more thorough planning pass before proceeding.

The reason to do this isn't just caution. It's that Claude Code will often surface questions you hadn't considered — which files it needs to touch, which approach it was going to take, assumptions it was making about your stack. The planning exchange forces those assumptions into the open before they're baked into a diff.

This costs thirty seconds and prevents an hour of cleanup. For a multi-file change, a migration, or a new feature, always ask for the plan first.

Scope your requests precisely

Vague requests in Claude Code are expensive. "Clean up this service" can mean ten different things — Claude will pick one, make sweeping changes, and you'll spend twenty minutes reviewing a diff you didn't ask for.

# Vague
Refactor the UserService class.

# Precise
In UserService.java, extract the email validation logic in the
createUser() method into a private validateEmail() method.
Don't change anything else in the file.

The phrase "don't change anything else" is underused. Claude Code will stay in bounds if you tell it where the bounds are. Same with "don't modify files outside of X." Claude Code takes you literally — that's a feature when your prompt is precise, a liability when it isn't.

Reference specific files and line numbers

Claude Code performs better when you anchor it to specifics rather than leaving it to navigate the codebase on its own. Describing an area generally ("the payment service") leaves room for the wrong interpretation. Naming the file and line removes it.

# Loose
Add error handling to the payment service.

# Anchored
In PaymentService.java, the processPayment() method at line 84
has no error handling for failed Stripe API calls. Add a try/catch
that catches StripeException and throws a PaymentProcessingException
with the original message. Don't change the method signature.

The more precisely you define the target, the less Claude Code has to infer about where to look and what to touch.

Few-shot prompting

When you want Claude Code to match a specific aesthetic or pattern — most often in frontend work — don't just describe what you want. Give it examples.

For UI work this means screenshots and source. Open browser dev tools on a design you're trying to match, copy the HTML, drag and drop the screenshots into the Claude Code prompt, and paste the markup alongside them. Two thousand lines of HTML plus three screenshots gives Claude Code something concrete to match against. A description of "more of an Anthropic feel" does not.

This isn't unique to frontend. The same principle applies anywhere you have examples of what you're aiming for. The more concrete the reference material, the less Claude Code has to guess about the target.

Adversarial code review

Claude Code has a blind spot: it thinks its own output is good. Ask it to review what it just built and it will usually find minor issues and declare the rest correct. This is a known characteristic of the underlying models — they evaluate their own output charitably.

There are two ways around it. The first is to open a second terminal, start a fresh Claude Code session with no history, and have it review the codebase with explicit adversarial framing — tell it to look for problems, not confirm correctness.

The second is to use a different model entirely. The Codex plugin for Claude Code (from OpenAI) installs just like a skill and provides a /codex review command. Having a different model review the work removes the in-session confirmation bias entirely. For complex projects or anything you're shipping to production, an adversarial review from a second session or a different model is worth the extra step.

Skills

Skills are text prompts packaged as slash commands. When you install the frontend design skill and invoke it with /frontend-design, you're not running code — you're loading a curated prompt that guides Claude Code to approach frontend work with specific constraints and heuristics. The official Claude Code GitHub has a set of maintained skills, and there's a plugin marketplace accessible with /plugin.

The most useful thing to know about skills at the start: they exist, Claude Code can install them for you if you give it the URL or the name, and any repeated workflow you find yourself doing is a candidate for becoming a skill. When you notice yourself writing the same framing for a prompt type over and over, that's the signal to turn it into a skill.

The short version

• Open Claude Code in VS Code's terminal to start — the raw terminal later
• Understand the permission levels and where you'll eventually land
• Watch your context window; reset it often with /clear
• Write a CLAUDE.md at your workspace root — it's your persistent context
• For any non-trivial change, ask for a plan before asking for code
• Scope every request to the smallest change that accomplishes the goal
• Use "don't change anything else" liberally
• Reference specific files and line numbers rather than describing areas generally
• Provide examples when you want specific output — screenshots, source, not just descriptions
• Get a second opinion on complex work; in-session review is optimistic by default

Claude Code takes you literally — in an agentic context that matters more than anywhere else, because it's not writing words, it's writing your codebase.

New to prompting AI in general? Start with the previous post: AI Prompting: The Fundamentals — the four-part structure and pull prompting techniques that apply across every tool.