How an AI Founder Actually Uses Claude Code

I started using Claude Code under pressure. I was three weeks behind on a deployment, my lead engineer was on leave, and a data pipeline needed refactoring before a client demo. I opened Claude Code, described the problem, and it read the codebase and produced a working solution in forty minutes.

Since then it has become part of most of my working days, often at 2am. This is how I use it, what it gets wrong, and the rules I give my engineers.

Morning status checks across several codebases

I run StarApple AI and four AI labs, so I deal with several repositories, teams and deployment pipelines. My mornings used to start with a queue of Slack questions from engineers. Now I open a terminal, point Claude Code at the repo that needs attention and ask three questions: what changed since yesterday, which tests are failing, and what state the module I care about is in. It reads the code and answers plainly. That saves me about an hour most days.

I also use it to read my own old code. I wrote parts of our early systems years ago with sparse comments and naming I would not defend now. Claude Code explains what those functions do, which is faster than reconstructing my reasoning from memory.

A three-day prototype at Maestro AI Labs

At Maestro AI Labs we incubate pre-seed AI companies, where proving the concept matters more than polish. Last month we built a proof of concept for an agricultural monitoring tool in three days: a Flask API, a trained classifier, a basic front end and deployment scripts.

I described the architecture and the data schema, and Claude Code wrote most of the scaffolding while I worked on the business logic and model training. The result had problems. Error handling was too aggressive, logging was inconsistent, and it picked a library I would not have chosen. It still worked, which is the bar for a prototype, and I could not have done it alone in three days.

Code review late at night

We do not have a CTO, so final decisions on architecture and security sit with me, and I review a lot of pull requests at inconvenient hours. I point Claude Code at the diff and ask what is wrong with it. It compares the change with the rest of the codebase and lists concerns: missing checks, likely security gaps, slow queries. It catches mechanical issues I miss when tired.

It misses business context. It does not know that a particular data flow breaks a regulatory constraint one of our clients operates under. So I use its review as a first pass and spend my own attention on the questions only someone who knows the client can answer.

Directing the tool

The "AI Boss" name came from a 2014 session at my first startup. I took a non-technical colleague through building a neural network from scratch at a whiteboard, raw maths and all, and by the end she was asking questions I had not thought of. She called me the AI Boss, and the idea behind it stuck: you direct the AI, not the other way round.

Claude Code tests that more than any tool I have used. It can write whole applications and refactor large codebases. Given vague instructions, it will also produce code that runs and is badly structured. I have done that to myself when I was lazy with a prompt. Before I ask for anything substantial I write down the architecture I want, and I never deploy code I have not read.

Three rules I give my engineers

Every engineer at StarApple AI and across our labs has access to Claude Code.

1. Use it for the routine work. Data validation, boilerplate endpoints, test scaffolding and migration scripts. Keep your own attention for problems that need domain knowledge.
2. Read every line it writes. You are responsible for what ships. If you cannot explain what a function does and why, it does not go to production.
3. Study its different choices. When it solves a problem differently from you, work out which approach is better. Sometimes it knows a better pattern; sometimes it picked a worse one.

What goes wrong

• Plausible but wrong code. It sometimes writes code that looks right and fails on an edge case, or calls a library function that does not exist. Tests catch most of this.
• Loops. It can keep retrying variations of the same broken approach. When that happens I end the session, rethink the problem and start again with a clearer description.
• No Caribbean context. It does not know Jamaican credit union regulation, or that the internet drops in some parishes during heavy rain. I keep that context in a project file it reads at the start of each session, instead of retyping it.
• Your code leaves the building. Claude Code runs the model on Anthropic's servers, so any file it reads is sent to Anthropic. For client code, check your contract and use a plan whose data terms your client accepts.

What has changed for me is speed. Fifteen years of building AI systems gave me the judgement to check its work; it gives me prototypes in days instead of weeks and code review that does not wear me out. For a Caribbean founder with little capital, that time matters.

"Claude Code gives you back the hours you used to lose to boilerplate. Your engineering judgement decides what to do with them." - Adrian Dunkley, AI Boss

What to do next if you run a small tech team

1. Founder or tech lead: pick one repository and one routine task this week, such as writing tests for an untested module, and compare the time taken with and without Claude Code.
2. Tech lead: write a CLAUDE.md file at the root of each repo covering architecture, coding conventions, test commands and local constraints (regulation, connectivity, client rules). Update it whenever Claude Code gets something wrong for lack of context.
3. Every engineer: run Claude Code on a feature branch, never directly on main, and do not give it production credentials.
4. Founder: before using it on client code, check each client contract for restrictions on third-party processing, and choose an individual or business plan accordingly.
5. Reviewers: add "AI first-pass review done" to your pull request checklist, and keep a human review for business logic and security before merge.

Frequently Asked Questions

How do I stop re-explaining my project to Claude Code every session?

Put the context in a CLAUDE.md file at the root of the repository. Claude Code reads it automatically at the start of each session, so architecture notes, coding conventions, test commands and local constraints only need writing once. Keep it short and specific, and add a line each time the tool makes a mistake that the file could have prevented.

Does Claude Code send my source code to Anthropic?

Yes. The tool runs in your terminal, but the model runs on Anthropic's servers, so any file Claude Code reads, and the output of commands it runs, is sent there for processing. Anthropic's commercial terms for business and API customers differ from consumer plan settings on data retention and training use, so check which terms apply to your account before using it on client code.

What does Claude Code cost?

It is included with Anthropic's paid Claude plans, starting with Pro at US$20 a month, and it can also be billed per use through an API account. Heavy daily use on large codebases can reach the Pro plan's usage limits, which is when teams move to a Max plan or API billing. Track a month of usage before committing a whole team to one option.

Is it safe to let Claude Code run commands on my machine?

It asks for permission before running commands or editing files, unless you change that setting, so the safety depends on what you approve. Work on a feature branch so every change can be reviewed and reverted. Keep production credentials and customer data out of the environment it can reach.

Can a non-developer use Claude Code?

It works in a terminal and assumes you can read the code and test results it produces, so it suits developers best. A founder who does not code can still use it to get plain-English explanations of an existing codebase. For document and file work, the Claude desktop and mobile apps are a better fit.