Claude Code for Non-Developers: Four Installs, One Team
Claude Code is good for non-developers when most of their work lives in documents: client notes, plans, finance trackers, weekly updates. Claude Code reads and edits files in a folder, and anyone who can describe what they want can direct it. It gets harder when you need it to stay out of the terminal completely, or when nobody on the team can review the parts that behave like software.
Our team has very different technical backgrounds, and all of us work out of one repository that I call our company brain (how that repo is laid out).
The setup is four things
On July 7 we wrote down a ruling about setup. Anyone using the brain needs “git + Claude Code + uv/Python + the shared .env,” and nothing else. Heavy work runs remotely, on GitHub Actions and Cloud Run. The last line of the ruling matters most: “Per-machine installs beyond baseline are optional power-user paths, never load-bearing.” The reason we gave was that the whole team, with “varying technical skill,” had to be able to use every part of the brain without local setup.
That ruling had a casualty. A local semantic search setup needed about 2GB of models on every laptop, and it got replaced by a managed search service. We keep rulings like this in an append-only log so the next person who wants to add a local dependency can see why we said no.
Our README hasn’t fully caught up with the ruling. Its manual setup section still lists six tools, including Node and two command-line tools for Google and Gemini. Most people never read it, though, because there’s a /setup command that runs inside Claude Code. It checks what’s missing, offers to install it, asks for the API keys your role needs, and reads the team roster to install only the dependencies for your department. Someone in sales gets asked for the payment key. Someone in finance doesn’t get nine marketing tool folders. At the end it lists the commands available to your role, built from the actual command files so the list can’t go stale. The whole setup, including what’s shared in git and what stays on each laptop, is in Claude Code team setup.
What we took off their plate
Git. Nobody on the team has to learn branching. A command called /tidy looks at everything you changed, groups it into sensible commits, puts documents and code on separate branches and opens a pull request for each. Across the whole repo, 2,978 of 3,474 commits (86%) carry a Claude co-author line. A non-developer can skip learning git and still get what git gives you: every change has a history and can be undone.
The daily Google login. Our Google Workspace token expires every day. Instead of a wiki page about OAuth, there’s one command that checks the token and, if it’s dead, runs the whole re-auth. In the words of one of our command files, “the human only clicks Allow.”
Waiting for a reviewer to approve a note. For most of the summer, every change to the repo needed a pull request and an approving review, including a one-line edit to a client’s notes. Most of what changes in the brain is prose, so notes waited in the same queue as code. Our access registry shows what people did about it in other repos: they asked for admin rights so they could merge their own pull requests without waiting on a second review.
On September 11 we split the repo into a doc lane and a code lane. A small classifier looks at every file in a pull request. A file only counts as a document if it matches none of the code patterns and has a known document extension. Anything it doesn’t recognize goes to a human. When it guesses wrong, a document waits for a person. It can’t guess wrong in the direction of code merging itself. Anything classed as code still needs an approving review from someone listed in GitHub’s CODEOWNERS file, which is how we name who must approve which paths.
Since the split, 137 of 204 merged pull requests merged themselves. The median time from opened to merged for those was 83 seconds.
What a non-developer does with it
The clearest example is our operations lead. More than a hundred commits since March, most of them co-authored with Claude. Almost all of it is documents: financial KPI plans with plain-language definitions, engagement retrospectives, invoices and receipts filed into client folders, updates to engagement letters.
The interesting part is the commands. When we deleted 52 skills and commands this spring, the weekly client update was the only project management command that survived (how it works now). Our operations lead has since edited it in five separate commits. Another set of changes reworked how we close out a client engagement, with commit messages like “require inline source tags on retrospective text fields.” That’s a process change, written in English, that the AI now follows every time anyone runs the retrospective.
Claude also wrote some Python along the way. Our operations lead’s commits touched script files 21 times, mostly small helpers for pulling data out of Notion. The line between “edits documents” and “writes software” gets blurry fast, and that’s where the hard parts are.
Do you need the terminal?
For Claude Code itself, less than you’d think. It installs on macOS, Linux and Windows, and Anthropic now publishes a guide for people who have never opened a terminal and a desktop app that skips the terminal entirely. I wrote up which recent desktop updates are worth using. Our repo is the harder part: its setup command supports macOS and Windows through WSL, because our scripts assume a Linux-style shell, and for a new Windows user getting WSL running is a small project of its own. And when something fails, the error message is written for an engineer. Claude can explain the error, which helps, but someone still has to paste it in and decide whether to trust the answer.
Where it’s still hard
Markdown can be code. Our command files are plain English. They’re also the instructions every automated run follows, and a bad edit to one can break every founder’s end-of-day run. So the classifier treats any markdown under .claude/ as code, and code needs an engineer’s approval. For our operations lead, that means a 26-file batch of invoices and receipts can merge in 61 seconds, while a one-file change to the weekly update command still needs one of us. One of those, opened just before the split, sat for 20 days.
Show the data
| Pull requests | Window | Count | Median open to merge |
|---|---|---|---|
| Docs, merged themselves | Sep 11 to Oct 16 | 137 | 83 seconds |
| Merged by a person | Aug 1 to Sep 10 | 43 | 4.9 hours |
| Merged by a person | Sep 11 to Oct 16 | 67 | 42.6 hours |
The code queue got slower. From August 1 to September 10, the median pull request took about 4.9 hours to merge. Since the split, the ones that still need a human take a median of about 42.6 hours. The doc lane took every easy approval out of our queue. What’s left is the stuff that needs real attention, and we put it off. I don’t have a fix for this yet. Two-thirds of merges now take care of themselves, the other third got visibly worse, and I’d still make that trade.
Someone has to own the rules. The setup ruling, the doc lane, /setup, /tidy and the Google login command were all built by my co-founder and me. So were most of the lines in our CLAUDE.md files. A team of non-developers can use a brain like this every day. Building the guardrails around it is a different job, and I wouldn’t hand it to someone in their first month with the tool.
When I set out to write a guide to agentic coding for non-technical leaders, “just a document” turned into a playable SkiFree and a music engine within ten days (the making-of story). Our operations lead’s 21 script changes are a smaller version of the same drift, and somebody has to decide which side of the line each change lands on.
Where to go from here
If you want to know what people actually use it for, here’s what our 66 commands do, department by department. If you’d rather never open a terminal, read Claude Code vs Cowork first, because for one person working alone Cowork may be the better start.
Trying it on your own work
If you want to find out whether this fits how you work, the fastest test is your own documents, not a tutorial project. Build It Yourself coaching is four 90-minute sessions over screen share for $1,997: bring a folder of real files, you do the typing, and you get a recap after each session so you can keep going once we hang up. If you’re not ready for that, the setup planner asks six questions about your team’s tools and gives you a free plan without asking for an email.
