I've started giving these instructions and I think I've been much more successful in generating clear output: Comment blocks are Limiting the number of words is the strongest factor in cleaning up the output, IMO. For older code I've instructed it to delete all the comments, and then I re-comment it using a new session and these guidelines, asking it to rejustify the need for every comment to itself.
Why it should write comments at all? Code is the documentation. I only let it write high level information of why something is the way it is.
This or you just repeat the initial prompt every 200k tokens
Which gets you to the point where the whole thing is.. still unreliable. Generative text engines are going to generate. This calls for real enforcement in deterministic pre-edit hooks. And here is where naive people will say something like "Why do I care if robots shit all over the codebase? Code is for machines, I don't expect to deal with it much now". But really externalized CoT like this confuses machines too, wa…
My take on this is they are a tool to help speed up your work they are not meant to produce finished work. Humans produce finished work. LLM will never be deterministic cause their entire value is that they are generalizable.
I've started giving these instructions and I think I've been much more successful in generating clear output: Comment blocks are Limiting the number of words is the strongest factor in cleaning up the output, IMO. For older code I've instructed it to delete all the comments, and then I re-comment it using a new session and these guidelines, asking it to rejustify the need for every comment to itself.
Claude not only writes verbose comments, it also writes comments about how things used to work when refactoring. That might have a place in version control comments, but not in the code.
We call these temporal comments. We recently updated our code review skills to heavily discourage them. It doesn’t matter why funcA was added then later refactored to funcB. That much can be ascertained from git history. What does matter is why approach A doesn’t work, but B does.
Thanks, this sequence of 33 words alone was enough to give me a searing migraine.
Glad to know it worked. Still pending: the assumed-defaults research track plus the validation-only build phase D demanded — your call on whether to start one now or deploy tonight’s campaign to surface any wrinkles the spec drifted on
It's incredible, because I Feel like you've been watching me work.
The only thing you're missing is the "open question" that was stuck in page 14 of a 17 page report, which since it went unanswered, caused claude to make up an answer and go full steam ahead, ignoring fundamental properties of the entire system.
Has Anthropic said anything about how or why Claude writes the way it does? So many people hate it, seems like they need to do some damage control there. I haven't had the same problems others have but I'm also not a heavy user of it.
Watermarking? It certainly is useful for that. I see Claude-written prose AND I know instantly it's LLM writing. What I do with that knowledge varies.
Honestly, this is the most practical take on prompt engineering I've come across lately. Makes me wonder why spend all that time crafting a 500-word essay to tell Claude to stop being Claude, when the real move is just to chain a couple models together and call it a day
I've started giving these instructions and I think I've been much more successful in generating clear output: Comment blocks are Limiting the number of words is the strongest factor in cleaning up the output, IMO. For older code I've instructed it to delete all the comments, and then I re-comment it using a new session and these guidelines, asking it to rejustify the need for every comment to itself.
Claude not only writes verbose comments, it also writes comments about how things used to work when refactoring. That might have a place in version control comments, but not in the code.
My theory is it writes these comments as "notes while working", and I don't don't mind that, per-se. My problem is it's inability to clean that shit up before committing it. That's wrong load-bearing lever that doesn't earn it's keep.
I pruned my Claude.md and it made a difference. There were entries there that evolved from earlier models and Opus 5 could be reacting to it in a different manner.
I have no Claude.md file. Claude is still absolutely horrible.
If you’re on Claude.ai web, you still have preferences tied to your past interactions. That can be edited.
The problem is, when the context window grows, Claude tends to forget these kinds of rules. It will then do whatever it wants. I had to outright ban comments in the global claude.md, the local claude.md AND write a hook to catch any that still slipped through.
I think people really need to focus more on working with limited contexts rather than trying to work around it. I really try to keep my sessions as short as possible and it helps a ton with keeping Claude (et al) focused. Specifically, I like the "canary" trick that people have discussed where you add a small, innocuous rule to your CLAUDE.md like "When responding to me, start every sentence with my name." so that wh…
I set my env up so I can see the exact context used in CC CLI, and then once I get over about 40% ctx used I have it handoff to a new, fresh session. Nothing good comes from running above, say 60% of your context window. Coincidently, I usually have good results with CC. I never compact a session ever.