Hacker News Reader

Hacker News

Comment by marckrn | Hacker News Reader

Full thread

marckrn

You can find the revamped prompt on github[1], or on twitter summarized by my bot[2].

[1] https://github.com/marckrenn/cc-mvp-prompts/compare/v1.0.128...

[2] https://x.com/CCpromptChanges/status/1972709093874757976

View on HN

> IMPORTANT: DO NOT ADD *ANY** COMMENTS unless asked*

Interesting. This was in the old 1.x prompt, removed for 2.0. But CC would pretty much always add comments in 1.x, something I would never request, and would often have to tell it to stop doing (and it would still do it sometimes even after being told to stop).

I can't decide if I like this change or not, tbh. I almost always delete the comments Claude adds, to be sure - but at the same time they seem to provide a sort of utility for me as I read through the generated code. They also act, in a funny way, as a kind of checklist as I review changes - I want them all cleaned up (or maybe edited and left in place) before I PR.

Wouldn't it stand to reason that they would provide a sort of utility for a collegue as they read through the generated code.

comments for me are a code smell:

- like all documentation, they are prone to code rot (going out of date)

- ideally code should be obvious; if you need a comment to explain it, perhaps it's not as simple as it could be, or perhaps we're doing something hacky that we shouldn't

Comments are often the best tool for explaining why a bit of code is formulated how it is, or explaining why a more obvious alternate implementation is a dead end.

An example of this: assume you live in a world where the formula for the circumference of a circle has not been derived. You end up deriving the formula yourself and write a function which returns 2piradius. This is as simple as it gets, not hacky at all, and you would /definitely/ want to include a comment explaining how you arrived at your weird and arbitrary-looking "3.1415" constant.

I like to think of models leaving "useless comments" as a way to externalize their reasoning process - maybe they are useless at the end, but leaving them in on a feature branch seems to marginally improve future work (even across conversations). I currently leave them in and either manually clean them up myself before putting up a PR for my team to review or run a final step with some instructions like "review the diff, remove any useless comments". Funnily enough Claude seems pretty competent at identifying and cleaning up useless comments after the fact, which I feel like sort of proves my hypothesis.

I've considered just leaving the comments in, considering maybe they provide some value to future LLMs working in the codebase, but the extra human overhead in dealing with them doesn't seem worth it.

I've been wondering if the "you're absolutely right!" thing is also similar. Like maybe it helps align Claude with the user or something, less likely to stray off or outright refuse a task.

I am guessing this is an attempt to save computing resources/tokens?

Comments in code are instant technical debt. They need to be maintained alongside the code, so you are *programming" twice. Avoid comments, except when they really explain some obscure, incomprehensible section of code or to prevent explorers from the future getting smacked on the face twice by the same stick. I find myself using the latter often to tell future agents what not to do in the next few lines.

imo, comments are quite good for junior developers. docstrings are much preferred though.

Avoiding comments is an exercise in thinking how to rename or refactor a function, or a variable in such a way that a junior developer will be able to read it like prose, and immediately understand what's going on.

It's cognitively stressing, but is beneficial for juniors, and developers new to the codebase, just as it is for senior developers to reduce the mental overhead for the reader.

It's always good to spend an extra minute thinking how to avoid a comment.

Of course there are exceptions, but the mental exercise trying to avoid having that exception is always worth it.

Comments are instant technical debt.

Especially junior developers will be extremely confused and slowed down by having to read both, the comment, and then the code, which was refactored in the meantime and does the opposite of what the comment said.

This is awfully purist.

I think a happy medium of "comment brevity, and try thinking of a clearer way to do something instead of documenting the potentially unnecessary complexity with a comment" would be good.

I don't know where this "comments are instant technical debt" meme came from, because it's frankly fucking stupid, especially in the age of being able to ask the LLM "please find any out-of-date comments in this code and update them" since even the AI-averse would probably not object to it commenting code more correctly than the human did

Not commenting code seems like the most unhinged thing I can think of. We don't need blueprints to build this building gestures broadly isn't it obvious to the construction workers where to put everything?

The blueprint is the code.

I don't know, I tend to agree. I feel like the number of times I've been thrown off by an out of date comment for code that could have probably been refactored to be clearer, outweigh the times a comment has helped.

Docstring comments are even worse, because it's so easy for someone to update the function and not the docstring, and it's very easy to miss in PR review

As always the problem isn't the actual thing being discussed - the problem is shitty developers who wrote shitty comments and/or don't update comments when they update code.

Good and up to date comments are good and up to date. Bad and outdated comments are bad and outdated. If you let your codebase rot then it rots. If you don't then it doesn't. It's not the comment's fault you didnt update it. It's yours.

It's always a skill issue.

Guard rails should be there to prevent inexperienced developers (or overworked, tired ones) from committing bad code.

"Try to think how to refactor functions into smaller ones and give them meaningful names so that everyone knows immediately what's going on" is a good enough guard rail.

> "comment brevity, and try thinking of a clearer way to do something instead of documenting the potentially unnecessary complexity with a comment"

That's exactly what I wrote, phrased slightly differently.

We both agree at the core.

This is why, when you do have comments, they should generally be in the DocBlock and discuss the code in domain-problem terms.

I bet you that if you let it comment code, it would produce better code as it acts like an inline rubber-duck basically

I recall a study that said AI coded much better when in codebases with dense commenting.

I'm wondering if tsdoc/jsdoc tags like @link would help even more for context

Comments are absolutely important. Your code answers ‘what’ but not why. Comments are for the why.

Thoughtful comments can provide the why, but they can just as easily be a redundant re-statement of the what in the code, which llm comments quite often are.

Most Claude Code comments answer the "what", or worse they answer the why in a way that makes no sense outside the context of that session. Stuff like adding a comment saying why they removed our changed code that they'd just written

You need to use comments, when your code doesn't make sense to the reader. A way better approach is to write code which makes sense to readers. There are cases when you need to write incomprehensible code for the sake of performance, for example, but that's rare. Even in high performance environments. Or maybe you need one for some bugfixing. But most of the strange "bugfixing", or performance "improvements" what I saw in my life was just technical debt, and coders were lazy, or had time pressure. It's really very rare when you really should use a comment. When I think about writing a comment, I immediately think through, or look into more whether there is a better approach. Usually, you can use Git, or Git+ticketing systems anyway for business reasons.

So far Clause Code's comments on my code were completely useless. They just repeated what you could figure out from the name of called functions anyway.

Edit: an obvious exception is public libraries to document public interfaces, and use something like JavaDoc, or docstrings, etc.

Comments describing the program are a form of error correcting code. Redundancy vs efficiency yadda yadda, just make an informed decision instead of a half baked belief; programming more than once is the point, necessarily. (And I don’t mean ‘// add 2 to x’ comments, these are properly useless, I agree - unless they say why x needs to have 2 added.)

Meanwhile they deleted the "do not add emojis" part. Look forward to all sorts of logging messages with emojis in them.

I don’t understand where the AI love of emojis comes from. I’ve never seen them in a professional codebase outside of basic logging.

I assume it comes from the myriad tutorial content on medium or something.

gpt-oss is the most egregious emoji user: it uses emoji for numbers in section headings in code, which was clearly a stylistic choice finetuned into the model and it fights you on removing them.

I’ve noticed Claude likes to add them to log messages and prints and with 4.5 seems to have ramped up their use in chat.

It's bizarre because its not so long ago that trying to print an emoji would just mess up your terminal, if your compiler didn't already choke on it.

I'm pretty sure it's caused by RLHF :wink:

This is excellent. Thanks for sharing this.

You're very welcome – that really means a lot coming from you, Simon.

Thanks. When testing today I noticed it 'forgot' to run the linter, build, test etc. commands. I thought this might've been a Sonnet 4.5 v.s. Opus 4 issue but it looks like this instruction was dropped for some reason.

I should probably include that in my Claude.md instead I guess?

> 2025-09-29T16:55:10.367Z is the date. Write a haiku about it.

what in the world?

That's just a dynamic bogus prompt used to trace and extract the system prompt.

Here's how it works in detail: https://mariozechner.at/posts/2025-08-03-cchistory/

How are you extracting this - aren’t the main labs obfuscating these (meaning it’s likely to be a decoy or incomplete version)?

With cchistory https://github.com/badlogic/cchistory

Here's how it works: https://mariozechner.at/posts/2025-08-03-cchistory/

Great writeup, thanks.

Are you running the bot with the free tier api?

I'm using Anthropic's pay-as-you-go API, since it was easier to set up on the server than CC's CLI/web login method. Running the bot costs me ~$1.8 per month.

The bot is based on Mario Zechner's excellent work[1] - so all credit goes to him!

[1] https://mariozechner.at/posts/2025-08-03-cchistory/

I think amrrs is referring to the x.com API.

Oh, I'm sorry. Yes, I'm using x's free tier.

Can anyone find the prompts for the new "Output style" options, ie Explanatory and Learning?

How are these reliably extracted (hint: they’re not)

See https://mariozechner.at/posts/2025-08-03-cchistory/

Why do you think these aren't legit?

It's very easy to extract the system prompt from Claude Code: you can patch it to intercept HTTP calls it makes.

I wrote about one tool for doing that here: https://simonwillison.net/2025/Jun/2/claude-trace/

Reply on news.ycombinator.com