What People Actually Use Claude For, and It Is Not Coding

There is a belief we run into constantly with people who are not engineers: that Claude is a developer tool, and they are visiting as a guest. It is a quiet belief, nobody says it out loud, and it stops them from putting their actual work through it. They ask it questions instead of giving it jobs.

The data says that belief is backwards. And it is Anthropic's own data, from their own users.

What do people actually use Claude for?

Mostly operations and writing, not code. In Anthropic's study of 1.2 million anonymized Claude Cowork sessions run between May 11 and May 31, 2026, business process and operations accounted for 33.4% of use and content creation and copywriting for 16.4%, while software development was 8.7%. Operations plus writing is roughly half of all measured sessions, about six times the software development share.

Here is the full breakdown from that study period.

If you have been treating this as a programmer's tool, you have been standing outside the room where most of the work is happening.

What does "business process and operations" mean in a real week?

That category name is doing a lot of hiding. It sounds like enterprise software. What it actually describes is the work sitting on your desk right now.

The Monday report someone assembles by hand from three tabs. Invoice and receipt reconciliation. Pulling a client update out of a CRM, an inbox, and a project tool so you can write four paragraphs. Triaging an inbox against a rule you keep in your head and have never written down. Turning a page of meeting notes into the follow-ups that actually have to happen, with owners attached.

The common thread is that this work is well defined, repeated, and boring, and it currently lives in one person's memory. That last part is why it never gets delegated to a human either. Explaining it feels slower than doing it, so the person who knows it keeps doing it, forever.

That is also why it is the highest-return place to start, and not the flashiest. Nobody demos invoice reconciliation on stage. But it is the work that eats a real percentage of a real week, and it is the work with a clear right answer, which makes it easy to check.

There is a second reason this category dominates, and it is worth understanding before you pick anything. Operations work has a shape that suits handing off: the inputs are known, the output format is stable, and the definition of correct does not change week to week. Creative and strategic work has none of those properties, which is why it feels more impressive to attempt and produces so much less. The 33.4% is not an accident of who happened to be using the product. It is the category where the work and the tool actually fit.

Why do most people stall in their first week?

We see the same four patterns, and none of them are about the model.

They bring a question instead of a job. A question gets you an answer, which is nice and then over. A job gets work done and can be handed over again next week. "What should I include in a client update?" is a question. "Here are the three places our client data lives, here is last month's update, write this month's" is a job.

They give no context, then judge the output. You would not hand a new hire a task with no background and then conclude they were not very sharp. The context is not overhead, it is most of the work.

They try to one-shot something they would not hand anyone on day one. If a task takes you twenty minutes to explain to a competent human, it takes about twenty minutes to explain here too. That is not a failure, that is the price, and you pay it once.

They never repeat anything. One-off use never compounds. The value shows up on the fourth run of the same job, when the setup cost is already paid and the output is just there.

These are habits, not techniques. The hour-by-hour coaching is what our learn Claude one on one sessions are for. But the habits are free and they are most of the gap.

What changed when Cowork moved to web and mobile?

As reported on July 8, 2026, Claude Cowork sessions can be started and managed from Claude on web and mobile, with long-running tasks continuing in the cloud, progress monitoring, approval requests, and the ability to pick a conversation back up on another device.

The practical shift for a solo operator is bigger than it sounds. The work no longer has to happen while you sit and watch it. That is the difference between a demo and a recurring job. A task that only runs when you are staring at your laptop is a task you have to schedule your day around. A task that runs while you are in a meeting and asks for approval when it needs one is a task you can actually hand off.

One honest caveat: that rollout was staged, in beta to Max subscribers first with Pro, Team, and Enterprise following. Check what your own plan has today rather than trusting a July article, including this one.

How should a small team pick its first job?

Three tests. If a candidate passes all three, start there.

• You already do it on a schedule. Weekly, monthly, every time a certain event happens. Recurring is what makes the setup cost worth paying.
• You can describe it out loud in two minutes. If you cannot, that is useful information. It usually means the process has undocumented judgment calls in it, and those are worth surfacing whether or not you automate anything.
• You can tell instantly whether the output is right. Not eventually, not after a client complains. Instantly.

It is worth naming what not to pick, because the wrong first job sours people on the whole thing. Do not start with the task that is most annoying, if that task is annoying precisely because it requires judgment nobody has written down. Do not start with something you only do twice a year, because you will have forgotten the setup by the second run. And do not start with the thing you cannot check, like a forecast or a strategic recommendation, because you will have no way of knowing whether it worked and you will end up trusting it for the wrong reasons.

The best first job is usually mildly embarrassing in how mundane it is. That is the sign you picked correctly.

Then do the part almost everyone skips: write down what "good" looks like before you start. Not what the task is, what a correct result looks like, specifically enough that someone else could grade it.

That description is the whole trick. It is also, not coincidentally, the same discipline as writing an eval, which is how we build every agent system in the studio. Before we ship anything for a client, we write down what correct output looks like, and we run against it. When something drifts, we know within a run instead of within a quarter. The scale is different for a five-person team than for a production system, but the move is identical: define the job, define what correct means, then hand it over.

Run it beside yourself for two or three cycles before you trust it unattended. You are not testing the model, you are testing your own description of the job. It is almost always the description that needs work.

What this means if you are not technical

The gate is not coding ability. It is the ability to describe your own work precisely, and most operators can do that far better than they think, because they have been doing the work for years.

What they usually lack is the habit of writing it down. That is a smaller gap than "learn to code," and it closes faster.

This is not really a question of which assistant you pick, either. There is a reasonable argument to have about Claude versus ChatGPT for getting things done, and we have made it. But that argument matters far less than whether you have handed over one real, recurring job. The people getting the most out of this are not the best prompters. They are the ones who stopped asking questions and gave it something that was actually on their plate.

If you want a hand picking that first job and setting it up properly, that is exactly what our 1:1 Claude training is built for. One session, your real work, not a generic course.