I've also found it good at catching mistakes and helping write commit messages.
"Review the top-most commit. Did I make any mistakes? Did I leave anything out of the commit message?"
Sometimes I let it write the message for me:
"Write a new commit message for the current commit."
I've had to tell it how to write commit messages though. It likes to offer subjective opinions, use superlatives and guess at why something was done. I've had to tell it to cut that out: "Summarize what has changes. Be concise but thorough. Avoid adjective and superlatives. Use imperative mood."
Review your own code. Understand why you made the changes. And then clearly describe why you made them. If you can't do that yourself, I think that's a huge gap in your own skills.
Making something else do it means you don't internalize the changes that you made.
Your comment is not a fair interpretation of what I wrote.
For the record, I write better and more detailed commit messages than almost anyone I know across a decades[^0] long career[^1,^2,^3,^4,^5]. But I'm not immune from making mistakes, and everyone can use an editor, or just runs out of mental energy. Unfortunately, I find it hard to get decent PR reviews from my colleagues at work.
So yeah, I've started using Claude Code to help review my own commits. That doesn't mean I don't understand my changes or that I don't know why I made them. And CC is good at banging out a first draft of a commit message. It's also good at catching tiny logic errors that slip through tests and human review. Surprisingly good. You should try it.
I have plenty of criticisms for CC too. I'm not sure it's actually saving me any time. I've spent the last two weeks working 10 hour days with it. For some things it shines. For other things, I would've been better off writing the code from scratch myself, something I've had to do maybe 40% of the time now.
[^5]: None of the these are my best examples, just the ones I found quickly. Most of my commit messages are obviously locked away by my employer. Somewhere in the git history is a paragraphs long commit message from Jeff King (peff) explaining a one line diff. That's probably my favorite commit message of all time. But I also know that at work I've got a message somewhere explaining a single character diff.
What I can recommend is to tell it that for all documentation, readmes and PR descriptions to keep it "tight, no purple-prose, no emojis". That cuts everything down nicely to to-the-point docs without GPTisms and without the emoji storm that makes it look like yet another frontend framework Readme.
My commits’description part, if warranted, is about the reason for the changes, not the specificity of the solution. It’s a little memo to the person reading the diff, not a long monograph. And the diff is usually small.
I really like httpx’s handling of clients/sessions; it’s super easy to throw one in a context manager and then get multiple hits to the same server all reusing one http2 connection.
This seems like a lot of work depending upon the use case. e.g. the other day I had a bunch of JSON files with contact info. I needed to update them with more recent contact info on an internal Confluence page. I exported the Confluence page to a PDF, then dropped it into the same directory as the JSON files. I told Claude Code to read the PDF and use it to update the JSON files.
It tried a few ways to read the PDF before coming up with installing PyPDF2, using that to parse the PDF, then updated all the JSON files. It took about 5 minutes to do this, but it ended up 100% correct, updating 7 different fields across two dozen JSON files.
(The reason for the PDF export was to get past the Confluence page being behind Okta authentication. In retrospect, I probably should've saved the HTML and/or let Claude Code figure out how to grab the page itself.)
How would I have done that with Gemini using just the web interface?
Do I understand correctly that you deliberately entered personal contact information into LLM?
If so, I would be a reprimanding anyone in my org that did this.
While it’s more effort I’d use the LLM to write a script
to read the page with the Confluence api, parse it, write out
the json files and push them where they need to go.
Add in basic assertions to check the data is present, in the expected format
and there is enough of it. Alerting when the assertions fail, then I can schedule it and forget about it.
This is where LLMs shine, I can now build a robust solution in an hour instead of a day.
Graduated with a CS degree in 1996. Went to work right away for a media company helping run all their web sites. (A few dozen Ultra 2s on a FDDI network connected to NetApps. Served mostly by Apache. A couple beefier boxes serving dynamic content using Perl CGI scripts. The horrid Netscape Server to run early backend JavaScript. Management over a frame relay network. Had friends at Excite, Equinix, etc.)
(In college on the side, I ran a tiny local ISP with a couple dozen Hayes modems connected to a Livingston Portmaster. T1 uplink. A couple PCs running Linux. Before college I had been hanging out on AOL giving technical advice, and before that was using an Apple II dialing into BBS's.)
Which is all to say, I was there for all of this and this piece is pretty much spot on.
When the movie Frequency (which has a communicating across time aspect) was made in 2000, the company the screen writers went to for how to get rich by investing in the right stock? Yahoo.
"Review the top-most commit. Did I make any mistakes? Did I leave anything out of the commit message?"
Sometimes I let it write the message for me:
"Write a new commit message for the current commit."
I've had to tell it how to write commit messages though. It likes to offer subjective opinions, use superlatives and guess at why something was done. I've had to tell it to cut that out: "Summarize what has changes. Be concise but thorough. Avoid adjective and superlatives. Use imperative mood."
reply