3 ms·

> why something is there way it is It writes out stories describing what isn't there or what used to be there. It's usually not helpful, just noise. It also li

by rplnt 1mo ago

> why something is there way it is It writes out stories describing what isn't there or what used to be there. It's usually not helpful, just noise. It also likes to write it in very verbose AI-styled prose.

zormino 1mo ago
"don't write a goddamn novel" <- I've said this to claude way too many times, nothing you can do actually seems to make it significantly less verbose
deleted 1mo ago
[deleted]
orwin 1mo ago
And the way they are written is rather unhelpful: '//this not cosmetic: this css helps the user understand where he should click'. The 'this is not' pattern is useless at best.
skeledrew 1mo ago
It's likely not helpful to you, but it is to Claude. Basically a memory entry at the exact point of relevance, with the same caveats. One advantage though is it survives cloning, so another using the project benefits.
- rplnt 1mo ago
  It's only helpful to Claude in that it wastes more tokens and costs more.
  - skeledrew 1mo ago
    It does visibly use a few more tokens in the short term. But it hurts Claude's ability in the long term if removed because it has to either think more every time it encounters that section in the code (more invisible thinking tokens used), or there's an increased risk of making a maladaptive change without context. Heck I've been bitten enough times already by it, though more recently it's cross project concern where Claude rediscovers some root cause that was already found and documented (I have it save a centrally-located writeup for things that took serious work to learn, when I remember, but I still need to make that knowledge pool known to other agents/sessions without having to manually prompt each time) elsewhere. Problem is today's LLMs don't have the long term memory that humans have, and so remembering the reason behind a given change/decision has to be preserved in some way if it's non-obvious. Hence why there is {AGENTS|CLAUDE}.md, the auto-memory system, and 1001 variants of memory implementations in the wild. All are trying to ensure that LLMs can have the context they need at the location and time they need it. And you want to block Claude from using a technique that it natively finds helpful.
    - fooster 1mo ago
      No it doesn’t. The comments are hugely verbose trash that immediately becomes outdated and brittle and confusing for humans and Claude alike.
      - skeledrew 1mo ago
        If that were the case, the habit would have been trained out of it by the LLM researchers at Anthropic, etc. As for humans... well Idk about you but I'm not reading every line of generated code. I read the live transcript, and only dive in if something is off that the agent isn't resolving.
        fooster 1mo ago
        I'm certainly reading the code and comments, and I encourage all of my team members to do so. You are assuming that this excessive and nonsensnical comment choice is deliberate. It cannot be, or should not be because it regularly confused our team, and it regularly confuses claude also. Also many many people keep saying the same thing and you keep repeating adnausium the same tired comments. I get it, you think the comments are great and are valuable. Read the entire thread https://news.ycombinator.com/item?id=49393378 https://news.ycombinator.com/item?id=49393378 The concensus in this thread is that for multiple reasons the excessive comments are in fact actively harmful. The listed reasons are: 1. Document the conversation, not the code — narrate the back-and-forth that produced the change rather than what the code does 2. Reference intermediate states that never shipped ("previously X, now Y") 3. Cite plan documents and session artifacts (`per section 2.1 of addition-implementation-plan.md`) meaningless to a future reader 4. Belong in commit messages or PR comments, not source files 5. Go stale immediately — describe a state the code is no longer in 6. Launder incorrect code as intentional, making bugs harder to spot 7. Build a false Chesterton's fence around mistakes 8. Use defensive prose ("this is not cosmetic", "prevents the critical bug that shipped once") that asserts importance instead of conveying information 9. Describe what the code doesn't do — relevant in the moment, not in the codebase 10. Confuse later agent sessions, sending them to read irrelevant files 11. Consume context tokens on every read 12. Force reviewers to manually delete the litter 13. Resist correction — telling Claude to be concise doesn't durably stick Please consider that your opinion may need to adjusted.
- 0x457 1mo ago
  It's often is not helpful to claude either because it just confuses it more most of the time.
  - skeledrew 1mo ago
    Confusion usually surfaces immediately, so it can be steered properly. Being sure of a decision that turns out to be wrong usually means a bug that could bite when you least expect it.
    - iammrpayments 1mo ago
      No it doesn’t. The comments end up complicating simple tasks, and if you open the repo after a week it takes a while to find out why Claude is reading irrelevant files or replying about irrelevant things
      - skeledrew 1mo ago
        If that happens you do notice that something is off though, and can steer accordingly. Unless you aren't monitoring the agent, which I suspect is the real issue here; people send a prompt, go do whatever else, return and send the next prompt or use/release the artifact, without reviewing the transcript to see how Claude - or whatever agent - did.
        0x457 1mo ago
        I don't notice it because, agent running in full-auto until there is a PR to review or decisions to make. If I wanted to go step-by-step, I'd write code myself with LLM auto-complete. I only leave meta-comments in if its actually helpful (i.e. it goes in a wrong direction without it)
        skeledrew 1mo ago
        I run Claude Code in auto-mode (or bypass when sandboxed) and still am able to monitor the transcript because - possibly by design - it works slowly enough that I can keep up and usually steer; there's no going "step-by-step". In contrast, whenever I use DeepSeek Flash, it goes so fast that I'm unable to keep up, so I primarily prompt it via Claude and also have a separate review in a fresh session, usually also by a Claude.

by rplnt 1mo ago

zormino 1mo ago

"don't write a goddamn novel" <- I've said this to claude way too many times, nothing you can do actually seems to make it significantly less verbose

deleted 1mo ago

[deleted]

orwin 1mo ago

And the way they are written is rather unhelpful: '//this not cosmetic: this css helps the user understand where he should click'. The 'this is not' pattern is useless at best.

skeledrew 1mo ago

It's likely not helpful to you, but it is to Claude. Basically a memory entry at the exact point of relevance, with the same caveats. One advantage though is it survives cloning, so another using the project benefits.

rplnt 1mo ago
It's only helpful to Claude in that it wastes more tokens and costs more.
- skeledrew 1mo ago
  It does visibly use a few more tokens in the short term. But it hurts Claude's ability in the long term if removed because it has to either think more every time it encounters that section in the code (more invisible thinking tokens used), or there's an increased risk of making a maladaptive change without context. Heck I've been bitten enough times already by it, though more recently it's cross project concern where Claude rediscovers some root cause that was already found and documented (I have it save a centrally-located writeup for things that took serious work to learn, when I remember, but I still need to make that knowledge pool known to other agents/sessions without having to manually prompt each time) elsewhere. Problem is today's LLMs don't have the long term memory that humans have, and so remembering the reason behind a given change/decision has to be preserved in some way if it's non-obvious. Hence why there is {AGENTS|CLAUDE}.md, the auto-memory system, and 1001 variants of memory implementations in the wild. All are trying to ensure that LLMs can have the context they need at the location and time they need it. And you want to block Claude from using a technique that it natively finds helpful.
  - fooster 1mo ago
    No it doesn’t. The comments are hugely verbose trash that immediately becomes outdated and brittle and confusing for humans and Claude alike.
    - skeledrew 1mo ago
      If that were the case, the habit would have been trained out of it by the LLM researchers at Anthropic, etc. As for humans... well Idk about you but I'm not reading every line of generated code. I read the live transcript, and only dive in if something is off that the agent isn't resolving.
      - fooster 1mo ago
        I'm certainly reading the code and comments, and I encourage all of my team members to do so. You are assuming that this excessive and nonsensnical comment choice is deliberate. It cannot be, or should not be because it regularly confused our team, and it regularly confuses claude also. Also many many people keep saying the same thing and you keep repeating adnausium the same tired comments. I get it, you think the comments are great and are valuable. Read the entire thread https://news.ycombinator.com/item?id=49393378 https://news.ycombinator.com/item?id=49393378 The concensus in this thread is that for multiple reasons the excessive comments are in fact actively harmful. The listed reasons are: 1. Document the conversation, not the code — narrate the back-and-forth that produced the change rather than what the code does 2. Reference intermediate states that never shipped ("previously X, now Y") 3. Cite plan documents and session artifacts (`per section 2.1 of addition-implementation-plan.md`) meaningless to a future reader 4. Belong in commit messages or PR comments, not source files 5. Go stale immediately — describe a state the code is no longer in 6. Launder incorrect code as intentional, making bugs harder to spot 7. Build a false Chesterton's fence around mistakes 8. Use defensive prose ("this is not cosmetic", "prevents the critical bug that shipped once") that asserts importance instead of conveying information 9. Describe what the code doesn't do — relevant in the moment, not in the codebase 10. Confuse later agent sessions, sending them to read irrelevant files 11. Consume context tokens on every read 12. Force reviewers to manually delete the litter 13. Resist correction — telling Claude to be concise doesn't durably stick Please consider that your opinion may need to adjusted.
0x457 1mo ago
It's often is not helpful to claude either because it just confuses it more most of the time.
- skeledrew 1mo ago
  Confusion usually surfaces immediately, so it can be steered properly. Being sure of a decision that turns out to be wrong usually means a bug that could bite when you least expect it.
  - iammrpayments 1mo ago
    No it doesn’t. The comments end up complicating simple tasks, and if you open the repo after a week it takes a while to find out why Claude is reading irrelevant files or replying about irrelevant things
    - skeledrew 1mo ago
      If that happens you do notice that something is off though, and can steer accordingly. Unless you aren't monitoring the agent, which I suspect is the real issue here; people send a prompt, go do whatever else, return and send the next prompt or use/release the artifact, without reviewing the transcript to see how Claude - or whatever agent - did.
      - 0x457 1mo ago
        I don't notice it because, agent running in full-auto until there is a PR to review or decisions to make. If I wanted to go step-by-step, I'd write code myself with LLM auto-complete. I only leave meta-comments in if its actually helpful (i.e. it goes in a wrong direction without it)
        skeledrew 1mo ago
        I run Claude Code in auto-mode (or bypass when sandboxed) and still am able to monitor the transcript because - possibly by design - it works slowly enough that I can keep up and usually steer; there's no going "step-by-step". In contrast, whenever I use DeepSeek Flash, it goes so fast that I'm unable to keep up, so I primarily prompt it via Claude and also have a separate review in a fresh session, usually also by a Claude.