[guitheengineer]

True, but you can infer the why from what changed for a lot of cases

e.g. - Add types for X, Y Z

if the PR goal is to make types more strict, that message is clear.

I feel like the quality will be worse than if the engineer really put some thought into it, but the problem is, commits are annoying to write.

A lot of people do “wip” or do a worse than average job.

Having a summary of what changed is still better than that.

Edit: if you feed more context about what you’re trying to develop it will probably be able to infer.

[judofyr]

I’d rather have «wip» commit messages, and thus forced to open the diff, than worrying of the message being hallucinated.

I’m totally cool with people using this as an initial draft and then manually tweaking it though.

[isaacremuant]

Commits are annoying to write is in the same space as "variable names are annoying to write".

Communicating intent should be trivial or, if it's not, put effort into it because communication with that future dev may be essential .

Now, maybe some bullet points may suffice and quickly be reshaped by AI to make it more succinct and clear but you still should make the effort. The more you do it, the more it becomes an easy part.

The problem is when you copy and paste the same info in slightly different ways in many places and I can appreciate some form of suggestion around "you missed explaining why you want to change this part".

There's a space for AIb but it isn't "so that I don't need to think".