Most write-ups about AI coding tools stop at the demo: a prompt goes in, a component comes out, everybody claps. That is the least interesting thing these tools do. The interesting part is what happens on day forty, in a real repository, with a real test suite and a design system that already has opinions.
Claude Code is Anthropic's agentic coding tool. It runs in the terminal, in a desktop app, on the web at claude.ai/code, and inside VS Code and JetBrains. The distinction that matters is not "it writes code" but that it reads your repository, runs your commands, and checks its own work before handing anything back.
This is what I have found actually matters when you use it on production frontend work.
The mental model: an agent with a filesystem, not a chat box
A chat assistant answers from what you paste into it. An agent goes and looks. That difference changes how you prompt.
With a chat assistant, you write a long prompt because context is scarce. With Claude Code, a long prompt is often worse than a short one plus a pointer, because it can read the file itself and get the current version rather than the version you copied ten minutes ago.
# Weaker: you become the bottleneck
Here is my Button component [200 lines pasted]. Add a loading state...
# Stronger: point at the thing
Add a loading state to src/components/ui/Button.tsx.
Match how Badge.tsx handles variants.
The second version is shorter and better grounded. It also stays correct if the file changes.
Plan mode: the highest-leverage habit
Plan mode makes the session read-only. Claude explores, then presents a plan and waits for you to approve it before touching anything.
This is the single habit I would push hardest on anyone starting out. Not because the agent is reckless, but because a plan is reviewable in thirty seconds and a diff across nine files is not. Catching "you're going to migrate the router" at the plan stage costs one sentence. Catching it after the fact costs an afternoon.
Use plan mode when:
- The task touches more than two or three files
- You are not certain the task is well-specified
- The change is architectural, or hard to reverse
- You want an estimate before committing to the work
Skip it for a typo fix.
Permission modes decide how much rope
Claude Code asks before it does anything consequential. How often it asks is configurable, and the right setting depends on the blast radius of the work:
| Situation | Sensible posture |
|---|---|
| Exploring an unfamiliar repo | Plan mode, read-only |
| Ordinary feature work | Default, approve edits as they come |
| A long mechanical refactor you have already scoped | Accept-edits, review the final diff |
| Anything touching deploys, secrets, or prod data | Approve every step, no exceptions |
The failure mode is not the agent going rogue. It is you approving twenty prompts in a row without reading them, which is a human problem that tooling cannot fix. Match the mode to how much attention you actually intend to pay.
CLAUDE.md is a project's onboarding doc
CLAUDE.md is a file at the root of your repo that gets loaded into context at the start of every session. Think of it as the README you wish new hires actually read.
What belongs in it: facts that are true across the whole project and that are not obvious from the code.
# Project
Next.js 15, Pages Router. Do not migrate to App Router.
Tailwind v4, config-free. Tokens live in `src/styles/globals.css`.
## Conventions
- All user-facing strings go through `src/i18n/`. Six locales, update all.
- Never add an animation library. Use framer-motion or GSAP, both installed.
- Run `yarn typecheck && yarn lint` before saying a task is done.
What does not belong: anything the agent can read from the code, a changelog, or a long procedure. Long procedures should be skills instead, because a skill's body only loads when it is used, whereas everything in CLAUDE.md costs context on every single turn.
That last point is the one people miss. A bloated CLAUDE.md is not free. It is a tax on every request you make for the rest of the project's life.
Verification is the whole ballgame
The difference between a tool that saves you time and a tool that costs you time is whether the output is checked before it reaches you.
Give the agent a way to prove its work:
## Verification
- `yarn typecheck` must pass
- `yarn lint` must pass
- `yarn build` must succeed
- For UI changes, check the rendered result in the browser, not just the source
The last line matters more than it looks. An agent that reads its own diff and declares victory is grading its own homework. An agent that loads the page and measures the element has actually checked something.
I hit a version of this while building the stacked project scroller on this site. The implementation was correct, but every browser check reported it broken. The cause turned out to be that the preview pane ran as a hidden tab, and browsers do not fire requestAnimationFrame in hidden tabs, so the code being verified never ran. Three rounds of "fixing" working code. The lesson was not about the framework. It was that a verification loop you do not understand is worse than no verification loop, because it produces confident wrong answers.
What it is genuinely good at
Being specific here is more useful than being enthusiastic.
Tracing a bug through unfamiliar code. This is the strongest use case by a distance. "Find why the theme flashes on first paint" against a repo you have never opened is a task where reading fifty files quickly is the entire job.
Mechanical refactors with a clear rule. Renaming a token across a design system. Migrating a deprecated API call. Adding a prop to every call site. Work that is tedious rather than hard.
The first draft of tests. Not the final tests. The first draft, which is usually the part that stops people from writing tests at all.
Explaining code you inherited. Cheaper than interrupting whoever wrote it, and available at 11pm.
What it is bad at, and what to do about it
Taste. It will produce a defensible design and a defensible API. Defensible is not the same as good. Product judgment stays yours.
Knowing what you did not say. If you do not mention the design system, you get something that does not use it. The agent optimizes for the request as stated. Constraints must be stated.
Long, vaguely-specified work. "Improve the site" produces motion without progress. "Make the blog list denser: two-column on desktop, cap the hero at 400px" produces a diff you can evaluate.
Being sure it is right. It will report success confidently. Confidence is not evidence. This is exactly why the verification section above is not optional.
A workflow that holds up
- Start in plan mode for anything non-trivial. Read the plan. Push back on it.
- Point at files rather than pasting them.
- State constraints up front. Which patterns to follow, what not to touch, what "done" means.
- Let it verify. Typecheck, lint, build, and where relevant, actually look at the rendered output.
- Read the diff. Every time. This is the part that is tempting to skip and the part that is load-bearing.
- Fold recurring corrections into
CLAUDE.mdor a skill. If you have said the same thing three times, that is a config problem, not a prompting problem.
The honest summary
Claude Code is not a replacement for knowing what you are doing. It is closest to a fast, tireless colleague who has read the entire codebase, has no ego about being corrected, and will happily do the boring parts. It still needs someone to decide what is worth building and whether the result is good.
The engineers I have seen get the most out of it are not the ones with the cleverest prompts. They are the ones who set up the guardrails once, verify properly, and read the diff.
Related reading: Skills, MCP, models and effort levels, and subagents and hooks.
- #Claude Code
- #AI
- #Developer Tools
- #Agentic Coding
- #Workflow