Working with Claude Code: 5 tips to produce good quality code

TL;DR: if you only have 2 minutes

Starting a tech project this year? Before you touch anything, make sure you have done this:

• ☐ I answered the 10 brief questions in writing, not in my head, in writing
• ☐ I have one clear sentence that sums up the problem the project solves and for whom
• ☐ My requirements document exists, and it was reviewed and approved by every decision-maker before development started
• ☐ My CLAUDE.md file exists and points to the right project documents
• ☐ My technical architecture was approved by a tech lead
• ☐ I never send a request without defining the expected behavior and the “it’s done” criterion
• ☐ I move one feature at a time, and I validate before extending
• ☐ My team clears the context (/clear) at every new task in Claude Code
• ☐ My team uses the right model for the right job, not Sonnet to change a color
• ☐ My meetings are recorded and the transcripts live inside the project
• ☐ When something changes, the files get updated before we move on

Intro

Open any vibe coding tool and ask: “build my app”. You will get a fast result, sure, but an average one. Tokens are cheap these days, but every correction makes you pay again: in tokens, in time, and in frustration.

To produce quality code with Claude Code, you need more context (but not too much) and more structure (but not too much either). Let me explain.

The way I see it, working with AI demands more rigor than before. Not less. The robot goes fast, very fast, but in the direction you give it. If your direction is fuzzy, it goes fast in the wrong direction.

I learned this the most direct way possible: I signed up for a 90-minute hackathon without knowing how to code, with Claude Code as my only tool. One week of preparation, 90 minutes of execution. I finished 5th out of 14. What kept me in the race was not technical talent. It was structure.

Here is what I passed on to my teams afterwards. 5 tips, in the order you should apply them.

1. Brief first: answer the 10 questions before writing a single prompt
2. Structure the project: a PRD, an architecture, and a CLAUDE.md that acts as a compass
3. Iterate small: propose, test, validate, implement. Never everything at once
4. Manage the context: clean up between tasks, use the right model for the right job
5. Document in real time: what is not written down does not exist for the robot

This article is written for you, the non-tech entrepreneur or project manager, about to launch a project with an AI-augmented developer or directly with Claude Code. You can copy-paste the prompts as they are to your team or to your AI agent.

---

Tip 1: Brief first

For you, the entrepreneur:

The robot does not guess. It executes. And if it does not have the right information, it makes things up, and you pay for fiction.

Before opening Claude Code or sending your brief to your dev, take 30 minutes to answer these 10 questions in writing. You can ask AI to help you fill them in, but do not delegate this thinking blindly. You are the one who knows your project.

1. What is the project? In one sentence: what problem it solves, for whom.
2. Who is building it? Background, technical level, design preferences.
3. Who are the end users? Comfortable with digital tools or not at all?
4. Where does the data come from? CSV, existing database, manual entry?
5. Which features are essential? And which ones are out of scope for now, but could be requested later.
6. Is there a brand style guide? Colors, fonts, logo. If yes, provide them.
7. What are the time constraints? Deadlines, payment milestones, slow periods.
8. Who are the players? Client, project manager, tech, testers. Their languages, their roles, their availability.
9. Which tools do we use? GitHub, Notion, ticketing tool, MCP integrations.
10. Where does the team stand with AI? Who has already shipped with it, who is just starting.

This document is your brief. Without it, everything that comes next is fragile.

The prompt to give Claude Code (or your dev) to help you fill in the brief

Copy-paste this into a new Claude Code session, with your raw notes attached:

You are my assistant for scoping a tech project. I am going to give you my raw notes about a project I want to launch. Your mission: help me fill in a complete brief by answering the 10 questions below.

Rules:
- Do NOT write the answers for me if you do not have the information. Ask me the question directly.
- For each question, if my notes contain a partial answer, propose a clear wording and ask me to validate it.
- At the end, produce a clean `BRIEF.md` file, structured with the 10 sections.

The 10 questions:
1. The project in one sentence: problem solved + target audience
2. The creator: background, technical level, design preferences
3. The end users: profile, comfort with digital tools
4. Data source: CSV, existing database, manual entry
5. Essential features vs. out of scope
6. Brand style guide: colors, fonts, logo
7. Time constraints: deadlines, milestones
8. The players: roles, languages, availability
9. The tools: GitHub, Notion, MCP, tickets
10. The team's AI maturity

My raw notes:
[PASTE YOUR NOTES HERE]

Start by asking me questions about the missing information, one at a time. Wait for my answers before continuing.

And to add a feature along the way

Same logic, short version. Answer these questions before sending anything to your team or to the AI:

1. What is the feature? What it does, for whom, in which situation it kicks in.
2. What is the expected behavior, step by step? The user does X, sees Y, can do Z. Without this, the robot guesses, and it guesses badly.
3. Does it modify something that already exists? If yes, what exactly, and are the people concerned aware of it.
4. Is it in the initial plan? If not, is it an evolution approved by the decision-makers, or just a good idea that has not been discussed yet.
5. What is the “it’s done” criterion? How you will know it is finished and correct. Without a validation criterion, everything stays subjective.

A request without these answers is not a request. It is an intention. And an intention cannot be coded.

---

Tip 2: Structure the project in three documents

For you, the entrepreneur:

Before a single line of code gets written, three documents must exist. In this order.

Document 1: the PRD (Product Requirements Document)

This is the WHAT and the WHY. It describes what we are going to build, for whom, in what order, and why in that order. It lists the features to develop by priority, what is out of scope for now, and the criteria that let you say a feature is finished.

Claude can write a first version from your brief. But this document must be reviewed and approved by all the leads, client included, before anything starts. Launching development without a PRD that everyone understands and accepts is out of the question. This is the document that prevents the “oh but I thought that…” three weeks later.

The prompt to generate your PRD:

You are a senior product manager. From the attached brief, write a PRD (Product Requirements Document) structured as follows:

1. **Vision & problem solved** — 3 sentences max
2. **Personas** — who the users are, their current frictions
3. **V1 scope** — list of essential features, by order of priority
4. **Out of scope for V1** — what we are NOT doing now, with justification
5. **User stories** — in the format "As a [persona], I want [action] so that [benefit]"
6. **Acceptance criteria** — for each feature, how we know it is done
7. **Risks & assumptions** — what could go wrong
8. **Milestones** — validation steps with the client

Constraints:
- Use `think hard` mode to structure your ideas before writing
- Do NOT propose anything that is not in the brief. If information is missing, list it at the end in an "Open questions" section
- Deliver the result in clean Markdown, ready to share

Source brief:
[PASTE THE CONTENT OF BRIEF.md HERE]

Document 2: the Architecture

This is the HOW. Once the PRD is approved, a tech lead (human or AI in think hard mode) defines how the project will be technically structured to meet the PRD requirements: tech choices, file organization, database structure, endpoints.

This document gets approved by a tech person. As the client or project manager, you should be able to open it and think “ok, this file exists, the topic is covered.”

The prompt to generate the architecture:

You are a senior tech lead. Switch to `think hard` mode.

From the attached PRD, propose a complete technical architecture for this project.

Your deliverable must contain:

1. **Recommended tech stack** — frontend, backend, database, hosting. With a short justification for each choice.
2. **Folder structure** — clear project tree
3. **Data model** — main entities, relationships, key fields
4. **API endpoints** (if applicable) — list of routes with HTTP method and payload
5. **External dependencies** — third-party services, APIs, MCP servers
6. **Deployment plan** — environments (dev/staging/prod), minimal CI/CD
7. **Points of attention** — technical risks, potential debt

Constraints:
- Favor SIMPLICITY. No exotic tech without a strong reason.
- For each choice, give a simpler alternative we could take if the scope shrinks.
- Deliver the result in an `ARCHITECTURE.md` file

Source PRD:
[PASTE THE CONTENT OF PRD.md HERE]

Document 3: CLAUDE.md

This is Claude’s compass at every session. Contrary to what you often read (“it’s like the onboarding brief of a new hire”), I see it more as the project’s keyring: it explains which key opens which door, and what is behind it.

It must contain:

• In one sentence: why the project exists and what problem it solves
• The players and their roles (one line per person)
• Where to find and update the documentation
• Which documents to read for which type of task
• The validation workflow: specification → development → test → validation → deployment

That last point is crucial. Claude must know that it does not code a feature that has not been specified, and that it does not deploy without testing. If you do not tell it, it improvises, and improvisation burns tokens and produces code you do not need.

The prompt to generate your CLAUDE.md:

You are going to create a `CLAUDE.md` file that will act as a compass for Claude Code at every session of this project.

This file is NOT complete documentation. It is an index that points to the right documents and sets the rules of the game.

Expected structure:

## The project in one sentence
[Problem solved + target audience, in 1 line]

## The players
- [Name] — [Role] — [Main language]
- ...

## Where to find what
- Initial brief: `BRIEF.md`
- Functional requirements: `PRD.md`
- Technical decisions: `ARCHITECTURE.md`
- Meeting history: `/transcripts/`
- Learnings & corrections: `MEMORY.md`

## Which document to read for which task
- You need to code a feature → read `PRD.md` + `ARCHITECTURE.md`
- You need to debug → read `MEMORY.md` + the code concerned
- You need to make a product decision → ask [Name], never decide alone
- You need to make a technical decision → ask [Name], never decide alone

## Mandatory validation workflow
1. Written specification (in PRD.md or a ticket) before any code
2. Plan proposed before implementation
3. Human validation of the plan before writing code
4. Test after implementation
5. Human validation before deployment

## Non-negotiable rules
- NEVER code a feature that is not specified
- NEVER deploy without testing
- NEVER modify `ARCHITECTURE.md` or `PRD.md` without written validation
- At every new task: `/clear` to start clean
- For a simple edit: use Haiku. For a design task: Sonnet + `think hard`

Generate the file from the information in the attached brief.

Brief:
[PASTE THE CONTENT OF BRIEF.md HERE]

---

Tip 3: Iterate small, always

For you, the entrepreneur:

This is the most common mistake. You show up with a complete idea, you say “build me the app”, and it does. Except the design is off, the structure does not match what you imagined, and you have to redo everything. You just spent tokens for nothing.

The rule is simple:

Propose → Test → Validate → Implement.

Never everything at once. Always on a small unit.

Example: instead of “build me the homepage”, you say “build me the first section, just that one, taking inspiration from the design of this site [URL]. We look at it, we adjust, and then we continue.” You validate one section before moving to the next. One feature before the next. One decision at a time.

💡 PRO TIP: To stay focused on what matters, ask Claude Code to handle the main use case first. Edge cases come after.

The prompt to use for EVERY new feature

I want to add a feature to the project. Before writing any code, follow this strict protocol:

STEP 1 — Understanding
Rephrase in your own words what you understood from my request. Include:
- The expected user behavior, step by step
- The existing files that will be modified
- The new files that will be created
- The external dependencies or APIs concerned

STEP 2 — Open questions
List the ambiguities or decisions you cannot make alone. Ask me precise questions. Do not invent anything.

STEP 3 — Implementation plan
Propose a plan in numbered steps. For each step: the file touched + the action. Focus on the main use case, leave the edge cases for later.

STEP 4 — Validation criterion
Propose a clear test criterion: "the feature is done when [X is true]".

STOP. Wait for my written validation before coding.

My request:
[DESCRIBE YOUR FEATURE HERE]

Tools like OpenSpec let you formalize this process: propose, archive what is validated, deploy what is ready. But even without a dedicated tool, a simple checklist.md with the status of each deliverable is enough to stay in control.

The core idea: the AI proposes, you test, you validate, it implements. In that order. Always.

---

Tip 4: Manage the context properly

For you, the entrepreneur:

Claude Code re-reads the state of the project at every new session. If your team piles up context without cleaning, every new request costs more and gets less precise.

Three simple rules to impose on your team or on yourself:

1. At every new task: /clear. It is the one reflex to build.
2. The right model for the right job:

– Design tasks (PRD, sprint, architecture): think hard + plan mode. That is where you need the power.

– Simple edit tasks (fixing a file, adjusting a style, renaming a variable): a light model like Haiku is enough. No need to call on Sonnet to change a color.

1. When Claude gets it wrong: question it before starting over.

The prompt to use when Claude delivers bad work

Instead of correcting and moving on, stop and send this:

What you just delivered does not match what I expected.

Before I ask you to start over, I want to understand what went wrong. Answer these 4 questions:

1. What information were you missing to get this right the first time?
2. Where should it have been documented so you had access to it?
3. Which ambiguous instruction in my prompt led you astray?
4. What should I add to `CLAUDE.md` or `MEMORY.md` so this problem never happens again?

After your answers, propose a version to add to `MEMORY.md`. I will validate it before we resume the task.

That feedback is often worth more than the correction itself, and it improves every future cycle. As a team, centralize these learnings in a MEMORY.md file that Claude re-reads at startup.

---

Tip 5: Document in real time

For you, the entrepreneur:

Every decision made in a meeting that is not written down does not exist for the robot. And often, it ends up no longer existing for the team either.

Three reflexes to install:

1. Record your meetings. Get the transcript. Put it in a /transcripts folder in the project. Claude can refer to it to understand why a decision was made.
2. When a feature changes, a milestone moves, or client feedback comes in: update the files. PRD.md and CLAUDE.md are living documents, not archives.
3. New decision = update before moving on. No “I’ll do it later”.

The prompt to use after every important meeting

Here is the transcript of a project meeting. Your mission:

1. Summarize the DECISIONS made (not the discussions, the decisions).
2. For each decision, indicate:
   - Who made it
   - What changes concretely
   - Which project file(s) must be updated (`PRD.md`, `ARCHITECTURE.md`, `CLAUDE.md`, other)
3. List the action items with owner and deadline if mentioned.
4. Propose the exact changes to make to the files concerned. For each file: indicate the section to modify + the proposed new content.

STOP after this analysis. I will validate the changes before you apply them.

Also save the original transcript in `/transcripts/[DATE]-[TOPIC].md`.

Transcript:
[PASTE THE TRANSCRIPT HERE]

The robot is only as good as the information you give it. Up-to-date files: it works fast and right. Outdated files: it heads in the wrong direction, and you spend your time correcting things that should never have been done.

---

Bonus: free consultation

You want to start a tech project this year without heading in the wrong direction?

I offer a free consultation session where I do a complete review of your project’s instructions and AI setup.

Here is how it works:

1. You send me what you have: brief, PRD if you have one, CLAUDE.md, architecture, tickets, recurring prompts.
2. I analyze them before we talk. No “we’ll see during the call”.
3. We meet for 45 minutes. Together we look at what is missing, what is fuzzy, and how to structure it properly before launching anything.
4. You leave with a clear roadmap, even if we do not work together afterwards.

The idea is simple: you know exactly what to prepare, what to get validated, and what to ask your team (or your AI) so your project moves forward without costing you time or money.

👉 Book a free session →