151–160 of 410 posts
For my work as one of developers in team, no. The way I prompt is my asset and advantage over others in a team who always complain about AI not being able to provide correct solutions and secures my career
That context could clarify the problem, why the solution was chosen, key assumptions, potential risks, and future work.
I floated that idea a week ago: https://news.ycombinator.com/item?id=47096202 , although I used the word "prompts" which users pointed out was obsolete. "Session" seems better for now. The objections I heard, which seemed solid, are (1) there's no single input to the AI (i.e. no single session or prompt) from which such a project is generated, (2) the back-and-forth between human and AI isn't exactly like working wit…
Conceptually this is very similar to the question of whether or not you should squash your commits. To the point that it's really the same question. If you think you should squash commits, then you're only really interested in the final code change. The history of how the dev got there can go in the bin. If you don't think you should squash commits then you're interested in being able to look back at the journey that…
It's less clear to me if the software isn't crafted by a human at all, though. In that case I would prefer to see the prompt.
Not once have I found it useful: if the intention isn't clear from the code and/or concise docs, the code is bad and needs to be polished.
Well written code written with intention is instantly interpretable with an LLM. Sending the developer or LLM down a rabbit hole of drafts is a waste of cognition and context.
This applies both to future AI tools and also experts, and experts instructing novices.
To some degree, the lack of documenting AI sessions is also at the core of much of the skepticism toward the value of AI coding in general: there are so many claims of successes / failures, but only a vanishingly small amount of actual detailed receipts.
Automating the documentation of some aspects of the sessions (skills + prompts, at least) is something both AI skeptics and proponents ought to be able to agree on.
EDIT: Heck, if you also automate documenting the time spent prompting and waiting for answers and/or code-gen, this would also go a long way to providing really concrete evidence for / against the various claims of productivity gains.
EOM
Conceptually this is very similar to the question of whether or not you should squash your commits. To the point that it's really the same question. If you think you should squash commits, then you're only really interested in the final code change. The history of how the dev got there can go in the bin. If you don't think you should squash commits then you're interested in being able to look back at the journey that…
This only works if the software is still crafted by a human and merely using AI as a tool. In that case the use of AI is similar to using editor macros or test-driven development. I don't need to see that process playing out in real time. It's less clear to me if the software isn't crafted by a human at all, though. In that case I would prefer to see the prompt.