5 Claude Code Tips From Running Four AI Labs in Jamaica

I use Claude Code on almost every project at StarApple AI, Maestro AI Labs, Section 9 and IMPACT AI Lab. That is four labs, dozens of codebases and hundreds of sessions. These five habits changed the quality of what we ship more than any prompt template did.

They come from production work in the Caribbean, where teams are small and a broken release lands on a customer the same day.

1. State your constraints before your requirements

Open a session with what the code must not do, then say what to build. On a financial inclusion project, my first message is not "build me a credit scoring API". It lists the limits: Caribbean data protection rules apply, raw national ID numbers are never stored, no personal data goes to third-party services outside the region, and responses stay under 200 milliseconds because many users are on 3G in rural Jamaica.

With those limits stated up front, Claude Code picks lighter libraries, adds offline fallbacks without being asked and avoids designs you would have to throw away later. Treat constraints as design inputs and put them in the first message.

One constraint applies to Claude Code itself. The model runs on Anthropic's servers, so every file it reads is sent to Anthropic for processing. Work on synthetic or masked data, and keep real customer records out of the repository you open.

2. Have it write the tests first, in a separate step

Describe the behaviour you want and ask for the test suite only. Review it. Then, in a second step, ask for code that makes those tests pass.

When Claude Code writes the code and the tests together, the tests tend to describe what the code already does, so they pass by construction. Splitting the steps turns the tests into a check. At Section 9 AI Lab we adopted this for every new module, and in the first sprint it caught three bugs in safety-critical systems that the old workflow would have shipped.

It adds about ten minutes per feature. Tell Claude Code not to edit the test files during the second step, or it will sometimes "fix" a failing test instead of the code.

3. Write a CLAUDE.md file for every repository

Claude Code reads a file called CLAUDE.md from the project root at the start of each session. It is the cheapest improvement available, and most developers I meet either skip it or leave it as a stub.

Ours contain four things:

• Architecture in plain words. A few paragraphs on how the system fits together, not a link to a wiki.
• Conventions. snake_case or camelCase, explicit imports or wildcards, docstrings or none.
• Hard rules. "Never use eval()." "Never log personal data." "Validate every input from an external source." Once written down, these are followed consistently.
• Preferred libraries. requests or httpx, pytest or unittest. If you leave this out, Claude Code picks for you.

Every active repo at StarApple AI has one, and no two are alike. The financial inclusion repos carry data-handling rules, the sports AI repos carry latency budgets, and the climate resilience repos specify data formats. When Claude Code makes the same mistake twice, add a line to CLAUDE.md so it does not happen a third time.

4. When a session goes in circles, start a new one

If Claude Code keeps trying variations of the same broken approach, more corrections usually make it worse. Close the session, spend two minutes deciding what you actually want, and open a fresh one with a shorter, clearer description.

My rule at Maestro AI Labs: three failed attempts means the prompt is the problem. Rewrite it from scratch, or split the task into smaller pieces. In my experience the first answer in a fresh session beats the tenth answer in a stuck one.

A long, failing conversation fills the context with wrong answers, and the model starts staying consistent with them. A new session drops that history. Before closing the old one, ask it to summarise what it tried and why each attempt failed, and paste that summary into the new session as a list of approaches to avoid.

5. Let new engineers interview the codebase

New engineers on our teams now spend part of their first day questioning the codebase through Claude Code. They ask what a service does, why a function is structured the way it is, what happens when an endpoint gets invalid data, where migrations live and how authentication flows.

The answers are accurate enough to get someone oriented in an afternoon instead of a week of README reading and hesitant Slack messages. They still read the high-risk paths themselves, and they still have a human mentor who checks their understanding. For a Caribbean startup with a handful of engineers, cutting onboarding from weeks to days is the difference between a hire who ships in their first month and one who does not.

Why these habits work together

Each habit puts the engineer in charge of direction and checking, and leaves the typing to the tool. Claude Code is a power tool, and like any power tool it rewards the person who knows what they want from it.

I have told people to be the Boss of AI since 2014, when a nontechnical staff member at my first startup gave me the name during a sprint session where I taught her to build a neural network from scratch. The principle has not changed with Claude Code: you set the direction and constraints, you check the output, and you answer for what ships.

The weak spot in my own approach is habit 5. Claude Code can explain code confidently and still be wrong about intent, especially in older modules where the comments no longer match the logic. I have not found a reliable way to tell a new engineer which answers to distrust, other than pairing them with someone who wrote the code.

"Claude Code rewards clarity the way a good engineer rewards a good spec. Be precise about what you want. Be honest about what you do not know. The tool will meet you where you are." - Adrian Dunkley, AI Boss

What to do next

1. Tech lead, this week: run /init in your main repository to generate a starting CLAUDE.md, then spend 30 minutes adding your hard rules and preferred libraries by hand.
2. Each developer, on the next feature: ask Claude Code for the tests only, review them, then ask for the implementation with an instruction not to edit the test files.
3. Engineering manager, before the next sprint: write down a three-attempt rule for stuck sessions and share it with the team, so nobody spends an hour arguing with a looping session.
4. Whoever owns data protection, before anyone opens a repo: check that no production data, credentials or .env files sit in repositories people open with Claude Code, and move them out if they do.
5. Hiring manager, for the next new starter: give them a list of ten questions to ask Claude Code about the codebase on day one, and review their answers with a senior engineer on day two.