Most advice about AI tools is guesswork from people who read the release notes.
Anthropic published an account of how its own teams use Claude Code, and it is worth reading for a reason that has nothing to do with software. Eight teams are described. Five of them are not engineering teams. The legal department built working tools. The marketing team rebuilt how it produces ads. Nobody on either team is a developer.
That is the part worth your attention, because it is the part that transfers to a business like yours.
The figures below are Anthropic’s own, from How Anthropic teams use Claude Code.
The teams that do not write software
Start here, because this is where the surprise is.
Legal built a phone tree. Not a document, an actual working prototype: a system that routes a question from whoever is asking it to the right lawyer. A legal team built custom internal software with no development resources and nobody’s engineering time.
Sit with that for a second. The constraint that stops most businesses building the small tool they obviously need is not the idea. It is that building it requires a developer, a budget and a queue. That constraint moved.
Growth Marketing rebuilt ad production. They hand it a spreadsheet with hundreds of ads in it. It works out which ones are underperforming, then writes new variations that fit the character limits each platform enforces. Two specialised helpers run that in parallel, and hundreds of ads now take minutes where they took hours.
They went further and built a Figma plugin that generates up to 100 ad variations by swapping headlines and descriptions. The copy-and-paste work that used to eat hours now takes about half a second per batch.
That is not a marketing team using a chat window. That is a marketing team that built itself a tool.
Product Design closed the gap between the design and the thing. They feed Figma files in and get working features out. They also use it to map error states and logic flows before anything is built, which improves the design itself and saves hours of debugging later. They built Vim key bindings with barely any human review.
The pattern across all three: none of them asked for code. They described a job they do repeatedly and got something that does it.
The teams that do
The engineering results matter too, mostly because of what they reveal about where the time actually goes.
Security Engineering changed how they work, not just how fast. Their old sequence was a design doc, then rough code, then a refactor, then giving up on tests. Now the tests come first, which produces code that is more reliable because it was testable from the start.
During an incident they feed in stack traces and documentation and trace the control flow. Time to find the problem went from 10-15 minutes to about 3. Three times faster, on the task where being slow costs the most.
Inference cut research time by 80%. They translate tests into languages the team does not know well, like Rust, and they use it to explain model-specific functions to colleagues who do not have a machine learning background. What took about an hour takes 10-20 minutes.
That second use is the interesting one. It is not writing code. It is explaining existing code to someone who needs to understand it and does not have the background. Every business has a version of that problem.
Data Infrastructure saved 20 minutes during an outage. A Kubernetes cluster was failing. They fed in a screenshot of the dashboard. It diagnosed the cause, pod IP address exhaustion, and gave back the exact commands to create new IP pools.
A screenshot. During an outage. That is the whole story of why this is different from a tool you have to learn.
The data scientists replaced a category of software. They point it at an entire codebase to get oriented fast, and use it to explain which pipelines depend on which. It does the job their data catalog tool used to do. One team’s workflow quietly made a product unnecessary.
Product Engineering calls it their first stop. Not for writing the code, for working out which files to look at. The context-gathering that used to come before the real work stopped being manual.
What the numbers actually say
Four hard figures, and they point the same direction:
- Security Engineering: 10-15 minutes to 3 minutes finding the cause of an incident
- Inference: about 1 hour to 10-20 minutes on research, an 80% cut
- Data Infrastructure: 20 minutes saved in a single outage
- Growth Marketing: hours to minutes on ad batches, and hours to half a second on the copy-paste step
Notice what none of these are. Not one of them is “we wrote more code.” Every single one is time spent understanding something, moving something between places, or producing another variation of something that already existed.
That is the work. In most businesses it is the majority of the week, and almost none of it is the work anybody was hired to do.
What they do differently
The teams getting these results share a handful of habits. Most of them apply whether or not anybody involved writes software.
Give it a way to check itself. Instead of asking for something and inspecting the result yourself, hand over the test as well: here is the job, here is how to tell whether it worked, run it and show me. Without that you are the quality control, and you have to sit there. With it, you can walk away and come back to something that already passed.
Plan before building. Have it read everything and produce a plan first, saying what it will change and in what order, before it changes anything. Approve the plan, then let it go. This stops the expensive failure, which is not a mistake, it is a beautiful solution to the wrong problem. Skip it for something you could describe in one sentence. Use it whenever the job touches several things or you are not sure of the approach.
Keep a memory file that corrects itself. This is the one to steal if you steal one. It reads a file of standing instructions at the start of every session: how your business works, what you sell, the words you avoid, the mistakes not to repeat. When it gets something wrong, you tell it to write the rule into that file, and it stops making that mistake permanently. Keep the file lean. A bloated one gets skimmed and ignored, so prune anything that is not earning its place.
Do not accept the first answer. The first output is a draft. Ask what it would improve. Ask it to throw the version away and build the one it would build starting fresh. Ask it to prove the thing works rather than assert it. This costs one more sentence and changes the standard of everything you get.
Hand the boring parts a loop. Recurring work can be put on a schedule rather than re-triggered by you every time. Anthropic’s engineers prototype by setting something running on its own, letting it iterate, and reviewing the roughly 80% finished result later.
Talk instead of typing. Dictating is around three times faster than typing, and the instructions come out longer and more natural because speaking is easier than writing. A prompt that takes a minute to type takes under 20 seconds to say. You end up giving it more context because giving context stopped being work.
The line worth keeping
Anthropic’s own conclusion is one sentence, and it is the opposite of how these tools get sold:
Claude Code works best when you focus on the human workflows that it can augment.
The teams getting the most out of it treat it as a thought partner rather than a code generator. They explore, prototype quickly, and pass what they learn to each other, including to the people who are not technical.
Which is why the legal team’s phone tree is the most useful thing in that whole document. Nobody there set out to become a developer. They had a workflow that annoyed them, described it, and got a tool.
Where to start
If you do not write software, two things, in this order.
Write the memory file. One document about your business: what you do, what you sell, who you serve, how you talk, what you keep having to re-explain. Everything else works better once this exists, and most people never do it, which is the actual reason they conclude the tools are overrated.
Then pick one job you do every week and hand over the whole thing rather than a piece of it. Not “help me draft this.” The whole sequence, including how to tell whether it came out right.
The teams in that document did not start with a strategy. They started with one workflow that annoyed them. The legal team is proof that the ceiling is a lot higher than “it helps me write emails,” and that you do not need permission or a developer to find out where yours is.