kcxt2d ago

if you're using AI regularly to generate text/presentations that you intend to use persuasively i don't think i can trust a single thing you say. Where does the AI end and the human begin?

I think this is why im so against AI generated commit messages especially if the code was written by a human, you wrote the code so you should be able to demonstrate that you understand what the change does and why.

If you're deferring that to an AI and you made a subtle logic error that it decides to justify for you suddenly we have obfuscated our own fucking zero days. Good luck finding the bug if the commit message describes the error as if it was intentional.

For general text, if you start with the conclusion and let the AI write the justification then there is no justification!!! Details matter, having a paper trail for decision making matters.

I wonder how many executives will escape the consequences of their white collar crimes by blaming AI.

AI zombification is coming and it's going to create a distinct difference in communication styles between those who do and don't use it, honestly that point is already here.

And we're gonna find out yet again that marx was right when it becomes clear that AI usage correlates with class lines.

Show threadsbysb1d ago

@cas I agree completely regarding things you are intending for communication. That being said, my line for 'communication' in a shared repository is at the PR level. I would much rather have extremely accurate and over documented commit messages made by AI paired with an 'artisanal' human written message for **why** the change needs to happen, and what they where thinking when they made the change.

I feel like I am only really reading commit messages to figure out why a bug happened, and having very thorough (honestly usually too thorough) commit messages is nice.

Show threadkcxt1d ago
@sbysb having a "---" line break at the end of the commit message followed by some AI generated description would be less harmful, it also has the bonus that it gets removed if you export it with git format-patch and apply it with "git am", so could be removed easily from being committed permanently to the repo while still being easily found in MRs or mailing lists
Show threadsbysb1d ago

@cas I think for most of the git as a service websites that would mean you still would end up with a timeline of 'fix' 'fix 2' 'linting' 'fix again' with the description of what actually changed hidden. The value of my commit messages is already about zero as it stands if I am writing them, mostly because I can't stand writing commit messages.

A lot of this comes down to how you use git - I might have 30 commit messages in a PR, because I commit and push religiously on basically any change. In my experience Claude is 100% correct when writing a commit message for these small changes so the average value of a commit message on my projects has skyrocketed.

On the flip side I have played around with having Claude create the PR itself and am frequently disappointed in how it describes the change. I think what you are describing is actually essentially how it works in my flow: I hand write the PR title and description, and if you wanna look at a summary of what was done specifically there is a whole timeline of very detailed commit messages

Show threadkcxt

@sbysb yeah idk, i generally subscribe to the kernel/uboot workflow where you prepare patches carefully and actually have to write good commit messages. I make heavy use of git absorb and manual commit --fixup to make improvements to a patch series so it encompasses sensible changes from the context of the codebase rather than representing a timeline of changes from the context of the developer (which generally has a lot of unnecessary context and is missing more important context) overall making code harder to understand

thats the mindset from where im speaking anyway, if you don't care about the quality of individual commits in the same way then whether they're human or AI written becomes quite a different question

Mar 28 at 7:50pmWeb
Show threadHoshino Lina (ζ˜ŸδΉƒγƒͺγƒŠ) 🩡 3D Yuri Wedding 2026!!!1d ago

@cas @sbysb Those two flows are not incompatible. You can have sensible commit messages describing individual logical changes, and a PR describing a group of related changes. It's exactly the same as the cover letter model.

If your commit messages are essentially worthless and you rely on the PR description to actually describe what is going on, then the solution is to hit the "squash" button instead of the "merge" button and promote the PR description to a single commit message.

I think that once you're collaborating with others, a messy commit history has negative value. The tiny commits are useful ephemerally during development, but not as a historical record. It's better to have larger commits with good documentation than it is to have meandering small commits which hardly make sense on their own. Just squash. That's also very important because PR descriptions are often lost. You don't want important information about code history to exist only in the forge database.

Squashing also makes rebasing and pulling patches out easier, especially if the development process involved trying and redoing things to any extent. Having commits that revert portions of each other in the history is actively harmful in this case. Essentially, if your PR model involves reviewing the "global changes" view, you want to squash. If you review individual commits, you don't.

Show threadHoshino Lina (ζ˜ŸδΉƒγƒͺγƒŠ) 🩡 3D Yuri Wedding 2026!!!1d ago

@cas @sbysb And both models can coexist in a single project. Usually what you see is more experienced contributors doing the careful commits thing as part of a complex change, and less experienced contributors sending in simple changes with revisions tacked on as extra commits. As a maintainer it's very easy to see what you're dealing with and choose the right approach to review the PR and whether to hit the merge/rebase or squash button.

You don't need to force people into either model (if you don't insist on archaic submission processes like uboot and the kernel do). Forges make it easy to handle both.