4 ms·
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
by semiquaver 15d ago
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.
- BeetleB 15d agoAt work, I simply don't allow LLMs to make commits. :-)
- hannasanarion 15d agoThis currently is my team's only AI-use policy and I thik it's working out fantastically. "No AI PR Descriptions" is a great rule because it does 3 things: 1. It's a hard binary that's easy to recognize and enforce 2. It establishes personal ownership for the submitter, making it psychologically difficult to submit something you don't understand. If a person has to describe what a change does, how, and why, then they must have looked at it and made a real attempt to understand it, because you can't map a territory you have never seen. This alone prevents "claude-code run amok" scenarios where devs have completely abdicated responsibility that are a real pain to clean up. 3. It informs the reviewer of the change's intent. A human PR tells reviewers what a thing is intended to do, as well as the authors belief about what it does, which they can use as a framework to critique the actual substance. It becomes easier to notice missed edge cases, code behavior that subtly differs from intent, or changes that would block off or complicate an intended future project direction or reduce maintainability. And as a bonus, at time of writing, AI pr descriptions basically always suck. They are usually full of irrelevant implementation details, misplaced emphasis, weird presuppositions that seem to come out of nowhere and are really annoying to read, etc. That won't be true forever, they are always getting better, but it is true now, so that's a temporary 4th benefit.
- vova_hn2 14d agoGreat comment, no idea why it was flagged
- dawnerd 14d agoOur rules are: short title that should match the task in the ticket tracker, link to the task in the body as the first item, pr summary that’s human readable, screenshots of any front end changes at all the breakpoints. The screenshot requirement is huge, it’s caught a lot of people skipping visual testing locally. Even if they have an llm generate the screenshot we know it’s been at least tested by something and allows for a quick check before someone even wastes their time looking at code.
- LeafItAlone 15d agoA big win of LLMs in my book is the absolute reduction of commit messages with just “fixes” or “updates”. Commit messages have become more meaningful and useful, even if far from perfect. We have one dev who uses LLMs to write the code, but still commits by hand. Most of his messages are of the type above, and none of them are useful.
- semiquaver 15d agoYeah, I know people who have the same zero-explanation `git commit -mfix` style that they did pre-AI and am baffled. If you can’t be arsed to explain yourself, let the agent do it. It literally takes less work to tell the agent to commit for you and they will always do better than -mfix. I don’t understand it either other than obstreperous “become ungovernable” attitude.
- this_user 15d agoI'm not sure that Claude's "Realigned the shape of the load-bearing ownership gate to reduce the blast radius of the design contract; confirmed, not assumed" is more meaningful than "fix".
- 0x696C6961 15d agoThe long-ass Claude commit messages & PR descriptions suck. But they are 100% better than "fix".
- ericbarrett 15d agoMildly disagree. "Fix" is exasperating but immediately tells me I need to look at the diff. With unconstrained Claude spew, I need to wade through three levels of deep fried LLM-speak before realizing...I need to look at the diff
- atif089 15d ago[flagged]
- 15d ago
- initsecret 15d agosame. also—from the reviewer end—LLM generated PR descriptions are loooooooooooooong.
- dyauspitr 15d agoWhy do you want to understand the agent generated code though? That would make you the bottleneck. Shouldn’t you just concentrate on checking for optimal outcomes, exhaustively trying to find/prompt edge cases and profiling performance?
- codechicago277 15d agoIt’s difficult if not impossible to know where to look for edge cases or performance problems without understanding the code.
- semiquaver 15d agoLetting agents run wild with a codebase and no humans understanding it is a recipe for disaster across so many axes. You are not a serious person if you recommend that. Check back in a couple years and I’m sure they’ll be there but today’s frontier models 100% absolutely are not ready to fully own a nontrivial production codebase with no human involvement.
- intended 15d agoProcess vs outcomes. If your work has little liability then you can afford to not care beyond “does it work”. If you have to worry about quality and ensuring you don’t get sued, you make sure the process works. If it has to maintainable, you you need the mental model to be present in someone’s head.
- tiborsaas 14d agoI do check most of agent code, not because I really care about every tiny detail but to catch if it's going to shoot itself (and my project) in the foot. If I only check the result and it's OK, it still doesn't mean that in two features I won't totally blow up the app. I'm a happy little bottleneck, what's wrong with that? How do you even know how to ask it to build stuff for you if you don't understand what foundations are you building on? Writing commit message (aka. what has changed) gives me a sense of control that I know what's happening and I can confidently build the next thing.
- FuckButtons 14d ago
- cgriswald 15d agoUsing LLMs is like managing people. It’s difficult in some ways and easier in others. You should trust them to a degree but also know what is going on and if you’re “trusting” them out of laziness you’re doing it wrong.
- jdkoeck 15d agoTwo years ago? I don’t get it, coding agents have been compelling for barely a year.
- solarkraft 14d agoI 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.
- Terr_ 14d agoFor 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.
- maximg68 14d agoMakes sense. I started asking Claude to grill me on the PR to make sure I understand it.