Why I still hand write my commit messages · Jamie Tanna | Software EngineerWritten by<br>Jamie Tanna<br>on August 17, 2026<br>CC-BY-NC-SA-4.0<br>Apache-2.0<br>6 mins<br>Why I still hand write my commit messages
Table of ContentsFor over a decade, I've been a proponent of writing detailed Git commit messages. I find it a valuable use of my time, and continue to double down on it, even in a world where you can get a Large Language Model (LLM) to write it for you.<br>In the past, I've written about at least 89 strong feelings I have about Git commits, so I'm naturally biased to the benefit of commit messages, but why does this still hold in the current age, where a lot of people are delegating that to an AI agent, if at all?<br>"Why" is better than "what"<br>One of the most important things a commit message should explain is why you're making a given change.<br>Chris Beams' post about writing commit messages is probably one of the more cited blog posts of all time, and is a great resource on this and a number of other important pieces to remember when writing a commit message.<br>Unfortunately a lot of humans, and by extension LLMs, still continue to re-explain what has changed in a given commit. Generally, the "what" is clear, as you can see it in the diff itself. Although not all code is "self-documenting", you can generally see "what" is changed by looking at a commit's diff.<br>If you don't document why you're making the change, you're missing out on really important context.<br>Some other areas I focus on calling out:<br>if this is a prerequisite/prefactor for other changes<br>if this is a bug that this fix is resolving (not only referencing issues/JIRA tickets, but also any examples or error messages of note)<br>whether this has crept in due to a gap in my own review/implementationit's only a blame culture when it's me, otherwise I'll use we - i.e. I'd missed this from $sha
if there were any trade-offs, such as why we're executing an external command, instead of implementing a Typescript-based parser<br>In each of these cases, it helps provide more insight into what led to the change and why we're doing it.<br>Can I explain it?<br>The process of writing the commit message is also greatly helpful in determining whether I do actually understand the changes I've just made.<br>As we heard last week at GopherCon UK, a study in 2014 shows that you are more likely to retain knowledge if you are expected to teach it.<br>By making sure that I need to explain why a given commit's changes are necessary, I can make sure I do actually understand what I'm about to commit, and how I'd explain it in my own words.<br>I'll very often find that - even with changes I've fully authored myself - as I'm going to explain it, I don't necessarily agree with a choice I've made, or now that I've stepped back to review the changes, I can see a better option.<br>I've found this to be a positive experience when writing documentation in the past, too. When you're trying to explain a new feature, or clarify existing functionality, you often need to "take a step back" and rethink how a user who may be unfamiliar with the inner workings of the project will reason about it, and by doing that, you may find that there's a lot of implied understanding you need to break through.<br>When working through my commit messages, I'll watch out for occurrences of Also, ... or Additionally, ... - sometimes they're OK, but it's often a case of a commit that is trying to do too much, which requires breaking down the changes into multiple commits.<br>I'm the author now<br>In the case I'm working with some AI-assisted code, I may not have necessarily been the driver of the changes or making a lot of the decisions that were made.<br>By having to explain the choices in the commit message, I'm not only working out why the decisions were made, but taking full ownership of the changes.<br>(regardless of whether you do this or not, if you've committed it, it's your responsibility!)<br>Indicating what specific areas are AI assisted<br>I work to introduce atomic commits where possible, which allows me to add per-commit attribution for AI usage.<br>In cases where I am using AI to support a change, I can opt to specify in the commit message exactly what pieces have had AI assistance, allowing a way to call out specific areas the different AI model(s) have been used.<br>AI can't replicate my taste (yet?)<br>Last week, I'd been working on some personal projects that I've been struggling to make the time to work on, so decided to get my Claude for Open Source (Claude Max) subscription to work.<br>I decided to vibe it a little, and allow Claude to commit atomically as it needed to. I don't particularly like the way it writes its commits, so I put Claude Fable on the task of taking 100 of my most recent commits and creating a skill for committing as me to improve the resulting commits.<br>It wasn't surprising that these commits were better, but not quite my writing style. That's absolutely OK - I don't actually want an AI to be able to write like I do.<br>But it is a nice...