When I first learned about using the /context command I was under the impression that once those little bubbles of context were used up they were sealed off forever. After using claude more I have really grown to appreciate the foresight it provides and I am using it in my overall workflow much more frequently.
I use 2 MCP tools currently.
- chrome devtools
- supabase
I rarely use devtools at this point and prefer a much fast copy paste approach to debugging but the supabase mcp has proved invaluable. The speed to delivery is probably a third of the time it would have normally taken to implement a new feature in the DB.
The biggest gain there though has been the edge taken off by not having to copy paste HUGE sql files in to supabase, run into problems, do it again. That became frustration. BUT a supabase MCP article is for another day.
What I found by regularly using these tools in my workflow is that they would eat up context quickly. You can see here that even early in the conversation a good chunk of context is already taken up by supabase tools
Seems pretty manageable at first but problems can start happening after a conversation is compacted with claude and avoiding it or at least being aware of it ahead of time can be a great way to plan your overall project execution.
So let's investigate a little further. This is deep into a conversation and at a point where I would consider wrapping up or handing off to another claude.
Now this is where you can use the planning around context to your advantage because having checked /context at intervals during the development cycle you know now it's time to free up some of that valuable little cube space!
so hit /mcp and free some of it up
Now you have about double the amount of free space you had before!
Using this technique in my workflow has allowed me to prepare for when claude will start performing badly.
What happens when claude goes through a compaction process or 2 or 3?
- marks tests as .skip instead of fixing them
- tried to change the pre-commit hook preventing bad code like eslinterrors and warnings
- hides results of the full tests results in it's output on pre-commit and requires further digging and prodding
This is the thing claude suffers from Completion Bias. This is something I will talk more about in further articles but because of Completion Bias claude WANTS to think, and so there for wants to make you think, that claude is done working. Many times claude is NOT done and so you need to have measures in place to prevent bad code from going to production.
I hope this helps you with your coding!
Top comments (0)