Most people use AI like a fast Google. Type a question, read the answer, close the tab. I did this for months before I understood that the model was the least interesting part of the tool.
Claude Code isn't primarily a code generator. It's a context holder that can execute. The distinction matters.
What changed when I stopped treating it like a chatbot
The shift happened when I started working on Formatex — a LaTeX-to-PDF API built on Go and Next.js with an MCP server. The codebase had a Go backend, a Next.js frontend, a PostgreSQL schema, a compiler orchestration layer, and an MCP server for AI integrations. Small team, moving fast.
At that scale, the bottleneck isn't writing code. It's holding the whole system in your head while making decisions across layers no single person fully owns. The cognitive surface area compounds.
Claude Code changes this because it doesn't just answer questions. It reads your files, runs your commands, holds the context of your entire working session, and can switch between roles — implementer, reviewer, debugger — as fast as you can describe the problem.
That's the thing that actually helps. Not the code generation. The context.
CLAUDE.md — the memory that survives the session
The most underused feature is also the simplest: CLAUDE.md. A file in your repo that Claude reads at the start of every session.
Mine has things like: always use TanStack Query for data fetching, never use as any, don't add attribution lines to commits, write commit messages in lowercase. A global file for cross-project preferences, a per-repo file for project-specific rules.
That sounds mundane. But the value compounds. Every conversation starts with Claude already knowing your conventions, your preferences, your non-negotiables. You stop correcting the same mistakes. You stop re-explaining context. You start where you left off.
The per-repo files are where the real value is. When your codebase has a design system with custom tokens (signal, ink, dim, canvas), naming conventions, or architectural constraints, you document them once and stop explaining them. The model operates within your system instead of guessing at it.
Skills — the protocol layer
Claude Code ships with a skill system: small protocol files that tell Claude how to approach a class of problem. Brainstorming before building. Systematic debugging before proposing fixes. Verification before claiming something is done.
I was skeptical at first. It felt like overhead. Then I ran the debugging skill on a problem I'd been staring at for an hour. It forced a structured approach — reproduce it, understand it, find the root cause, verify the fix — and caught something I'd missed because I was too close to it.
The skills that changed my workflow the most:
Brainstorming before building. Running this before implementing any feature sounds slow. It's actually faster — you catch design problems before they're in the code. The hour you spend exploring the problem space is recovered from the hours of refactoring you won't need.
Systematic debugging. Not "what could cause this" but "reproduce it, understand what's actually happening, find the root cause, verify the fix." The discipline is the point. Skipping straight to solutions is how you fix the wrong thing confidently.
Verification before completion. Before marking a task done, this skill forces the model to prove it — run the tests, check the output, confirm the evidence. Claims become evidence. This one alone has caught more incomplete work than I can count.
These aren't magic. They're workflow. The same way a checklist before a flight isn't magic.
MCPs — the plugin layer
Model Context Protocol is how you extend Claude Code's reach beyond the filesystem. I use the GitHub MCP server on every project — it means I can manage PRs, issues, and code reviews without leaving the session or switching context.
For Formatex, I built an MCP server into the product itself. Any AI agent with MCP support can compile LaTeX directly — send a source file, get a PDF back. Claude Code included. The pattern of building tools that are natively accessible to the agents you work with is something I keep returning to. It collapses the distance between what you build and how you build the next thing.
The setup I've settled on: GitHub MCP for repository operations, project-specific MCPs when the product has an API worth exposing to agents, filesystem tools for everything else. The goal is keeping Claude in the loop on operations that would otherwise require context switches.
What I actually delegate
This is where most AI productivity guides oversell the capability.
I delegate: mechanical refactoring, boilerplate scaffolding, repetitive UI work, test setup, commit messages, debugging hypotheses I want to validate faster, documentation I'd otherwise skip.
I don't delegate: architecture decisions, data model design, anything where the problem definition is still unclear.
Claude is fast at execution — but it operates on the problem you give it. If the problem is wrong, the solution will be fast and wrong. Garbage in, garbage out, at higher velocity.
The failure mode isn't bad code. It's the right code for the wrong problem, delivered quickly.
This happened during a recent session on this portfolio. I needed to fix the mobile layout of a specific project card. I described it correctly. Claude made three attempts, all on the wrong component — ProjectBentoCard.tsx — when the actual render path went through ProjectSpotlight.tsx. The code was correct. The target was wrong. I'd given it an imprecise problem and it executed precisely on the wrong thing.
Precision in the problem statement is the skill that compounds. The model handles the rest.
What it gets wrong
Regularly:
Component targeting. In a large codebase, Claude sometimes edits the file that looks responsible rather than the one that is. Your architectural knowledge is the check on this.
Over-engineering. Left without constraints, Claude tends toward completeness. You want the minimum solution to the actual problem. Explicitly asking for the simplest approach is worth doing every time.
False completion. Occasionally it claims something is done before it's verified. The verification skill exists for this. Use it.
Context erosion in long sessions. Eventually early decisions get compressed away. I've started treating long sessions as sequential — summarize the state, reset, continue. This isn't a limitation to work around. It's session hygiene, the same as committing before a major refactor.
The actual result
Most of my projects ship solo. Gesthub: a five-role auth system with Kanban, server-side data tables, and PDF generation, deployed for Morocco's Education Ministry. Hodour: 179 API endpoints serving three interfaces across a university faculty. This portfolio. Watchfolio. Subday. Built alone, from schema to deployment.
None of that required a full team. It required the right workflow.
The value isn't that Claude Code writes code for you. It's that it holds context, executes reliably, catches things you'd miss when you're moving fast, and removes the parts of the job that drain energy without producing insight. The creative work — what to build, how to structure it, what problem is actually worth solving — stays yours.
That's the deal. Not a replacement. Not magic. A second engineer who's available at 2am, doesn't need onboarding, and already knows your code.