Claude Code: what it is, how it works and how to use it

Claude Code is a tool that turns AI from a conversation partner into a doer: it opens your project, reads files, makes edits, runs tests and looks at what broke. Instead of "tell me how to write this function" — "do it, verify it and show me the result".

Over the past eighteen months, command-line agents like this have stopped being toys: a field study by Microsoft covering tens of thousands of engineers recorded roughly a quarter more merged pull requests among those who adopted them. Below: what this tool is, how it works under the hood, five techniques that separate real work from endless re-prompting, what it costs and what the situation is with access from Russia.

What is Claude Code, in plain terms?

Short version: Claude Code is an AI agent for working with code that lives inside your project and acts on its own instead of handing out advice. You state the task in words, it carries the task out and reports back with a result.

Anthropic's own wording is this:

"Claude Code is an agentic coding tool that reads your codebase, edits files, executes commands and integrates with your development tools" — the official Claude Code documentation.

The key word here is "agentic". There is a separate breakdown of this class of programs and their varieties — AI agents for business: what they are and what kinds exist. An ordinary neural network in a browser works on a question-and-answer loop: you copy a chunk of code into the chat window, get text back, paste it into the project, run it, see an error, copy the error back into the chat. The loop closes through you, and every turn of it costs you attention.

An agent takes that loop over. It finds the right files itself, changes them itself, runs the tests itself, reads the output itself and fixes whatever failed. You step in where a decision is needed, not where copying is needed.

If this is the first you're hearing that code can be written in plain words, start with the companion piece — what vibe coding is and why business should care. Claude Code is the next step after it: the AI stops being a conversation partner for one-off prototypes and takes its place on the assembly line of a real project.

How is Claude Code different from a chatbot or editor autocomplete?

Short version: a chat answers with text, autocomplete suggests the next line, an agent completes the whole task. The difference is who holds the feedback loop.

The practical difference shows in a simple example. In a chat, "fix the failing test" turns into a ten-message exchange: show me the code, show me the error, try this, no, now something else is failing. The same request in Claude Code is a single sentence, after which it finds the test itself, reads the stack trace, fixes the cause, reruns the test suite and comes back with the result.

How does Claude Code work under the hood?

Short version: it runs a loop of read, decide, act, verify until the task is closed. The main constraint on that loop is how much context fits into the model, not how clever the model is.

Inside, it is simpler than it looks. The agent has a set of tools: read a file, edit a file, run a command in the terminal, search the project, reach out to the internet. At each step the model decides which tool to call, gets the result back into the conversation, and decides again. This continues until it judges the task done.

That is where the main limitation comes from, and the documentation states it without hedging:

"Most best practices stem from one constraint: Claude's context window fills up quickly, and as it fills, quality degrades" — the Claude Code best practices guide.

The context window is the agent's working memory: everything in the conversation, every file it has read and the output of every command it has run go into it. A single debugging session easily eats tens of thousands of tokens. When the memory fills up, the agent starts "forgetting" earlier instructions and making more mistakes. Nearly every technique in the section below is a way of spending context sparingly.

The second thing worth understanding: the agent stops when the work looks done. It has no sense of responsibility for the outcome of its own — only the signals you gave it. With no signals, the only criterion left is "seems plausible".

Where does Claude Code run: terminal, editor, desktop or browser?

Short version: Claude Code is one engine with several faces, and your project settings work across all of them at once.

• Terminal. The original and most complete form. Installed with a single command, launched by typing claude in the project folder.
• VS Code and Cursor. An extension that highlights edits right in the editor, lets you reference files with @ and preview the plan.
• JetBrains. A plugin for IntelliJ IDEA, PyCharm and WebStorm; requires the CLI to be installed.
• Desktop app. A standalone program for macOS and Windows: visual diffs of edits, several sessions side by side, scheduled tasks.
• Browser and phone. Launching tasks without a local install — handy when you want to hand over a long task and come back to it later.

An important detail: the project rules file, the settings and the connected external tools are shared across all surfaces. Set it up once in the terminal and it works in the editor and on your phone too.

Installing on macOS, Linux or WSL:

curl -fsSL https://claude.ai/install.sh | bash

Launching from the project folder:

cd your-project
claude

Why are developers so enthusiastic about Claude Code?

Short version: the measurements show a noticeable increase in shipped work, but the study authors themselves warn that "shipped more" and "did it better" are not the same thing.

The most serious measurement to date is a field study by Microsoft, submitted on 1 July 2026. The authors relied on telemetry from tens of thousands of engineers during a rollout of command-line agents, rather than on self-reporting:

"Those who adopted the tool merged approximately 24% more pull requests than they would have without it" — Emerson Murphy-Hill, Jenna Butler, Alexandra Savelieva, "Adoption and Impact of Command-Line AI Coding Agents", arXiv:2607.01418.

In the same study the authors noted two more things. The tool spread through the company along social ties: people started using it after seeing it in a colleague's hands. And retention depended not on age or seniority, but on how much code a person writes in the first place.

The gain held across all four months of observation — so it is not a novelty effect that wears off after a month. But in the same abstract the authors add a caveat that retellings usually leave out: a merged pull request is taken as a proxy for the outcome, and it is "not the same as the value it delivers".

What sits behind that for developers themselves comes down to three things. First, context switching disappears: you no longer leave the terminal for the browser and back. Second, the backlog of deferred chores finally gets done: tests for a module written long ago, clearing out linter warnings, updating dependencies. And it becomes possible to take on tasks in unfamiliar parts of the project — because "how is logging set up here" is a question you put to the agent, not to a colleague.

Where does Claude Code stumble?

Short version: nearly every second accepted pull request from the agent still needed human edits. The agent speeds up the writing, but does not remove the review.

The most useful figure for a sober assessment comes from a study that examined 567 pull requests created by Claude Code across 157 open-source projects:

"83.8% of such agent-assisted pull requests are eventually accepted and merged by project maintainers, and 54.9% of the merged ones are integrated without further changes. The remaining 45.1% require additional edits and benefit from human refinement, particularly in fixing bugs, documentation, and conformance to project conventions" — Miku Watanabe et al., "On the Use of Agentic Coding", arXiv:2509.14745.

Read that this way: eight out of ten of the agent's proposals turn out to be useful, but almost half of those accepted need a human hand — and most often precisely where the specifics of a particular project matter. The agent handles refactoring, documentation and tests very well. It is worse at guessing your team's unwritten conventions, because they are written down nowhere.

The Claude Code documentation lists five typical ways to spoil your own work, and all five are about the human. Dumping unrelated tasks into one session. Correcting the agent in circles instead of rephrasing. Bloating the rules file until the important parts drown in it. Believing a plausible result without checking it. Kicking off an open-ended "investigation" with no boundaries set.

That is exactly why the techniques below should be treated as part of the tool: without them it delivers noticeably less of what people install it for.

Technique 1: how do you make the agent check its own work?

Short version: if the agent has no way to check itself, you become the checker — and the whole time saving is eaten by your attention.

The documentation puts it bluntly: the agent stops when the work looks done, and "without a verification it can run, 'looks done' is the only signal available, and you become the verification loop".

The verification can be anything that returns pass or fail: a test suite, a build exit code, a linter, a script comparing output against a reference, a screenshot against a mockup. The difference in how you state the task looks like this:

Before: implement an email validation function

After:  write a function validateEmail. Examples: user@example.com — true,
        invalid — false, user@.com — false. After implementing it, run the
        tests and get them all passing.

The second version closes the loop without you: the agent writes, runs, reads the result, fixes and repeats. And a useful habit on top: ask not for the claim "done", but for the proof — the test output, the command itself and its result.

Technique 2: why plan before writing any code?

Short version: an agent sent straight off to write code will often solve the wrong task very neatly.

Claude Code has a planning mode: in it the agent reads files and answers questions but changes nothing. The working order is four steps: explore, plan, implement, commit. First "read how authorisation is set up here", then "draft a plan for the changes", and only once the plan satisfies you — "go ahead".

At the same time the documentation honestly warns that planning costs time, and gives a criterion for when you can skip it: "if you can describe the change you need in a single sentence, you don't need a plan". Planning pays off when you are unsure of the approach, when the change touches many files, or when you don't know that part of the code well.

For larger tasks there is a stronger technique: ask the agent to interview you. It asks questions about edge cases and trade-offs you hadn't thought about, and collects the answers into a written specification. A fresh session then executes that spec — with clean context and a ready brief.

Technique 3: what should the CLAUDE.md rules file look like?

Short version: CLAUDE.md is a file at the root of the project that the agent reads at the start of every session. The longer it is, the worse it works.

What goes in is what cannot be inferred from the code: how the build and tests are run, what conventions the team follows, what non-obvious pitfalls exist, how branches are named. What does not go in is anything the agent will work out anyway by reading the code.

The selection rule from the documentation is a question to ask of every line: "if I removed it, would the agent start making mistakes?" If not, cut it. And a warning from the same place, set with an exclamation mark: bloated rules files lead to the agent ignoring some of your instructions.

The sign that the file needs pruning is simple: the agent keeps doing the very thing the file has an explicit rule against. That means the rule has drowned in the noise.

A separate technique that works well over the long run is keeping a list of "red flags" in that file: one line per trap you've caught, with a link to a detailed write-up next to it. That way the file stays short and the knowledge isn't lost.

Technique 4: how do you economise on the agent's context?

Short version: context is the scarce resource of a session. You clear it, compress it and move it outside.

Four working instruments:

1. Clearing between tasks. Finished one thing and starting something unrelated — reset the context. Otherwise the previous task stays in memory and gets under your feet.
2. The two-correction rule. If you have corrected the agent twice on the same point, the context is littered with failed attempts. It is cheaper to start over with a formulation that accounts for everything you understood during those two attempts.
3. Subagents for reconnaissance. Exploring code reads dozens of files and eats your memory. A separate agent does that in its own context and returns a summary — what enters the main session is the conclusion, not a pile of source files.
4. Rewinding to a checkpoint. Before every edit a snapshot of the files is taken, and you can return to it. That makes it possible to try risky approaches: didn't work out, roll back. With one caveat from the documentation: snapshots capture only the agent's own edits and are not a replacement for version control.

Technique 5: skills, hooks or MCP — when to use which?

Short version: some rules are advice and some are guarantees. That difference decides where you put them.

• Skills are folders with instructions for a specific repeatable process. They load only when needed, so they don't take up context permanently. Everything in the rules file that you need only rarely moves here: a release checklist, an incident post-mortem, a publishing pipeline.
• Hooks are ordinary commands that run before or after the agent's actions. Unlike instructions in the rules file, which are advisory, a hook always fires. Formatting after every edit, blocking writes to a sensitive folder, running the linter before a commit — these are hooks.
• External connections over MCP — an open standard through which the agent reaches your issue tracker, database, design mockups or internal services. A task from a ticket gets done without retelling the ticket by hand.
• Subagents are specialised roles with their own permission sets: a separate security reviewer, a separate verifier.

For reviews it is worth remembering a caveat from the documentation: a reviewer told to look for flaws will almost always find something, even when the work was done well. Chase every finding and you end up with over-engineered code. So tell the reviewer directly: report only what breaks correctness or the stated requirements.

How much does Claude Code cost and what are its limits?

Short version: there is no separate price — it comes with a Claude subscription. It starts at $20 a month, and the price rises along with the limit.

Prices checked against the Claude pricing page on 18 August 2026.

The limit is counted not in requests but in volume of work: there are five-hour windows and a weekly ceiling, and they are consumed faster the more powerful the model you use and the larger the project. A practical rule of thumb: a few hours a day on medium-sized tasks fits within Pro; daily work on large repositories with the strongest model hits the ceiling and calls for Max. There is a second way to pay — per token through the API, with no subscription; it works out cheaper for occasional use and more expensive for daily use.

What about access to Claude Code from Russia?

Short version: officially Claude Code is unavailable in Russia — a vendor restriction, not a technical property of the product.

Russia is not on Anthropic's list of supported countries, either for Claude.ai or for the commercial API — even though the list runs to about 190 territories. You cannot sign up and pay through the normal channels from Russia. That is why searches like "claude code in Russia" and "paying for Claude Code" keep noticeable search volumes.

For a company, one practical conclusion follows, and it has nothing to do with workarounds. Even if access is solved, a question remains that no agent setting can solve: the code and data you hand to a tool like this travel to servers outside Russia. For a pet project that doesn't matter. For a system holding customers' personal data, payments or trade secrets, it becomes an architectural question: what exactly you are willing to send outside, what has to stay inside the perimeter, and how to separate the two without losing development speed. How that is handled in practice is covered separately — neural networks without leaking your data.

Who is Claude Code right for, and who needs engineered development?

Short version: as a developer's tool — almost everyone. As a replacement for a contractor — only where the cost of a mistake is negligible.

Claude Code covers three scenarios well: speeding up a team that already writes code; assembling a prototype to test an idea before investing; getting your bearings in someone else's or a long-abandoned project. In all three, a human makes the decisions and the agent saves their time.

It covers a fourth scenario badly — "build the system the business runs on instead of hiring a contractor". We looked at the fork between a quick solution and a system built around your own process in your own system or an off-the-shelf product. Not because it generates bad code: the figure of 83.8% accepted pull requests says the opposite. But because the remaining 45.1% of refinements are exactly where the difference lives between a working prototype and a system you can operate for years: edge-case handling, security, conformance to the conventions of a specific project. Only someone who reads the code can see those 45%.

At INCUBE AI we use agents like this every day, and that is exactly why we know the boundary well: where an AI agent honestly saves weeks, and where a good-looking demo turns into a rewrite from scratch a month later. If you're currently sizing this approach up for your own task — come to a consultation. We'll look at your process and tell you straight: what makes sense to build quickly in-house, and what should be done as an engineered system — under contract, with data held in Russia and with support after handover.

Sources

• Claude Code — product overview, official Anthropic documentation
• Claude Code — best practices guide
• Claude pricing plans
• Anthropic's list of supported countries
• Murphy-Hill E., Butler J., Savelieva A. "Adoption and Impact of Command-Line AI Coding Agents: A Study of Microsoft's Early 2026 Rollout of Claude Code and GitHub Copilot CLI", arXiv:2607.01418
• Watanabe M. et al. "On the Use of Agentic Coding: An Empirical Study of Pull Requests on GitHub", arXiv:2509.14745