This would sound insane to me from two years ago but I have recently started insisting on writing all my own commit messages and pull request descriptions. I do usually have an agent review them for factual accuracy, but not rephrase them.
It slows things down a bit, but in the best possible way. It has helped immensely to improve the depth of my understanding of the agent-generated code. When agents are doing everything its way too easy to “skim” diffs and not really absorb them.
I always prided myself on my technical writing, and commit messages and PRs were a great place to hone that skill. I found that I missed it and my work is better now I’ve reclaimed that part of my old job back.
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.
semiquaver · · focus · HN ↗
It slows things down a bit, but in the best possible way. It has helped immensely to improve the depth of my understanding of the agent-generated code. When agents are doing everything its way too easy to “skim” diffs and not really absorb them.
I always prided myself on my technical writing, and commit messages and PRs were a great place to hone that skill. I found that I missed it and my work is better now I’ve reclaimed that part of my old job back.
solarkraft · · focus · HN ↗
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.
Terr_ · · focus · HN ↗
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.