[paganel]

> The PR descriptions are more thorough than what I’d write

Why do people do this? Why do they outsource something that is meant to have been written by a human, so that another human can actually understand what that first human wanted to do, so why do people outsource that to AI? It just doesn't make sense.

[ytoawwhra92]

Same reason they outsource writing their blog posts.

This weird notion that the purpose of the thing is the thing itself, not what people get out of the thing. Tracks completely that a person who thinks their number of commits and think that shows how productive they are (while acknowledging that it's a poor metric and just shrugging).

[paulhebert]

Yeah I agree.

We have “Cursor Bot” enabled at work. It reviews our PRs (in addition to a human review)

One thing it does is add a PR summary to the PR description. It’s kind of helpful since it outlines a clear list of what changed in code. But it would be very lacking if it was the full PR description. It doesn’t include anything about _why_ the changes were made, what else was tried, what is coming next, etc.

[neilkakkar]

This is exactly why I use a custom skill - I can tell it what to focus on, I can give it a ill formatted blurb of why I'm making the changes, and it will format it nicely, and add more context based on the changes.

Most of the time, the PR descriptions it generates for me are great.

I think the issue is you're assuming it's always a poor output, which isn't the case. I'm in a much smaller team than you'd expect, so the why is talked about sync more often than not, and it becomes less of an problem.

[godd2]

> Why do they outsource something that is meant to have been written by a human

Says who? The point of the summary is so that I don't have to go look at the diff and figure out what happened.

[piva00]

The point of the summary is also to explain "why" something was done, most Claude-generated PR descriptions I've been seeing go through the "what" and "how" but if the human-in-the-loop didn't care to precisely describe the "why" it is just an English version of the changes made in the code... I can just read the code for that, give me the reasons behind the diff and I'm a happy camper.

[nzach]

If you have a large PR the existence of a good summary on "what" changed can help you to make a better review.

But I agree with you, when reading PR descriptions and code comments I want a "why" not a "what". And that is why I think most LLM-generated documentation is bad.