Claude Code: what it is and how I actually use it
June 9, 2026•8 min read
Claude Code is Anthropic's agentic coding tool. Here's what it is, how it works, and how I actually use it across real Go and Python projects.
I have shipped real software with Claude Code. Not toy scripts. A UI framework in Go, a browser-based terminal that runs a real shell, and a port of a Python astronomy library to Go that has to agree with the original to the decimal place. So when I write about Claude Code, it is not from reading the docs. It is from living with the thing.
This is the post I wish I had when I started: what Claude Code actually is, how the loop works, how I use it day to day, and where it will burn you. Because it will, at least once.
What Claude Code actually is
Claude Code is Anthropic’s agentic coding tool. It runs in your terminal (and now also in a desktop app, a web app, and inside VS Code and JetBrains), and instead of just answering questions like a chat window, it can read your files, edit them, run commands, run your tests, and read the output, all inside your actual project.
That is the part that matters. A chatbot gives you a snippet and you paste it. Claude Code works in the repo. It opens the files, makes the change, runs the build, sees the error, and fixes it. You are not the copy-paste middleman anymore. You are the reviewer.
The word “agentic” gets thrown around a lot, so here is the plain version: it can take a goal, break it into steps, and act on those steps using tools, then check its own work and keep going. It is not magic. It is a loop.
How the loop works
Under the hood the loop is simple, and understanding it is most of what makes you good at using it:
- You give it a goal.
- It looks at the relevant files (it searches, it reads, it builds a picture).
- It proposes and makes edits, or runs a command.
- It reads the result (the test output, the compiler error, the diff).
- It decides whether it is done, or loops back to step 2.
You stay in that loop with it. You approve commands, you redirect when it goes the wrong way, you tell it the real constraint it missed. The quality of the output tracks the quality of your steering more than anything else.
The other thing worth knowing early: it works against a context window, a finite amount of text it can hold at once (your instructions, the files it has read, the conversation so far). When a long session fills that up, it summarizes and keeps going, so it does not just fall off a cliff. But it means how you scope a task matters. A tight, well-described task beats “go fix the whole app.”
The CLAUDE.md file
This is the single highest-leverage thing most people miss. You can drop a CLAUDE.md file
at the root of your project, and Claude Code reads it at the start of every session. It is
project memory: the build commands, the conventions, the “we use this library, not that
one,” the things you are tired of repeating.
I treat it like onboarding notes for a new engineer who is fast, tireless, and has no memory
between sessions. The better that file is, the less I have to correct mid-task. Stack,
directory layout, commit conventions, the gotchas specific to this codebase: it all goes in
there. When I notice myself correcting the same thing twice, that is the signal to write it
down in CLAUDE.md once.
Skills: a playbook for a kind of task
CLAUDE.md is always on. It loads every session, which makes it the right place for the
handful of things that are true for the whole project. But you do not want your build commands
sitting next to a 40-line guide on “how to write a strategy (with the backtesting engine)”:
which engine to use, the conventions to follow, and worked examples to copy. Most sessions do
not need that guide, and stuffing everything into one always-on file just burns context.
That is what skills are for. A skill is a packaged set of instructions for one kind of
task, and Claude Code only pulls it in when that task actually comes up. If CLAUDE.md is the
standing house rules, a skill is a playbook you hand over the moment the matching job starts.
The mental model that helps me: CLAUDE.md answers “what is always true here,” and a skill
answers “how do I do this one thing well.” The moment you notice yourself pasting the same long
instructions into a new session, that is the signal to turn them into a skill.
How I actually use it
The pattern that works for me is validation-first. I do not ask it to build a big thing and hope. I set up a way to check the work, then let it iterate against that check.
When I ported Skyfield, a Python astronomy library, to Go, the whole project only worked because of this. An ephemeris calculation is either right or it is wrong, and “looks plausible” is worthless. So I built golden tests first: run the original Python, capture the exact numbers, then make the Go port agree to the decimal. Claude Code could then grind through the port, and the tests told both of us the truth. I was not trusting the AI. I was trusting the tests, and the AI was just very fast at making them pass.
Same story when I built godom, a UI framework in Go. Claude was the implementation partner, but I was the one who decided the architecture, caught the wrong turns, and kept the design coherent. And when I got curious enough to run Claude Code inside a browser terminal I had built in Go, the surprising part was that it just worked, because a real PTY and a real shell are exactly the environment it expects.
So the loop in practice:
- Give it a tightly scoped task, not the whole mountain.
- Make sure there is a way to verify (tests, a build, a thing I can run and look at).
- Let it work, but watch it like a hawk when it touches anything I care about.
- Correct early. A wrong assumption caught in the first step is cheap; caught five steps later it has metastasized through the diff.
This is the same philosophy I described in why, when, and how I use AI generally: the tool is fast and useful, and it is also confidently wrong sometimes, so trust is earned through verification, not vibes.
Where it burns you
It will burn you. Plan for it.
The classic failure is confident wrong. It will produce code that looks right, reads right, and is subtly broken, with the same calm tone it uses when it is correct. There is no nervous “I think this might work” in the output. This is exactly why validation-first matters: the tests do not care how confident the prose was.
It also drifts on long, vague tasks. The fix is not a better model, it is a better task: smaller scope, clearer done-condition, a check it can run.
And it will happily “fix” a failing test by weakening the test, unless you are watching. That is the hawk part. Read the diff. Especially read the diff on the parts you did not expect it to touch.
So is it worth it?
For me, clearly yes, but with the caveat that runs through all of this: it amplifies a competent operator, it does not replace one. It made the Skyfield port a weekend instead of a month, but only because I knew what “correct” meant and built the harness to enforce it. Hand the same tool to someone who cannot tell good output from plausible output, and it will help them ship bugs faster.
That is not a knock on the tool. It is the whole point. The leverage is real. The judgment is still yours.
FAQ
What is Claude Code used for?
Building and changing software inside a real codebase. It reads your files, writes and edits code, runs commands and tests, and works through multi-step tasks, all in your terminal or editor. People use it for features, refactors, bug hunts, writing tests, and exploring an unfamiliar repo.
How does Claude Code work?
It runs an agentic loop: you give it a goal, it reads the relevant files, makes edits or runs commands, reads the results, and repeats until the task is done or it needs your input. You stay in the loop to approve actions and steer it.
Is Claude Code free?
It needs access to Anthropic’s models, so it is tied to a paid Claude plan or API usage rather than being free-forever. Pricing and the included usage change over time, so check Anthropic’s current plans rather than trusting a number in a blog post.
What is the CLAUDE.md file?
A file at your project root that Claude Code reads at the start of every session. You put your build commands, conventions, and project-specific gotchas in it, so you do not have to repeat them. Think of it as onboarding notes for the tool.
What are Claude Code skills?
Packaged instructions for a specific kind of task that Claude Code loads only when that task
comes up, unlike CLAUDE.md, which loads every session. You write the playbook once (say, how
to draft a certain type of post, or run a certain review), then invoke it instead of
re-explaining the workflow each time.
How does Claude Code manage context?
It works within a finite context window. As a long session fills up, it summarizes earlier
context and continues, so work is not lost mid-task. In practice, tightly scoped tasks and a
good CLAUDE.md keep it focused and reduce wasted context.
Does Claude Code work in VS Code?
Yes. Alongside the terminal CLI, it has IDE integrations (including VS Code and JetBrains), plus desktop and web apps. The underlying loop is the same; only the surface changes.
Claude Code did not make me a better engineer. It made the engineer I already am a lot faster, and a lot more dangerous if I stop paying attention. Set up the checks, stay in the loop, read the diff. The leverage takes care of itself.