Yes. I have trained marketers, PMO coordinators, testers, designers and admin staff to use Claude Code on their own work, alongside developers in the same cohort. Claude does the typing. Your job is to say clearly what you want, check what comes back, and decide whether it is good enough to use. If you manage people or run a business, you already brief people, check their work and decide what is good enough every day.
There is one adjustment to make. Claude Code runs in a terminal window, which will feel odd for about a session and a half. After that, Claude Code is a text box that can read and write the files you point it at.
The more useful question is what a non-developer would actually use it for, and where people get stuck. Both answers come from real participants.
What non-developers brought to the training
Before the masterclass, I ask everyone for one real task they want Claude Code to help with, plus the context they would give it. In one client's mixed cohort, the non-developers wrote these:
- A marketer wanted a monthly marketing performance report for non-technical leadership, turning data into insights about return on investment.
- A PMO coordinator wanted project health checks: risks raised, conversations flagged, and outstanding tasks from emails nobody had answered, with each task tracked in an Excel file.
- A QA lead wanted help designing test cases, covering positive, negative, boundary, security and accessibility scenarios, each traced back to a requirement.
- Someone handling admin wanted a messy folder of files checked, sorted and kept in order.
None of those four tasks involves writing software. All four are repeated, structured work that eats hours every month.
Their briefs were already good
What struck me was the quality of the instructions these participants wrote, before any training on how to do it.
The marketer listed the limits Claude had to work within. The data lives on several platforms and not all of them are connected yet, so Claude should only work with the files they hand over. Where data for a platform is missing, the report has to say so and leave the gap visible. The finished report had to be visual, under two pages, in simple language, with real numbers next to every claim and three recommended actions for next month. Their test for done was that they could read it once and send it to leadership without rewriting it.
The QA lead told Claude not to invent requirements, and to list assumptions and questions wherever information was missing.
The admin brief was the shortest and possibly the most important: don't delete anything, and skip sensitive files.
Each of them wrote down what done looks like and what Claude must never do. Writing down those two things is the core skill of working with an AI agent, and people who manage work, check work or answer to leadership have usually been practising it for years. Their knowledge of the job is the context Claude needs.
The real hurdle: the gap between setup and daily use
Writing a good brief is one thing. Making the tool part of a normal week is another. A marketer in one cohort described the problem better than I could:
"What's still unclear is the gap between setup and daily use. The tool is installed, but as a non technical person I don't yet see how it fits into my working day. When would I use it instead of regular Claude, what does a normal task look like from start to finish, and how much context management do I need to think about versus what happens automatically? I understand the concepts individually, just not how they come together into a daily routine."
The gap between setup and daily use is where non-developers most often stall. Installation works. The concepts make sense one at a time. What's missing is a routine. So here are short answers to the marketer's three questions.
When to use it instead of regular Claude. Reach for Claude Code when the task involves your files, when you will do it again next month, or when you want it to follow your rules every time. A one-off question still belongs in the chat window.
How much context management. Some things Claude should always know, such as your house rules, your audience and what it must never do. Write those things down once, in a file Claude reads at the start of every session. Everything else you hand Claude per task. Long, wandering conversations get worse over time, so start fresh for each job.
What a normal task looks like. The next section walks through one normal task from start to finish.
What a normal task looks like, start to finish
In the AI Bootcamp for Business Leaders, every session repeats the same loop, applied to bigger jobs each time:
- Say what you actually want.
- Give Claude what it needs to know.
- Agree the plan before building anything.
- Build the smallest working version.
- Check the result before you trust it.
- When the result is wrong, find out why from evidence.
- When the result is right and you'll do the job again, make the job reusable.
- Decide what may run without you.
Take the monthly marketing report. You describe the report and the reader. You hand over the exports for the platforms you have data for. You ask Claude to show you the outline and the charts it plans before it writes anything. Claude produces one month's report. You check every number against the source. Where a figure is off, you ask Claude to show which file that figure came from. Once a month's report comes out right, you turn the steps into something reusable. Later, you decide whether any part of it may run on a schedule.
Step five, checking the result, matters most. I wrote a separate piece on how to check AI output, because "it looks right" and "I checked it" are very different claims.
Make it repeatable
Step seven, making the job reusable, is where you get the hours back. A skill is a written-down way of doing a job that Claude follows the same way every time. One participant from the product and business team, who arrived saying they couldn't yet trust the output without a lot of review, wrote this at the end:
"I have been able to build skills that I can use for repetitive tasks and I have been able to refine my instructions to Claude and it has got better at doing what I ask."
I explain how to build a skill in turn repeated work into a skill.
What Claude Code will and won't do for you
Claude Code helps with the parts of your job that follow a pattern. Claude Code doesn't replace your judgement or your craft. A designer in one of my cohorts put it plainly:
"I now use claude much more as a tool to aid in tasks that would take longer. As a designer Claude cant design for me but it can help aid in layout and copy ideas."
That designer's view is realistic, and I would rather you started with it than with a promise of ten times the output.
Anthropic's own non-engineering teams use Claude Code in a similar way. In its write-up on how its teams use Claude Code, Anthropic says its Legal team "created prototype 'phone tree' systems to help team members connect with the right lawyer at Anthropic" (How Anthropic teams use Claude Code).
Claude Code or Claude Cowork?
Both come from Anthropic and both are included in a paid Claude plan. Cowork works through tasks in the folders and tools you choose, from the desktop app, the web or your phone. Claude Code gives you more control: you teach it your rules once, build small tools of your own, and decide what may run without you. I teach Claude Code because it is where you teach the assistant your own rules, and what you learn carries over to Cowork.
Learn it on your own work
If you lead an organisation or a department and want to use Claude Code yourself, on your own reports, memos and repeated jobs, that is what the AI Bootcamp is for. The AI Bootcamp runs over eight evenings in a cohort of twelve, needs no coding, and ends with two build clinics where I sit with you while you finish the thing you came to build.