How I Use Claude Code as a Full-Stack Developer

Most of what you can see on this site — the file converters, the SEO checker, the practice tests and this blog — was built by one developer in the gaps between client work, with Claude Code— Anthropic's agentic coding tool — as the pair programmer. This post is the honest version of how I use it: what I hand over, what I never hand over, and the setup that makes the difference.

What Claude Code actually is

Claude Code is Claude working inside your project rather than in a chat window. It reads files, searches the codebase, runs your commands — tests, linters, builds, git — and edits code, asking permission for anything with side effects. It runs in the terminal, in VS Code and JetBrains, in a desktop app, and on the web, where sessions run in a cloud sandbox against your GitHub repository.

The difference from pasting snippets into a chatbot is context. A chat answer is written against the three files you remembered to paste. Claude Code answers against the whole repository, and then checks its own work by running the build. That second part is what turns it from a suggestion engine into something that ships.

Want this built for you? Use code CLAUDE10 for 10% off your first Claude API integration project. Start a project

The single most valuable file: CLAUDE.md

Claude Code reads a CLAUDE.md at the root of the repository at the start of every session. It is a briefing document for a new teammate: the stack, the conventions, the commands, and the mistakes you are tired of correcting. Running /init generates a first draft from the codebase; the useful version is the one you edit over the following weeks.

A trimmed version of the one behind this site:

# prosohel.com

## Stack
Next.js 16 (App Router, Turbopack), React 19, TypeScript, Tailwind v4,
MongoDB via Mongoose, Auth.js v5.

## Conventions
- Registries drive routes: lib/blog/registry.ts, lib/tools/registry.ts,
  lib/quiz/registry.ts. Add an entry, never a hand-written route.
- Server Components by default. 'use client' only on the leaf that needs it.
- params / searchParams are Promises — always await them.

## Before you say "done"
- npm run lint
- npm run build

The “registries drive routes” line is doing a lot of work. Every blog post here, including this one, is a single entry in lib/blog/registry.ts; the route, sitemap entry, Open Graph image and structured data all derive from it. Once Claude knows that, a request like “add a post” produces one registry entry and one body file — not a bespoke page that quietly misses the sitemap.

The five-step loop I use for every feature

1. 1Write the brief, not the codeTwo or three sentences: what the user should be able to do, which existing pattern to follow, and what “done” means. The pattern pointer matters most — “mirror lib/tools/registry.ts” saves more back-and-forth than any amount of detail.
2. 2Ask for a plan firstPlan mode makes Claude read the relevant files and propose an approach before touching anything. This is where you catch the wrong abstraction, while it is still a paragraph instead of a 400-line diff.
3. 3Let it implement in small, reviewable stepsOne concern per step: data model, then route, then UI. Each step ends with lint and a build, which Claude runs itself, so type errors surface immediately rather than at the end.
4. 4Review the diff like a colleague's PRRead every line. Ask “why” about anything surprising — the answer is usually a good reason you would have missed, and occasionally a misunderstanding worth correcting in CLAUDE.md so it does not recur.
5. 5Ship through the normal pipelineCommit, push, open the PR. Claude Code can do all three, but the PR still goes through the same checks and the same review as anything else. The tool changes how fast code gets written, not the bar it has to clear.

Where it saves the most time

• Cross-cutting changes. Renaming a prop across forty components, migrating params to the async API, or moving from middleware.ts to proxy.ts. Tedious, mechanical, easy to get 95% right by hand — and the last 5% is what breaks production.
• Unfamiliar code.“Explain how auth flows from the login form to the session cookie” on a client codebase you inherited yesterday. It traces the real files instead of describing how auth usually works.
• The second 80%. Loading states, empty states, error boundaries, accessible labels, structured data. The work that is easy to describe and slow to type, and that separates a demo from a product.
• Debugging with evidence. Paste the stack trace and let it reproduce, read the logs and bisect. It is relentless in a way that is hard to be at 1 a.m.

What I never hand over

Product decisions, pricing logic, and anything that touches money or credentials get written or reviewed line-by-line by me. Not because Claude gets them wrong more often, but because the cost of a subtle mistake there is asymmetric and I am the one accountable to the client. The rule I work by: you can delegate the typing, not the responsibility.

Getting started in ten minutes

1. Install Claude Code from claude.com/claude-code and sign in with your Claude account.
2. Open a real project — not a toy — and run /init to draft your CLAUDE.md.
3. Start with something small you already understand, such as “add an empty state to the projects list”, so you can judge the result.
4. Every time you correct it, ask whether the correction belongs in CLAUDE.md. That file is where the compounding happens.

If you would rather call Claude from your own app than code alongside it, the companion post Build a Streaming Claude Chat in Next.js walks through the API side end to end.