How we build AI Workspace Builder with Claude Code

AI Workspace Builder has no engineering team. It has a Claude Code workspace. Its repository has more than 100 commits since the first one in April 2026, and all but 3 are co-authored by Claude Code: the web app, the sign-in and billing, the generator, the command-line installer and this blog.

That doesn't mean the agent runs the company. It means the decisions, the rules and the review process are written down where the agent reads them. This post shows how that's set up, using our own repository as the example.

Three instruction files, one per area

The repository has three CLAUDE.md files, 325 lines in total:

• The root file (115 lines) says what the product is, how the repository is laid out, the tech stack, how to build it, and the business context.
• The web app's file covers the Next.js app: its stack, directory structure, authentication model, API routes and key conventions.
• The installer's file covers the command-line tool.

Claude Code loads the root file in every session and each folder's file when it works in that folder, so a change to the web app doesn't carry the installer's rules around with it.

The business context is the part most teams leave out, and it changes the agent's decisions more than any coding rule. Our root file lists the gates the product has to pass and the top risks to keep in mind. One of them reads: "never tie architecture solely to CLAUDE.md format; core value is doc reading + structured extraction." An agent that has read that line doesn't hard-code one output format into the generator, even when that would be quicker.

Every change goes through a council

The root file has a section called "Mandatory council review". It says every change, whether a feature, bug fix, refactor or deployment script, goes to role profiles for review before it is implemented:

1. State the change and why.
2. Pick the relevant profiles for that kind of change.
3. Run each profile and record its concerns in its own words.
4. When profiles disagree, name the trade-off.
5. A CTO profile reviews everything and approves, modifies or blocks.
6. Implement only after approval.

Which profiles review depends on the change. A web page gets the frontend engineer and the product designer. Anything touching credentials gets the security analyst and the architect. A pricing change gets the revenue and finance profiles. Every completed build gets QA and a penetration tester. Critical findings block deployment.

Each profile is a folder with a description of the role, a prompt to run it as an agent, and a review checklist. They stay project-neutral; the change being reviewed is filled in each time. This is the same idea we sell: a profile for each role, installed into the workspace.

Nothing is done until it's verified live

The rule that matters most isn't about code. It's that the agent never reports something as done until it has checked the result where users see it.

This week is a good example. Our analytics showed that blog readers were arriving but almost none reached the product: in one week, about 20 visitors read a post, one opened the builder, and nobody clicked the call to action. Every route into the product ended at a sign-up page before the visitor had seen any output.

The change: let visitors fill in the questionnaire and download their CLAUDE.md without an account, with an optional "sign up to save" step afterward. The agent built it and deployed it. Then it opened the live site in a signed-out browser at phone width and walked the whole path: from a blog post, through the questionnaire, to a downloaded file named CLAUDE.md, to the sign-up link, checking that the answers were kept for later. Only then was it reported as done, along with the one part it couldn't test without a real new account.

That last line is the habit we care about most: saying exactly what was verified and what wasn't.

Corrections become rules

When the agent gets something wrong and is corrected, the correction is written down. If the same correction comes up twice, it becomes a standing rule in an instruction file, with a short note on why it exists. Most of the rules in our files started that way: build one change at a time instead of running agents in parallel, never guess a fact that can be checked, measure a fix before calling it fixed.

The rules keep the agent from repeating a mistake. The notes on why keep a future reader from deleting a rule that looks unnecessary.

What a person still does

• Decides what to build. The agent proposes; a person picks what matters to customers.
• Approves anything that can't be undone. Releases, pricing, anything a customer will see.
• Reads the results. The analytics, the review findings, the live site.

The agent supplies the speed. The written workspace carries a person's judgment into every session.

Try it on your own team

The slow part of this was never the agent. It was writing the workspace: the instruction files, the business context, the role profiles. Most teams already have that knowledge in READMEs, onboarding guides and wiki pages.

AI Workspace Builder turns it into a workspace. Upload the docs your team already has, and it generates the CLAUDE.md, a profile for each role, and an install script in 15 to 30 seconds, using your own Anthropic API key. No docs yet? Answer a short questionnaire and download a starter CLAUDE.md, no signup needed.