← All episodes

2026-08-22 · Why I still hand write my commit messages cover art

2026-08-22 · Why I still hand write my commit messages

Show notes

BRINE — 2026-08-22 · show notes

Guest: the open-source maintainer (a fictional archetype).

Claims are paraphrased and attributed; nothing is read verbatim. Where a thread disagreed with the article, the show surfaces the disagreement.

Segments

  1. Why I still hand write my commit messages
  • Source: https://www.jvt.me/posts/2026/08/17/hand-write-commits/
  • Discussion: https://lobste.rs/s/kj1bvt
  • Topic: software engineering practices · interest 85
  • The author argues that writing commit messages manually is an essential process for verifying one's own understanding of code changes and taking ownership. The discussion emphasizes that offloading reasoning to LLMs risks breaking the social contract of maintainability, and highlights the practical utility of detailed messages for local historical context when remote PR platforms are unavailable.
  1. Proposal to prohibit vibe coded projects from being hosted on SourceHut
  • Source: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CDKSTMKM0ZD9N.2FTBDFREZH699@ddevault.org%3E
  • Discussion: https://lobste.rs/s/5jq8hz
  • Topic: AI in Open Source Governance · interest 85
  • A proposal to ban 'vibe-coded' (AI-generated) projects from SourceHut sparks a broader debate on platform autonomy versus the pragmatic utility of LLMs in software maintenance. The discussion includes a significant intervention from Greg Kroah-Hartman, who argues that while LLM output is often problematic, it functions as a useful tool for security auditing that maintainers should pragmatically exploit rather than ban.
  1. rust-glancer: An alternative LSP for Rust with focus on low memory usage
  • Source: https://rust-glancer.github.io/blog/hello-world/
  • Discussion: https://lobste.rs/s/am0xtj
  • Topic: Rust tooling · interest 85
  • Rust Glancer is a new, memory-efficient LSP implementation for Rust that prioritizes low RAM usage through a persistent, disk-based indexing strategy rather than the memory-heavy, incremental approach used by rust-analyzer. The project includes benchmarks and a detailed architectural critique, and it has already garnered professional interest and analysis from the lead developer of rust-analyzer.

Transcript

Transcript. Paraphrased; sources in notes.md.

HostIt is August 22nd, 2026. Welcome to the show. Today, we are looking at the changing landscape of how we write, govern, and tool our code, drawing all of our stories from the community discussions over on Lobsters. I am here with Tom, who is joining us from his desk, which I imagine is buried under a few dozen GitHub notifications right now. How is the maintenance life holding up this week, Tom?

GuestIt is consistent, Daniel. Meaning, it is mostly people asking why I have not implemented a feature that would take me three months to build just because they watched a two-minute video about a similar tool in a different language. I saw the post about manual commit messages today, and honestly, if I could automate my way out of the frustration of seeing empty commit bodies, I would. But you cannot automate the act of caring about the person reading your history.

HostThat is a perfect segue. Let’s talk about that first piece, which argues that writing out your commit messages by hand is a critical part of the engineering process, not just a clerical task. The author claims that if you offload your reasoning to an AI, you are essentially breaking the social contract of software maintenance, because the reader loses the ability to trust that the author actually understands the change they are proposing. Tom, as someone who spends half his life reading commit logs to figure out why something broke three years ago, does this resonate?

GuestIt resonates to the point of being a requirement. When I am digging through git blame at two in the morning, I am looking for the why. I do not care that you changed a variable name from x to y, I can see that in the diff. I need to know why you thought that was the right move. The Lobsters thread on this is excellent. A user called nickmonad brings up a great point, which is that you cannot force contributors to write good messages, but you can certainly lose respect for the ones who decide that their time is too valuable to explain their own work. If you are using a machine to write your explanations, you are not really communicating. You are just outputting noise.

HostIt is interesting that the thread splits between the practical necessity of the message and the broader implications for the profession. Moving on, there is a heated debate over on SourceHut, the minimalist forge, about whether they should outright ban what people are calling vibe-coded projects, essentially, software built entirely by AI agents without human intervention. The proposal is about keeping the platform clean, but it has drawn in some heavy hitters, including Greg Kroah-Hartman, who suggests that while AI output is often problematic, it is a tool for security auditing that we should not discard in a fit of purism. How do you square those two?

GuestIt is a messy situation. On one hand, I have zero interest in reviewing code that was hallucinated by an agent that has no stake in the project. That is a waste of my finite human attention. But Greg is right. If I can use a script to scan for buffer overflows or bad memory patterns, I am going to use it. The problem is the performative aspect of it. A user called accelbread in the thread mentions they have less trust for projects that do not have a human hand in the steering, and I feel that in my bones. If I ban a tool, I am just pushing people to platforms that do not care about code quality. It is a game of whack-a-mole.

HostWell, at least when it comes to tools, the community still seems to value human-centric engineering. Take the launch of Rust Glancer, a new Language Server Protocol implementation for Rust. The author’s claim is that rust-analyzer, the current standard, is just too heavy for older hardware, so they built an alternative that prioritizes low memory usage through a persistent, on-disk index. It is already getting attention from the experts, including the lead developer of rust-analyzer. Tom, are you tempted to switch?

GuestI am always tempted by anything that keeps my RAM usage under 100 megabytes, Daniel. I am running a project that is fairly resource-intensive, and sometimes I have to run it in a container with strict limits. If I had a tool like this, I could keep my index warm across restarts without the machine hitting the swap file and dying. A user called yshui points out that the real win here is the persistent index, and they are spot on. It is the kind of engineering that respects the user’s hardware. I actually spent about twenty minutes yesterday testing a similar indexing strategy for my own utility library to see if I could speed up cold starts. It is not quite as ambitious as an LSP, but it is the right philosophy. You build for efficiency, and you build for persistence.

HostI think that is the theme for the day, really. Whether it is commit messages, AI governance, or LSP backends, it is all about whether we are building for five years from now, or just for five minutes from now.

GuestExactly. If you are building for the future, you have to write it down, you have to be honest about how you built it, and you have to respect the machine it is running on. I have got a pile of issues to clear before the weekend, so I suppose I will be writing some very high-quality, human-generated commit messages for the next few hours.

HostI will let you get to it, then. Thank you, Tom, for stopping by to help us parse the latest from Lobsters. For everyone listening, we will be back tomorrow with more. Have a great day.