I don't know why you got downvoted, but I find myself wanting to say some version of what you just said over and over again. People write extremely lazy, straightforward prompts and expect the LLM's intelligence to take care of all of it. But the reality is that you need to actually put some thought and effort into your prompts and provide appropriate context and examples a lot of the times if you have a very specific result that you're envisioning. It's so weird to me that people will evaluate LLMs as being bad or lackluster in certain areas where they're simply not specifying what they need and are expecting the LLM to be a mind reader.
I'm not saying that the GP is necessarily doing this. But having repeatedly had plenty of success myself in getting LLMs to write things the way that I want, with a little bit of prompting, it seems likely
There's centralized tooling for the PR descriptions, but I have some local flows where I try to provide more careful prompting and examples to get it to write better. It definitely helps but it's still not great and I'm often unsure if all the extra prompting is worth the effort.
> you need to actually put some thought and effort into your prompts and provide appropriate context and examples a lot of the times if you have a very specific result that you're envisioning.
Ain't gonna happen. By that point in time, I might as well do it myself. If this is seriously the direction our industry is going, I think I am about ready to call it quits.
It seems to me that you might as well put that thought and effort into describing the changes yourself. Most of my changes warrant 0-2 sentences of description below the header. A few particularly subtle bug fixes may need more to make sense of, but detailed descriptions of why certain mitigations are necessary are in my case more likely to end up as code comments.
That describing a change should frequently be such a difficult problem that instead of just doing it you prefer to put thought and effort into telling an LLM to do it smells bad to me. For me, the thought and effort spent writing a description is mostly already amortized through thinking clearly about the problem and performing the work. I have a much easier time describing what I just did and why than a machine that has no access to that information unless I tell it.