I still manually edit almost every word for utmost precision in anything I expect a human to read since LLM prose is hard to read and often subtly wrong or misleadingly worded (those false contrasts ...).
Commit messages are not exactly in this category for me, I view them mostly as a work log to be later inspected by another LLM to gather context. I do usually review them before approving a given plan, so I do care about their structure and content, but find the LLM sufficiently competent at writing them.
For me, the use-case of commit messages is to help a human discover when some kind of thing might have changed, as distinct from the commits before and after it. Importantly, the human is doing a subjective scan for something that sounds relevant.
If they already knew what function or detail is involved, they would be already be doing a "all commits that touched this line" filter, and my comment about affecting $thing would probably be superfluous.
I also don't need to tell them such details in the commit, because that is better expressed by the actual diff.
So in a sense, I'm trying to provide good keywords, about transactions, errors, logging, button color, whatever.
Commit messages are not exactly in this category for me, I view them mostly as a work log to be later inspected by another LLM to gather context. I do usually review them before approving a given plan, so I do care about their structure and content, but find the LLM sufficiently competent at writing them.