I think I'm with the majority of commenters here in thinking this would just wind up being clutter. Markdown might now generate code, but it isn't user facing and doesn't get shipped (I don't want to install a library and have a tonne of prompt text unnecessarily downloaded). I also don't really want to be on the hook for maintaining my co-workers past prompts etc.
For people who like this idea, or do something similar, how do you make use of prompts used to create code checked into your codebase?
I can see it valuable at the review stage, but if I was trying to trace-back a regression to a previous commit, I feel like I already have enough noise without this attached.
Prompts and LLM conversations have now become an important software artifact. I don't think the question should be whether or not to save them. They should be saved. The question is how to structure them in your folders and whether or not they should be part of the context for the LLM.
Our approach is to save LLM conversations but to not have them be part of the context.
I guess that gets to my question a little more - I can see them being helpful for reviewing. Do you go back to them after the review?
I work in data and machine learning, it's pretty common to attach artifacts like charts, images, data outputs to a PR for me, but not include them in the codebase.
I'd only want to do that if it was going to be useful at some future point - do you go back to chats / transcripts etc months after a PR is merged to understand its design? (that sounds rhetorical, but I promise it's a genuine question!)
benrutter · · focus · HN ↗
For people who like this idea, or do something similar, how do you make use of prompts used to create code checked into your codebase?
I can see it valuable at the review stage, but if I was trying to trace-back a regression to a previous commit, I feel like I already have enough noise without this attached.
intrasight · · focus · HN ↗
Our approach is to save LLM conversations but to not have them be part of the context.
xg15 · · focus · HN ↗
intrasight · · focus · HN ↗
Much of the knowledge of writing the software is manifest and captured in those chats. and we share them so that we can learn from each other.
benrutter · · focus · HN ↗
I work in data and machine learning, it's pretty common to attach artifacts like charts, images, data outputs to a PR for me, but not include them in the codebase.
I'd only want to do that if it was going to be useful at some future point - do you go back to chats / transcripts etc months after a PR is merged to understand its design? (that sounds rhetorical, but I promise it's a genuine question!)
boomlinde · · focus · HN ↗
Why don't your chatbots just write clear, well documented code?
boomlinde · · focus · HN ↗
aDyslecticCrow · · focus · HN ↗
have they though? I feel like 50% of the chat history is gettin in the way of the model that just created it half the time, let alone any future LLM.
Humans wont re-read an old chat history either unless very desperate for clues.
The few valuable nuggets of information in the chat history can probably be summarize into 3 bullet points and put in the docs or in code comments.
I really dont see the value.
cindyllm · · focus · HN ↗
[dead]
akazantsev · · focus · HN ↗
Any prompt-storing/sharing ideas floating around hit the same wall - they assume the text will be in English. It won't.