Hacker News Reader

Comment by bhelx | Hacker News Reader

This speaks to the general problem with using LLMs for writing. The audience they are writing for us you, but you're trying to write for a totally different audience. In code, this manifests as comments in the code that are hyperspecific to the conversation you are having, and not the long term benefit of having those comments in the code.

I see this in docs a lot. I've been reading a lot of docs these days where it feels like the LLM is trying to hype up the person writing the docs. It's like it has no conception that the writing is meant for a 3rd party audience.

View on HN

It reminds me of something I've always wanted as a coder but never cared enough to implement, which would be a verbosity switch.

I see the full multi-paragraph comments in my codebases and get annoyed but also feel like the additional context helps improve the llm results over time because that history helps it know what's been tried and removed in the past. It's additional context for the system that improves with context.

The feature I want in the code tool itself (for me) is to adjust how verbose the comments are so I can read "just code", then "terse comments" then "full comments" then "full comments with historical context" (including fit commits and ticket references) and finally, full-on literate programming. And I'd like to switch between on the fly as I read through the code.

I think this is something we could actually produce with llms, and I feel the ability to switch between these modes would help the llm as well.

Sometimes I just need to see what's being done. Sometimes I need to know why. Sometimes I need to know what's been tried. Never always all of these things. And expecting to find this context in git comments doesn't feel right either.

What you want can be accomplished with an extra doc, call it the Log, where the llm appends things tried, lessons learned, failed experiments etc.. while leaving the comments as terse accurate snapshot of the current state. I've been using this log pattern and it works well.

Despite all of this though, GPT 5.6 Sol to me has significantly less trouble with this. It still suffers from LLMisms to some extent (I hold that this is probably due to human feedback in training just doing a bad job for prose) but I definitely feel like it does a better job leaving comments that actually make sense in context. Not perfect. But better.

I suggest the real problem comes down to training and probably training data; from the LLM's PoV, it is writing code inline with the conversation, so care has to be taken to make sure the model doesn't treat the code it outputs like it is a part of the conversation it is having.

>It's like it has no conception

This is the point.

It's an empty point and a boring one and leads nowhere. It means nothing, but sounds deep. It's so shallow, any taxi driver and sociologist can come up with it and has, already in December 2022.

>It's an empty point and a boring one and leads nowhere.

But, is it true?

>It means nothing...shallow...

Ironically, the entirety of your comment just repeats that the GP comment means nothing. There is no further explanation or "depth".

Yours added no depth either.

Yes. Though adding something like what you wrote here into the instructions does help. Especially combined with a fresh session.

I don’t even think comments are useful at all given AI. I can ask my AI to explain a piece of code if I am stuck and I will get a reply in context of what I am looking for.

But comments should hopefully explain "why", not what or how, and that kind of context is exactly what an LLM is likely to be missing

Yes, but some of that is actually better placed in the git commit messages. But of course not all.

Reply on news.ycombinator.com