Claude Code Rules for Non-Technical Founders

Eight months ago I had never opened a pull request. This year I ship the GrowthMentor codebase myself with Claude Code, three to five pull requests a day, and I stopped paying $10,000 to $15,000 a month for developers. I wrote about how that started earlier this year.

What I did not write about is the first month, because it was embarrassing. The same login bug fixed three times in one afternoon. A "small change" to the booking page that touched forty files. A session that had been open since breakfast and could no longer remember what we agreed at breakfast. And a bill that went up on the days when nothing shipped.

The requests coming into GrowthMentor now describe the same month. Since May, dozens of founders have booked calls about a product built with Claude Code, Lovable, Bolt or Cursor, and the bookings doubled in August. Almost half of them use the same words. Bloat. Spinning. Correcting mistakes it already corrected. Burning real money.

The good news is that nearly all of it comes from five or six habits, and the fix for each one fits in a sentence. Anthropic has published most of them in its own Claude Code documentation. The rest I learned by getting them wrong.

Why it spins

Every Claude Code session has a context window, the working memory it reads before each reply. Everything you have said, every file it opened, every failed attempt and every error message sits in it. Anthropic's best-practices page puts the constraint in one line. "Claude's context window fills up fast, and performance degrades as it fills."

That explains the afternoon with the login bug. By the third fix, the session contained two wrong fixes, the errors they produced, and my increasingly short replies. The agent was reasoning over a pile of failed approaches, and it kept reaching for them.

The docs say what to do, and it is the least intuitive rule of the ten. "If you've corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches. Run /clear and start fresh with a more specific prompt that incorporates what you learned."

Once you know the constraint, most of the other rules are ways of protecting it.

The ten rules

1. One feature, one session. Start a fresh session for every piece of work, and clear it when you switch to something unrelated. Long sessions feel productive because nothing is lost. What is lost is the agent's ability to tell your current instruction from the ones it abandoned an hour ago.

2. Plan first, and make it interrogate you. Claude Code has a plan mode that stops it from touching files until you approve an approach. Use it for anything that touches more than one file, and tell it to keep asking questions until the plan matches what you had in mind. Anthropic's own cut-off is useful. "If you could describe the diff in one sentence, skip the plan." Everything else gets a plan.

3. Keep the rules file short, and earn every line. Claude reads a file called CLAUDE.md at the start of every conversation. The instinct is to fill it with everything you want. The docs say the opposite, in capitals. "Bloated CLAUDE.md files cause Claude to ignore your actual instructions!" and target under 200 lines. Mine has fifteen numbered rules, and every one of them exists because the agent did the wrong thing once. Never run the full test suite on the laptop, push to CI. Console commands on one line. Do not use the same round timestamp for two migrations, because in August two of them collided and blocked every deploy until one was renamed.

4. Give it a check it can run. This is the rule that separates a session you watch from one you can walk away from. Tests on the three flows that make you money, sign-up, booking, payment. A build that has to pass. A screenshot it has to match. The docs are blunt about the alternative. "Claude stops when the work looks done. Without a check it can run, 'looks done' is the only signal available, and you become the verification loop."

5. For a bug, ask for a failing test first. Not "fix the login bug". Write a test that reproduces the bug and fails, then fix the code until the test passes, then run the whole file. The order matters, because the failing test is the proof the bug existed and the passing test is the proof it is gone. Without it, "fixed" means the agent believes it is fixed.

6. Review in a second session, and put a human on the logic. The agent that wrote the code is the worst reviewer of it, and Anthropic says so. "A fresh context improves code review since Claude won't be biased toward code it just wrote." So the review is a new session, or a subagent, reading the diff cold. Then a person. The first thing I did in January was hire a senior developer for a few hours a week to shadow me, flag anything obviously bad, and rebuild the worst of it before it reached the codebase. I still do. The agent's own review is a first pass, never the sign-off.

7. Learn the nouns. You do not need to write a serializer. You need to know what one is, so that when the agent adds three of them for a one-field change you can say no. My list from the first months, and it has not grown much since. Databases, edge functions, API calls, auth, row-level security, serializers, controllers, schema. An hour with each is enough to catch over-engineering, and over-engineering is where the bloat comes from.

8. Ask for the smallest change, and delete on the way out. AI-written code duplicates. GitClear's 2025 study of 211 million changed lines found blocks of five or more duplicated lines up eightfold during 2024, and refactoring down to under 10% of changes from 25% three years earlier. The agent will happily write a new helper instead of finding the existing one. So the prompt says "smallest change that does this, reuse what exists, no refactor unless I ask", and the end of a session includes "what did we add that we could remove".

9. Every session ends in a commit or a revert. Small commits on a branch per feature, so that "it fixed this already" has a history you can go back to. If the session went sideways, revert to the last commit and start again with rule 1. A codebase where every change is a commit is one where a bad afternoon costs an afternoon.

10. Know what an hour costs, and read the meter as a symptom. Claude Code is included in the $100 and $200 Max plans, Lovable starts at $25 a month for 100 credits, and every one of these bills climbs fastest on the day the agent is stuck. That is not a pricing problem. A spend spike on one bug is rule 1 telling you the context is full. Type /usage, look at the session, and clear it.

What the research says about speed

Two numbers I keep in view. In July 2025, METR ran a randomised study with sixteen experienced open-source developers using Cursor with Claude. The developers predicted AI would make them 24% faster. Measured, they were 19% slower, and afterwards they still believed they had been sped up. METR's 2026 follow-up with newer tools found something closer to an 18% speed-up for returning developers, and called its own data "only very weak evidence".

I take two things from that. The first is that the feeling of being fast is not evidence, which is why rule 4 exists. The second is that for someone like me, who could not write the code at all in January, the comparison is not 19% slower than a developer. It is shipping versus not shipping, with a review step in between.

Quality has a number too. Veracode tested more than a hundred models on eighty coding tasks in 2025 and found that 45% of the generated samples contained a flaw from the OWASP top ten, with cross-site scripting failing 86% of the time. Their 2026 update across 150 models put secure output at 55%. The code compiles. Whether it is safe is a separate question, and the agent will not raise it unless you do.

Security is not in the vibes

Andrej Karpathy coined the term in February 2025, and the definition was clear about the trade. "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." That is fine for a throwaway. It is how a founder ends up with a production app where anyone can read anyone's data.

Simon Willison drew the line I use. "If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else, that's not vibe coding, it's software development."

So before anything with real users, three specific asks. A subagent review of the diff for security issues, in the docs' own phrasing. Row-level security on every table that holds user data, and a test that proves a logged-in user cannot fetch another user's rows. Authentication on every endpoint, checked by a test, not by reading the code. If those three sentences are unfamiliar, rule 7 comes first.

Bring the repo to someone who has shipped with an agent

Book a call with a CTO or senior engineer who builds with Claude Code every week. Bring your CLAUDE.md, your last stuck session and the diff. Leave with the three rules you were breaking. Unlimited calls, one membership.

Talk to a mentor

When to stop and call a human

The pattern in the requests is that the founder is alone with the agent, and the agent is very good at sounding sure. Nobody in the loop can say "that is the wrong approach" until a mentor reads the plan.

That is also how I got here. A mentor, Matthew Kay, told me to try Claude Code on a workation in January when I had already decided I could not. A senior developer reviewing my changes each week is what turned trying into shipping. Neither of them wrote the code. Both of them changed what I wrote.

The people below build with agents daily and will read your setup, not your product pitch. One call is usually enough to find which of the ten rules is doing the damage.

The outside voice

Engineers and CTOs who ship with Claude Code and will read your setup with cold eyes:

Roman

Co-founder and CTO at Agewise, coaches teams on agentic engineering. 20 sessions.

Book a call

Alex Ayache

CTO at Cobble, two-time founder, Techstars mentor. 60+ sessions.

Book a call

Sam Meurs

CTO with 15 years in SaaS startups, product and technical strategy. 15+ sessions.

Book a call

Julien Sch.

Product leader at Swiss Re, helps founders with product strategy and AI integration. 40+ sessions.

Book a call

More of them are on the AI mentors page.

The next session starts with three things. A new window. A plan the agent had to ask you about. And one check it can run before it tells you it is done. If the same bug comes back a third time, do not fix it. Clear the session, write down what you learned, and bring the diff to someone who has read a thousand of them.