A month ago, on the same day it released Claude 3.7 Sonnet, Anthropic launched a tool called Claude Code. It is labelled a research preview. There is no editor and no graphical window: you install it, type claude in a terminal inside your project folder, and start giving it instructions.
Its appearance is modest. We have been using it for a few weeks, and we consider it one of the more important releases of the year so far, despite the fact that it runs in a plain black window with a blinking cursor.
What does Claude Code actually do?
The difference from a chatbot is that it works inside your project. It can read your files, search through them, run commands, edit code, and run the tests to confirm whether an edit worked. With the default settings, it asks for permission before taking any action that changes something. You answer yes, no, or "yes, and don't ask again for this one."
As a result, there is no longer any need to copy code out of a chat window and paste it into a file. You describe the task, the tool carries it out in the actual files, and you supervise.
The closest comparison we can offer is pair programming with a very fast collaborator who has never seen your project before: excellent at the mechanics, but unaware of the reasons behind your choices unless you explain them.
At present, it is billed through Anthropic's API, based on usage. A long session on a large project becomes costly faster than one might expect, so we recommend monitoring usage closely at first. Setup instructions and current details are available in the Claude Code documentation, which is worth reading before using the tool on anything important.
How do we use it on real projects?
Much of our work involves websites, WordPress themes, small tools and custom GPTs. A significant share of it consists of code that no one enjoys writing: renaming an element across forty files, consolidating settings in one place, adding French strings alongside the English ones while keeping the keys consistent, writing a migration script. This is where a tool of this kind proves its value immediately.
Why give it a clear task and the files it needs?
Vague instructions produce vague results. "Clean up the theme" produces a series of unwanted changes. "In the header template, replace the hard-coded phone number with the value from the theme settings, and don't touch anything else" produces exactly the expected result.
It also helps considerably to indicate where to look. The tool can search on its own and does so reasonably well, but in a disorganized project it sometimes selects the wrong file because of a similar name. Directing it to the right file saves time for everyone involved.
Why write the rules down once?
Claude Code reads a file called CLAUDE.md at the root of the project, if one exists, and it can draft a first version for you. This is where you record the instructions you would otherwise repeat at every session: which folder contains the live theme and which contains the old one; that the text must be in French and English; how to run the tests; that the vendor folder must not be modified.
This small measure makes a real difference. It is essentially the onboarding note you would give a new contractor, which is exactly the role the tool fills.
Which guardrails do we apply?
This is the section we would most like small business owners to read, including those who will never open a terminal.
Version control, always. Every project goes into git before the agent touches it. Commit before a session and commit after. If something goes wrong, you return to the previous step and nothing is lost. Without this, you are entrusting your only copy to a very fast stranger, which we do not recommend.
Review every change. The tool shows you the diff, the before and after. Read it carefully. Most of the time the change is correct. Occasionally, it is correct for the requested task but also quietly "fixes" something nearby that was not broken. Those are the changes that cause problems a week later.
Keep it away from production. The agent works on a copy. You test the copy. Then you deploy. This is the same rule that applies to a junior developer, for the same reasons.
Keep secrets out of reach. Passwords, API keys and exports of customer data should not be stored in the project folder in the first place. With an agent that reads everything, good organization becomes even more important.
Avoid selecting "always allow" for everything. The temptation is understandable after the tenth permission prompt. Allow harmless actions, such as running tests or listing files, and continue approving manually anything that deletes, pushes or installs.
We also apply one broader rule: if we do not understand what the tool did, we do not keep the change, even if the tests pass. We are the ones who will have to repair it at eleven at night on a Sunday.
Why does a terminal agent matter?
In our view, the terminal itself is not the essential point. Anthropic started there because that is where developers already work, and we expect the tool to extend beyond the terminal before long.
What matters is the underlying approach. The AI no longer suggests code for you to paste; it does the work in the actual project, step by step, and consults you along the way. We expect every serious coding tool to move in this direction this year, and some already have.
As a small business, you will probably never run it yourself, and you do not need to. However, if someone builds or maintains your website, it is entirely reasonable to ask how they use tools of this kind and what they verify before anything goes live. A good answer mentions backups, review and testing. An excellent answer sounds methodical and unremarkable.
The same type of tool can also handle repetitive tasks on the business side: reports, exports and copying data between systems. If that is where much of your week goes, automating some of that busywork is now a realistic project, and a less expensive one than it was a year ago.