Skip to content
All posts
2 min read

How I Use Claude Code for Front-End Work

My actual workflow with an agent that lives in the terminal and touches the repo.

  • #ai
  • #claude-code
  • #workflow

Autocomplete in the editor is useful, but it is not how I get the most out of AI any more. These days a lot of my work runs through Claude Code, which is an agent that lives in the terminal. It reads the repo, edits files, runs commands, and reports back. Because it works inside the project it has real context, not just the few lines around my cursor. Here is how I actually use it.

The loop

The rhythm is simple. I describe a task, it makes the change, it runs the build and the linter itself, and then I review the diff. If something is off I say so and it iterates. I am not copying code out of a chat window and pasting it back in. The work happens in the repo, and I stay in the loop as the reviewer.

CLAUDE.md carries the rules

The single highest-leverage thing I did was write down my conventions in a file it reads on every run.

# Conventions
- Next.js 16 App Router, Server Components by default
- Tailwind v4, tokens in globals.css, no inline hex
- Every interactive element must be keyboard accessible
- Run `npm run build` and `npm run lint` before finishing a task

Now I stop repeating myself, and the output starts from my defaults instead of a generic guess.

Where it earns its keep

It is at its best on work that is mechanical but spread across many files. Migrations, refactors, wiring, boilerplate. I used it to move this blog off a hosted CMS and into MDX, which meant converting a pile of structured content and fixing the files that broke along the way. That is exactly the sort of careful, repetitive job I would put off for weeks. It did it in an afternoon, and I reviewed every step.

Where I keep the wheel

Architecture, anything user-facing and subtle, and accessibility stay with me. The model is fast and tireless, but it does not have taste and it does not know my users. So I review every diff, and I do not let it commit or push on its own. It proposes, I decide.

Guardrails

A few habits keep it safe. Scope tasks small so the diffs are readable. Lean on the build and the tests as a net, so a bad change fails loudly instead of sneaking through. And read the change before it lands, every time, the same way I would review a colleague.

Used like that, Claude Code is the biggest shift in how I work in years. Not because it thinks for me, but because it clears the tedious middle of the job and leaves me the parts that actually need a person.