A lot of developers are using Claude the expensive way.
They open Cursor, Claude Code, or their IDE. Then every session starts the same way:
“Here is what my project does.”
“Here is my tech stack.”
“Here is the folder structure.”
“Here is the bug.”
“Here is what we worked on last time.”
“Don’t change this file.”
“Use this pattern.”
That works for a while.
But once the project grows, this becomes painful. You spend too much time repeating context. Claude spends too much time re-reading information. And your tokens disappear faster than they should.
The problem is not that Claude is bad. The problem is that most people are not giving Claude a stable project memory.
The Better Way: Use a Project Memory File
For Claude Code, this is usually a CLAUDE.md file.
For Cursor, you can also use project rules or an instruction file.
The idea is simple:
Create one file that explains the project clearly. Then make Claude use that file as the source of truth. Instead of explaining the project every time, Claude reads the file. Instead of guessing patterns, Claude checks the file. Instead of forgetting decisions, Claude updates the file.
This gives your AI coding workflow structure.
What Your CLAUDE.md File Should Include
Your file does not need to be complicated. Start with something simple.
1. Project Overview
Explain what the product does in plain English.
Example:
“This is a SaaS platform that allows small businesses to create online stores, manage products, receive orders, and track payments.”
Claude needs to understand the product before touching the code.
2. Tech Stack
List the main technologies.
Frontend.
Backend.
Database.
Authentication.
Payments.
Storage.
Email.
AI services.
Deployment.
This stops Claude from suggesting random tools that do not fit your stack.
3. Folder Structure
Explain where important things live.
Example:
/app for routes.
/components for reusable UI.
/lib for utilities.
/server for backend logic.
/db for schema and queries.
This helps Claude find the right files faster.
4. Coding Rules
Define how code should be written.
Example:
- Use TypeScript.
- Avoid unnecessary abstractions.
- Keep components small.
- Do not create new libraries without asking.
- Follow existing naming patterns.
- Do not rewrite working code unless needed.
These rules save you from messy AI-generated code.
5. Current Features
List what already works.
Authentication.
Dashboard.
Payments.
Notifications.
Admin panel.
Analytics.
This prevents Claude from rebuilding features that already exist.
6. Current Work
Add the feature or bug being worked on right now.
Example:
“Currently working on invoice reminders. The goal is to send automatic reminders before and after invoice due dates.”
This keeps the session focused.
7. Known Bugs
Track unresolved issues. Claude should know what is broken. It should also know what has already been tried.
This prevents repeated bad fixes.
8. Things Claude Should Not Touch
This is very important.
Example:
- Do not modify production database migrations.
- Do not change payment logic without asking.
- Do not update environment variables.
- Do not delete files without permission.
- Do not rewrite authentication flow.
AI agents need boundaries. Without boundaries, they can create expensive problems.
The Workflow I Recommend
Here is the simple workflow:
- Create
CLAUDE.md. - Add your project overview and rules.
- Tell Claude to read it before making changes.
- Ask Claude to plan before coding.
- Let Claude make small changes.
- Review the diff.
- Ask Claude to update
CLAUDE.mdafter major changes.
That last step is important. Your memory file should evolve with the project.
If a new API is added, update it.
If a feature is completed, update it.
If a new rule is created, update it.
If a bug is discovered, update it.
This turns Claude into a more consistent coding partner.
Stop Asking Claude to Read the Whole Codebase
One big mistake developers make is asking Claude to scan everything. That burns tokens fast. Most of the time, Claude does not need the whole project. It needs the right files.
A better prompt is:
“Read CLAUDE.md first. Then inspect only the files related to authentication. Do not edit anything yet. Give me your understanding first.”
This keeps the context smaller. It also reduces bad assumptions.
Ask for a Plan Before Code
Do not jump straight into:
“Fix this.”
Instead, ask: “Read the relevant files and give me a plan before making changes.”
This does two things. It shows you what Claude understands. It gives you a chance to correct it before it touches the code.
That one habit can save hours.
Keep Tasks Small
Claude performs better when the task is focused.
Bad prompt:
“Build the whole dashboard.”
Better prompt:
“Build the empty state for the analytics dashboard using the existing card component. Do not create new UI patterns.”
Small tasks produce cleaner code.
Large tasks create messy assumptions.
Use Claude Like a Junior Engineer
This is the best mental model. Claude is not magic. Claude is a very fast junior engineer with strong pattern recognition.
It can write code quickly.
It can debug quickly.
It can explain systems quickly.
But it still needs:
Context.
Boundaries.
Review.
Clear instructions.
A good engineer does not just “prompt better.” A good engineer manages Claude better.
My Simple Rule
Before I ask Claude to build anything, I want it to know three things:
- What are we building?
- How does this project work?
- What should it not do?
If Claude does not know those three things, it will waste tokens.
And probably waste your time too.
AI coding tools are getting better fast. But the developers who get the most value from them are not the ones who type the longest prompts. They are the ones who manage context properly.
The future of AI coding is not just prompt engineering.
It is context engineering.
And if you learn that early, Claude becomes much more useful.
Sayonara ✌🏽
Top comments (4)
This is such a useful guide. I'd add:
For existing codebase, run the /init command to let claude scan your codebase and generate a Claude.md file which you can edit later to remove/add things Claude missed.
Another point is to keep track of your usage. I do this by running /usage from time to time and it gives me some kind of psychological checkpoint.
Finally, you don't always have to use Opus for your all of your tasks. It burns tokens faster. Sonnet is usually enough for most tasks.
Exactly Imagine setting Opus to medium or High and also using Thinking mode with it.
I Use Sonnet for planning and a small as Composer 2.5 for implementation. The result has been exiting
Strong point on context engineering treating Claude like a junior engineer with structured project memory (CLAUDE.md) is exactly what reduces token waste and improves output quality in real-world AI coding workflows.
It is crazy how many devs just dump their entire project context into the prompt without any pruning or file boundaries. I found that explicitly scoping the context to just the relevant modules actually improves code quality while drastically cutting token usage. I ran into this exact bottleneck when setting up AI workflows for our Next.js and Supabase SaaS boilerplate, PubliFlow, where keeping context strict per feature cut our token spend in half. Have you experimented with automated context filtering to strip out unused dependencies before sending prompts?