New possibilities

I’ve been using Claude Code on a daily basis for four months now. Starting from its $17/month plan, I quickly came to understand that if I want to use it exhaustively for all the crazy ambitions in my head, I will have to upgrade, because I was constantly hitting the 5h limit. For those of you who don’t know, Claude has two token caps: tactical one which resets every 5 hours and strategic one which resets every week. I’ve been hitting cap on both constantly. At some point I started contemplating the progress behind.

A year ago I would not delegate the smallest test to be fixed to AI because it would only break it in two more places. And now I don’t have enough tokens for everything I would like to task AI agent with. What changed? Well, first of all, models got “smarter”, obviously, N times smarter compared to the market year ago. Teams behind the agent are working hard to make development with models more… I don’t know, efficient? Complete? For example, the recently increased context window of Opus 4.6 from 200K to 1M is great news for every Claude user. You don’t have to orchestrate an army of lesser model agents to do some muscle work and provide the king Opus with concise results so that he could do his stuff. 1M window is honestly enough for anything with basic sanity of context management like “do not create Amazon in one session”.

The code quality itself increased. It’s not a straightforward and quite opinionated metric (unless, of course, calculating BigO complexities), so I’d better say that now I can look at generated code with much less disappointment. You still have to understand what you’re doing and why, drive your educated decisions based on analysis provided by foreign intelligence, your trust in that intelligence and your own expertise. If anything, it seems quite similar to what tech leads and product owners do.

For the past two months I’ve been constantly tailoring personal software solutions for my own needs. I’ve been fulfilling all my wildest fantasies of how nice it would be to have a personal offline map with markers functionality or a fast note shortcut. From addressing old pains to simply fantasizing about what’s next, I’ve been playing with Claude Code and its capabilities.

Product development & product owning

This is a ridiculously fun feeling: you can think of anything you need and immediately try to implement it. This is an unspeakable level of freedom.

When I went up to the $100/month plan, I hit another bottleneck. But this one was not a Claude restriction, but rather my own brain restriction - at some point I’m feeling the so-called “decision fatigue”. This is the moment when you’re so tired that you don’t want to make any decisions. You just want to get something done somehow.

And that “somehow” is exactly what I’d argue against!

For example, I’m using Superpowers plugin for Claude Code and it’s a well-tailored solution for developing middle-to-large features. It:

• brainstorms ideas with you;
• clarifies the questions;
• drafts the spec;
• self-reviews the spec and asks you to review it;
• drafts a plan;
• asks you to review it;
• finally implements the scope based on the plan.

You can see how much thinking- and decision-related involvement it requires from you. On each of the steps I’m feeling an enormous temptation to just let it spin itself spamming “go” like a monkey. Dealing with this flow several times a day, every day, is, to say the least, exhausting. Perhaps memes are not that far from the truth…

When faced with such temptations, I try to keep two things in mind. First, I’m thinking about all the hours in the world I’ve already saved compared to doing everything manually. Surely, I can spend 10 minutes to make sure I understand the plan and the plan is sound. Second, I remind myself that if I want to be in charge, I need to understand what I’m doing. That’s like basic sanity, right? Well, it’s not that obvious in the moment of laziness. My mind drifts to pleasant patterns like “will skip now, will learn later” (which I never do) or “nothing bad will happen if I skip this particular part” (I don’t know).

In my line of work, if you are not ready for product ownership, you are not ready for product development. So I’ve come up with a similar conclusion that if I’m not ready to dive into the details of something, I’m not ready to do that. And if I’m not ready to do that, I’d better get ready - go for a walk, eat well, sleep, take a break, dive into hobbies etc.

I’m sure there are a lot of philosophical- and mindset-ish topics about how you should and should not approach working with AI, but the topic above is my main struggle, thus an emphasis. And now, finally, to dense practical tips.

Dense practical tips for using Claude Code

1. Spend a couple of hours reading about how Boris Cherny uses Claude Code. This comes from experience of people responsible for developing Claude Code. They might know a trick or two.
2. Spend half an hour learning about context management in Claude Code. You need to understand which parts are persistent and which will go away. Also, in case you’re facing tight limit, you need to understand why it gets eaten and whether it’s optimizable.
3. Spend an hour learning how Claude Code auto-memory works. I kid you not, learning the difference between CLAUDE.md and MEMORY.md was the toughest mental challenge for me.
4. Develop a pipeline for context management, both for yourself as a constant practice and for Claude Code as a set of written rules. When you devise your one and only way of managing any context that comes your way while developing, immediately write it down and follow it. In the future you should think only about the context itself, not about how to write it down.
5. Store concise imperative rules that are globally true for your style of operations in ~/.claude/CLAUDE.md. This is the user-scoped rules file that gets automatically loaded into every Claude Code session that you launch from whatever folder.
6. Store concise imperative rules that are globally true for your current project in <whatever-it-is-called>/<your-project-name>/CLAUDE.md. This is the project-scoped rules file that gets automatically loaded into every Claude Code session that you launch from that project folder.
7. Move out situational detailed knowledge into separate .md files and refer to them from your CLAUDE.md files. It works both for global and project-scoped rules. Your CLAUDE.md files should remain as decluttered as possible, so you should eventually clean up and destructure them. Remember that they eat tokens from each of your sessions and that Claude Code follows them less reliably the bigger they are.
8. Make sure your <whatever-it-is-called>/<your-project-name>/memory/MEMORY.md stays under 200 lines… Claude Code cuts off anything above. MEMORY.md is the auto-memory file that gets automatically loaded into every Claude Code session that you launch from that project folder. It’s like a table of references to detailed .md files with short descriptions. Claude Code reads it to understand situations where he will need to load particular generated memory.
9. …or disable auto-memory feature completely. That’s my choice. I found myself managing all the information that Claude Code needs to know quite well. So this feature that eventually spins up whenever Claude Code decides to write down something I did not ask for, and which I might miss, creating context outside of my control… is, to say the least, quite useless. Furthermore, it distributes project-related files all over my PC because I got used to keeping all Claude Code context right in my repo while his auto-memory goes to global user .claude folder internals. I don’t want to jump between two places. Claude Code promised to allow doing this via /memory menu but it’s still to be done. So the only viable solution would be going to ~/.claude/settings.json and adding "autoMemoryEnabled": false line. This magic from a random web thread seems to be working:

10. If you do not feel constrained by token limits, use the latest Opus model in xhigh thinking effort by default.
11. NEVER put a possible bias in your questions and statements. Ask in the most neutral way possible because Claude tends to align with biases you verbally put in the discussion. For example, starting from “I don’t think it’s a good idea” makes it almost certain that Claude will redo his solution to align with your statement, even if quality will decrease.
12. Split tasks between agents and subagents for fresh angles. For example, when developing something in one Claude Code session and wanting a review of the result, ask Claude Code to spin up a subagent or just start another session in a separate window asking for review. That session will be less biased because it won’t contain discussions and decisions made in the initial session, thus it has better chances of finding something.
13. Adjust Claude Code behavior to your standards using skills. Write skills for all reusable procedures you might require. Pay attention to writing steps exhaustively and in an unambiguous manner. Don’t think too much about contextualizing the skill. You always can invoke it via command or explicitly asking to utilize it. And then you will never have to repeat yourself.

That’s not all, of course, but these are the most important ones for me. I think about Claude Code and work with it on a daily basis, following these principles, and find myself pleasantly surprised by the results.