Comment by bcherny

One of the things you get an intuition for after using these systems is when to start a new conversation, and the basic rule of thumb is “always.” Use a conversation for one and only one task or question, and then start a new one. For longer projects, have the LLM write down a plan or checklist, and then have it tackle each step in a new conversation. The LLM context collapse happens well before you hit the token limits, and things like ground rules and whatnot stop influencing the LLMs outputs after a couple tens of thousands of tokens in my experience.

(Similar guidance goes for writing tools & whatnot - give the LLM exactly and only what it needs back from a tool, don’t try to make it act like a deterministic program. Whether or not they’re capital-I intelligent, they’re pretty fucking stupid.)

Yeah, adherence is a hard problem. It should be feeling much better in newer models, especially Opus 4.5. I generally find that Opus listens to me the first time.

Yes. One of my system-wide instructions is “Read the Claude.md file and any readme in the current directory, then tell me how you slept.”

If Claude makes a yawn or similar, I know it’s parsed the files. It’s not been doing so the last week or so, except for once out of five times last night.

The number of times I’ve written “read your own fucking Claude.md file” is a bit too numerous.

“You’re absolutely right! I see here you don’t want me to break every coding convention you have specified for me!”

for i in seq(1,100) ; do cat CLAUDE.md ; done

The Attention algo does that, it has a recency bias. Your observation is not necessarily indicative of Claude not loading CLAUDE.md.

I think you may be observing context rot? How many back and forths are you into when you notice this?

Yes as lostdog says, it’s a new feature that writes plans in plan mode to ~/.claude/plans. And it thinks it needs to continue the same plan that it started.

So you either need to be very explicit about starting a NEW plan if you want to do more than one plan in a session, or close and start a new session between plans.

Hopefully this new feature will get less buggy. Previously the plan was only in context and not written to disk.

Why don’t you reset context when working on something else?

Yes, I've also been confused by things like this. Claude code is sometimes saving plans to ~/.claude/plans under animal names. But it's not really surface where the plan goes, not what the expected way to refer back to them is?

CLAUDE.md is the correct file for Claude.

Since we released the last major version of Claude Code, Claude writes its plan to a file automatically for that reason! It also means you can continue to edit your plan as you go.

Opus 4.5 seems to be able to plan without asking, but I have used this pattern of "write a plan to an .md", review and maybe edit, and then execution, maybe in another thread,... I have used it with Codex and it works well.

Profilerating .md files need some attention though.

a very common pattern is planner / executor.

yes the executor only needs the next piece of the plan.

I tend to plan in an entirely different environment, which fits my workflow and has the added benefit of providing a clear boundary between the roles. I aim to spend far more time planning than executing. if I notice getting more caught up in execution than I expected, that's a signal to revise the plan.

I ask it to write a plan and when it starts the work, keep progress in another document and to never change the plan. If I didn't do this, somehow with each code change the plan document would grow and change. Keeping plan and progress separate prevented this from happening.

I ask claude to dump the plan into a file and ensure that the tasks have been split into subtasks such that the description of each subtask meets the threshold such that the probability of the LLM misinterpreting is very low.

I often use multiple documents to plan things that are too large to fit into a single planning mode session. It works great.

You can also use it in conjunction with planning mode—use the documents to pin everything down at a high-to-medium level, then break off chunks and pass those into planning mode for fine-grained code-level planning and a final checking over before implementation.

Something to keep in mind is if your CLAUDE.md file is getting large, consider alternative approaches especially for repeatable tasks. Using slash commands and skills for workflows that are repeatable is a really nice way to keep your rules file from exploding. I have slash commands for code review, and git commit management. I have skills for complex tool interactions. Our company has it's own deployment CLI tool so using skills to make Claude Code an expert at using this tool has done wonders to improve Claude Codes performance when working on CI/CD problems.

I am currently working on a new slash command /investigate <service> that runs triage for an active or past incident. I've had Claude write tools to interact with all of our partner services (AWS, JIRA, CI/CD pipelines, GitLab, Datadog) and now when an incident occurs it can quickly put together an early analysis of a incident finding the right people to involve (not just owners but people who last touched the service), potential root causes including service dependency investigations.

I am putting this through it's paces now but early results are VERY good!

Try to keep it under 1k tokens or so. We will show you a warning if it might be too big.

Ours is maybe half that size. We remove from it with every model release since smarter models need less hand-holding.

You can also break up your CLAUDE.md into smaller files, link CLAUDE.mds, or lazy load them only when Claude works in nested dirs.

https://code.claude.com/docs/en/memory

Add it to your CLAUDE.md. Claude will automatically read that file every time it starts up

I’m old enough to remember being able to work at programming related tasks without any such tools. Is that not still a thing?

Good question. Why hasn't there been a profusion of new game-changing software, fixes to long-standing issues in open-source software, any nontrivial shipped product at all? Heck, why isn't there a cornucopia of new apps, even trivial ones? Where is all the shovelware [0]? Previous HN discussion here [1].

Don't get me wrong, AI is at least as game-changing for programming as StackOverflow and Google were back in the day. I use it every day, and it's saved me hours of work for certain specific tasks [2]. But it's simply not a massive 10x force multiplier that some might lead you to believe.

I'll start believing when maintainers of complex, actively developed, and widely used open-source projects (e.g. ffmpeg, curl, openssh, sqlite) start raving about a massive uptick in positive contributions, pointing to a concrete influx of high-quality AI-assisted commits.

[0] https://news.ycombinator.com/item?id=45511128

I use GitHub Copilot in Intellij with Claude Sonnet and the plan mode to implement complete features without me having to code anything.

I see it as a competent software developer but one that doesn't know the code base.

I will break down the tasks to the same size as if I was implementing it. But instead of doing it myself, I roughly describe the task on a technical level (and add relevant classes to the context) and it will ask me clarifying questions. After 2-3 rounds the plan usually looks good and I let it implement the task.

This method works exceptionally well and usually I don't have to change anything.

For me this method allows me to focus on the architecture and overall structure and delegate the plumbing to Copilot.

It is usually faster than if I had to implement it and the code is of good quality.

The game changer for me was plan mode. Before it, with agent mode it was hit or miss because it forced me to one shot the prompt or get inaccurate results.

I know of many experienced and capable engineers working on complex stuff who are driving basically all their development through agents. This includes production level work. This is the norm now in the SV startup world at least.

You don't just YOLO it. You do extensive planning when features are complex, and you review output carefully.

The thing is, if the agent isn't getting it to the point where you feel like you might need to drop down and edit manually, agents are now good enough to do those same "manual edits" with nearly 100% reliability if you are specific enough about what you want to do. Instead of "build me x, y, z", you can tell it to rename variables, restructure functions, write specific tests, move files around, and so on.

So the question isn't so much whether to use an agent or edit code manually—it's what level of detail you work at with the agent. There are still times where it's easier to do things manually, but you never really need to.

Here's one - https://apps.apple.com/us/app/pistepal/id6754510927

The app is definitely still a bit rough around the edges but it was developed in breakneck speed over the last few months - I've probably seen an overall 5x acceleration over pre-agentic development speed.

I use Junie to get tasks done all the time. For instance I had two navigation bars in an application which had different styling and I told it make the second one look like the first and... it made a really nice patch. Also if I don't understand how to use some open source dependency I check the project out and ask Junie questions about it like "How do I do X?" or "How does setting prop Y have the effect of Z?" and frequently I get the right answer right away. Sometimes I describe a bug in my code and ask if it can figure it out and often it does, ask for a fix and often get great results.

I have a React application where the testing situation is FUBAR, we are stuck on an old version of React where tests like enzyme that really run react are unworkable because the test framework can never know that React is done rendering -- working with Junie I developed a style of true unit tests for class components (still got 'em) that tests tricky methods in isolation. I have a test file which is well documented explaining the situation around tests and ask "Can we make some tests for A like the tests in B.test.js, how would you do that?" and if I like the plan I say "make it so!" and it does... frankly I would not be writing tests if I didn't have that help. It would also be possible to mock useState() and company and might do that someday... It doesn't bother me so much that the tests are too tightly coupled because I can tell Junie to fix or replace the tests if I run into trouble.

For me the key things are: (1) understanding from a project management perspective how to cut out little tasks and questions, (2) understanding enough coding to know if it is on the right track (my non-technical boss has tried vibe coding and gets nowhere), (3) accepting that it works sometimes and sometimes it doesn't, and (4) recognizing context poisoning -- sometimes you ask it to do something and it gets it 95% right and you can tell it to fix the last bit and it is golden, other times it argues or goes in circles or introduces bugs faster than it fixes them and as quickly as you can you recognize that is going on and start a new session and mix up your approach.

The Claude MD is like the documentation you hand to a new engineer on your team that explains details about your code that they wouldn't otherwise know. It's not bad to need one.

You might be misunderstanding what a CLAUDE.md is. It’s not about fighting the model, rather it’s giving the model a shortcut to get the context it needs to do its work. You don’t have to have one. Ours is 100% written by Claude itself.

Claude Code does not support AGENTS.md, you can symlink it to CLAUDE.md to workaround it. Anthropic: pls support!

Use AGENTS.md for everything, then put a single line in CLAUDE.md:

  @AGENTS.md

/model

Opus 4.5 is significantly better if you can afford it.

They also recently lowered the price for Opus 4.5, so it is only 1.67x the price of Sonnet, instead of 5x for Opus 4.

There's a counterintuitive pricing aspect of Opus-sized LLMs in that they're so much smarter that in some cases, it can solve the problem faster and with much fewer tokens that it can end up being cheaper.

Obviously the Anthropic employee advertising their product wants you to pay as much as possible for it.

Personally, CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR=1 made all my cd problems go away (which were only really in cmake-based projects to begin with).

I know the Playwright MCP server works great. I use it daily.

This seems pretty aggressive considering this is all just personal anecdote.

I update my CLAUDE.md all the time and notice the effects.

Why all the snark?

CLAUDE.md is read on session startup.

If you're continually finding that it's being forgotten, maybe you're not starting fresh sessions often enough.