I returned to doing a lot of my own coding for this reason.

I don't mind farming out the more monotonous bits to AI. When I was letting an agent handle the whole implementation for me, though, I found that I was rediscovering all the pitfalls of waterfall-style development. Because I was doing waterfall-style development. I was trying to pin down all the details in a plan document up front, which is inevitably the point in time where I know the absolute least about the best way to accomplish the task. And then I let the agent do the rest for me, which undermines my opportunity to learn and understand more.

The result was continual accumulation of bad decisions and unnecessary technical debt. The only difference between now and back in the bad old days of 20 years ago is this time instead of being the put-upon code monkey I had become the boneheaded engineering manager who isn't paying attention to the code and doesn't realize what a brittle mess it's become.

This. I've recently (re-)discovered the importance of using writing to force myself to confront my assumptions and gaps in knowledge. It's easy to fool yourself into thinking that you understand something if you haven't made it concrete and explicit by exercising your own brain. Arguably, this extends beyond writing in the conventional sense to many cognitive domains: mathematics, programming, physics, engineering, etc. AI should help the process of thinking, not replace it.

    "Writing is nature's way of letting you know how sloppy your thinking is."

Did you think about this comment or are you just repeating something you heard and that’s been said in every discussion on HN about writing and AI?

I suspect there's a prompt one can add to improve the consumption of commit messages for humans, just that the default one is pretty bad. Kind of similar to the AI generated posters a few weeks back: https://news.ycombinator.com/item?id=49764791.

Why make this change at all? Why do it this way? What would have been the next best way, and why not that? What important assumptions justify this? What's next for this? etc

I like the Git rule of thumb. If it's too long -- it's probably not a single commit.

To stay concise, I think bullet trees are the best. I've never had to make exceptions to this format.

Top level groups high-level concerns (optional). Below that (required) are short distillations of those concerns answering "why". Below that are descriptions of "what" was/wasn't done. A final optional level digs into deeper implementation detail.

The vast majority of my bullet trees are just those two required levels. Each commit message is rarely more than 10 or 15 lines long, and people really appreciate them. I appreciate them too since I'm the most likely to read them.

I have this rule in my global AGENTS.md:

> When writing a commit message, briefly explain at a high level what was done (the details are in the code). Explain the why of the commit; if you don't know that, ask me.

It works quite well. When it doesn't have it in context, it does ask.

Jujutsu is perfect for that - you create new changeset upfront, providing message at the same time (which can be later amended as needed). Feels so much more logical to declare the topic first, rather than come back to some accidentally uncommitted changes and wonder what was doing there.

On hindsight that should be obvious! Pre-write your commit message, because of course you know what you are going to work on!

BDD. Absolutely changed my world