Claude Code is an agentic coding tool, and most of what is written about it concerns software teams. But a large share of business automation is scripting with judgement attached — read this, decide that, write it somewhere — which is squarely what it does well. This is a practical view of where it helps, and where reaching for it is a mistake.
What it is genuinely good at
The strength is work that is mechanical but not quite scriptable — where the steps are clear yet the inputs vary enough that a rigid script keeps breaking.
- One-off data work: reconciling exports, cleaning a messy CSV, reshaping a file for import.
- Glue code against APIs you do not use often enough to have learned properly.
- Reading unstructured input — invoices, transcripts, form responses — into structured fields.
- Building the first version of an automation you will later hand to a platform like Make or n8n.
Where it does not fit
It is a development tool, not a production runtime. Automation that has to run unattended every day belongs on infrastructure built for that — with retries, alerting, and a log somebody actually reads.
The failure mode we see most is a working script on somebody's laptop being treated as a deployed system. It runs until that person is on holiday, and then it does not.
If you would rather have this built for you than build it yourself, an AI consultation is where we scope that.
Starting without breaking anything
The risk is not that the code is wrong. It is that a capable tool pointed at live systems does exactly what it was asked to do, quickly, to real data.
- Work against a copy or a sandbox until the behaviour is understood.
- Use read-only credentials for the exploratory phase; grant write access only once the shape of the job is settled.
- Keep it in version control from the first commit — you will want to see what changed.
- Have it write the plan before writing the code, so you can catch a wrong assumption cheaply.
Knowing when to hand it off
A prototype earns promotion once it runs on a schedule, other people depend on it, or it touches money or customers. At that point it needs the boring infrastructure: monitoring, error handling, defined ownership.
That is the same threshold we apply to everything we build. A workflow that fails silently and is not noticed for three weeks is worse than no workflow at all, because people quietly stop trusting the system and go back to doing it by hand.
If you have not used Claude Code before, start with the beginner's guide — it covers setup, a first task, and the mistakes worth skipping.
Key takeaways
- Best on work that is mechanical but too variable for a rigid script.
- It is a development tool, not a production runtime — do not leave unattended jobs on a laptop.
- Read-only credentials and a sandbox first; write access once the job is understood.
- Promote to real infrastructure once it runs on a schedule or touches money or customers.