Claude Code in the trenches: memory and planning

Agent memory after context compaction After context compaction, Claude Code automatically rereads the CLAUDE.md files — global and project-level. Whatever you put there, it will remember after compaction. What must be in CLAUDE.md: — the agent's role — deploy paths and the deploy method We'll come back to deploy itself, but if you don't spell out the method, it forgets how code reaches production and tries different options every time. There are countless options, and that breaks everything. How I work with any change Fixed something — immediately commit through Git, then tell the agent to remember what was done in the relevant section of memory. Planning: 90% prep, 10% execution Doesn't matter if it's a bug or a new feature — even when you work in plan mode and let Claude Code go full subagent, it still skips critical things. The more complex the change, the more you need to run the same questions through several times, from different angles. And it will keep finding new errors. Example: when I rolled out crypto payments, planning took 5–7 hours and around 40 passes of questions from different angles. After that I drew up the final plan. Execution itself took literally 5–10 minutes. Project knowledge base A very useful thing — launch a subagent after you've spun up your project, and have it analyze the entire codebase. Let it write a project description on its own — but a useful one, in human language. It reads it later itself, and you can also see what you've made.

Claude Code in the trenches: tasks and control How to set a task properly First you shove Claude Code's nose into the problem without telling it what the problem is. For example: "Study how delivery slots are built. How it's done in the admin panel, how it's done on the storefront. Study every dependency and propose how to add a time restriction for certain zip codes. The city has traffic jams, and these places are simply unreachable. Make a plan, launch subagents, trace every dependency so we don't break the project's existing logic." It makes a plan. You copy it and hand it to a bug-hunting subagent so it does another pass and looks at what's missing. The main Claude Code stays in plan mode. When recommendations come in — you ask it to evaluate them, because the recommendations are often garbage. When you think the plan is ready — you execute. And before deploy, you hunt bugs again: the same questions, asked in different words. Subagents and cross-validation It's useful to create a separate subagent dedicated to bug hunting. Even better — use different models: Claude, Codex, Gemini. They all hallucinate, but if you bounce ideas between them, it becomes clear what's actually worth doing. When to stop If you sit on a task too long — it starts pulling problems out of thin air. It will almost never say "everything's fine." The more you ask, the more it finds. From there it's up to you to decide where to stop. Technical debt Claude Code is good at finding bugs and sorting them by priority. Don't be afraid to file non-critical things into technical debt and come back later. It works better when it solves one task at a time. Give it a big one — it starts skipping. Example: translating a site from Russian to English. All articles, product descriptions — there's a ton of them. I had to run the task 10–15 times because it just skips chunks while saying it did everything. Same with SEO optimization — a separate topic that ate three weeks, maybe a month. You can't solve it in one command. Even with agents — it's work, it's your time. User feedback When a problem comes in from clients — you just paste their message into Claude Code and ask it to find where, what, and why something doesn't work.

Claude Code in the trenches: prod and reality Deploy: a dev server is mandatory When you think everything's ready — commit through Git and look at dev. Testing on prod is unrealistic. When dev is fine — you deploy. Then you test live. In my case — that's constant checking of order creation. Golden rule Don't change anything in production during the workday. Learned that the hard way. Logging is your best friend I made a separate page in the admin panel: — login attempts — registrations — order creation Separately — a recording of the entire client session that you can replay like a video. You see all the mouse movements — you understand what the client felt while wandering around the site. All API call errors are logged. After the day, you look, hand it to Claude Code, and dig through. If you're building a system — log everything you can. Bugs always get found There hasn't been a case where a bug wasn't found. Sometimes not right away, but within 5–20 minutes everything surfaces. Frontend stalls Sometimes Claude Code stalls on simple things, especially on the frontend. It starts guessing. In moments like that it's better to take the task and hand it to another model. They often give a solution right away — you feed it back, and it fixes in 2 minutes. Be careful with new features The more logic, the more bugs. Add gradually. Otherwise you drown in fixes later. The project needs time to simply settle. Human factor Dispatchers and admins don't grasp that the system logs every step, every click. The whole session is tracked — you immediately see who did what wrong. Case: an admin wanted to give one person a discount — and gave 20% off everything for everyone. Found out a day later. And of course "the system" is to blame. You need to be ready for this. Rollbacks and checks There were only a couple of rollbacks. But even with all the checks, in 30–50% of cases after deploy something has to be redone. Yes, Claude Code sits in Telegram topics, and with voice commands you can fix things from the park, from a taxi, from a bench. Convenient. But it's better to sit at the computer until you've personally confirmed everything works. That's the main reason I moved my whole dev environment onto a remote VPS. The laptop became just a terminal. Access — from anywhere. Final The work isn't writing code. The work is: watching, checking, going back, and not letting the system fall apart.