4 ms·

How about you find out for yourself? Keep a chat window or an agent open and ask it how it could help with your tasks. My git messages and gitlab tickets are be

• paffdragon 1y ago
  I find the commits written by AI often inadequate, as they mostly just describe what is already in the diff, but miss the background on why was the change needed, why this approach was chosen, etc, the important stuff...
  • khalic 1y ago
    Then ask it to write the commit differently, or you can explain why in the prompt. Edit: I start by creating the ticket with Claude+terminal tool, the title and descriptions gives context info to the llm, then we do the task, then commit and update the ticket
    • hansmayer 1y ago
      And in the time it takes to do all of that, the guy could have already written a meaningful commit message and be done with that issue for the day.
      • alwillis 1y ago
        And in the time it takes to do all of that, the guy could have already written a meaningful commit message and be done with that issue for the day. You only have to describe how you want commits written once and then the AI will just handle it. Is not that anyone of us can't write good commits, but humans get tired, lose focus, get interrupted, etc. Just in my short time using Claude Code, it generally writes pretty good commits; it often adds more detail than I normally would not because I'm not capable but because there's a certain amount of cognitive overhead when it comes to writing good commits and it gets harder as our mental energy decreases. I found this custom command [1] for Claude Code and it reminded me that there's no way a human can consistently do this every single time, perhaps a dozen times per day, unless they're doing nothing else--no meetings, no phone calls, etc. And we know that's not possible: [1]: https://github.com/qdhenry/Claude-Command-Suite/blob/main/.claude/commands/dev/git-status.md https://github.com/qdhenry/Claude-Command-Suite/blob/main/.c... # Git Status Command Show detailed git repository status *Command originally created by IndyDevDan (YouTube: https://www.youtube.com/@indydevdan) / DislerH (GitHub: https://github.com/disler)* ## Instructions Analyze the current state of the git repository by performing the following steps: 1. *Run Git Status Commands* - Execute `git status` to see current working tree state - Run `git diff HEAD origin/main` to check differences with remote - Execute `git branch --show-current` to display current branch - Check for uncommitted changes and untracked files 2. *Analyze Repository State* - Identify staged vs unstaged changes - List any untracked files - Check if branch is ahead/behind remote - Review any merge conflicts if present 3. *Read Key Files* - Review README.md for project context - Check for any recent changes in important files - Understand project structure if needed 4. *Provide Summary* - Current branch and its relationship to main/master - Number of commits ahead/behind - List of modified files with change types - Any action items (commits needed, pulls required, etc.) This command helps developers quickly understand: - What changes are pending - The repository's sync status - Whether any actions are needed before continuing work Arguments: $ARGUMENTS
        • paffdragon 1y ago
          It's not possible for a human to do what an LLM does at scale, for sure. But that's the difference, humans are not robots, so they will turn the the problem around and will try to find ways on how to not have to do this in the first place. E.g. minimizing pending changes left around by making small frequent commits. A lot of invention comes from people being annoyed doing something all over again manually. LLM stirs up things a little bit as it provides a completely different way of doing such tasks. You don't have to invent a better process if the LLM can do it repeatedly for a reasonable price. The new pressure then comes from minimizing LLM costs, I guess.
        • hansmayer 1y ago
          Wishful thinking. They will often ignore your general instructions, due to the statistical nature of their output. Source: have many such detailed general instructions that routinely get ignored.
      • khalic 1y ago
        Have you tried?
        • hansmayer 1y ago
          No, you see - I have my own brains and don't need to invest more effort in describing a trivial task, than actually doing it myself.
          • khalic 1y ago
            So no, maybe give it a try before talking about it? You know, having an informed opinion and all…
            • contagiousflow 1y ago
              These tools aren't magic, if there are reasons for code changes outside of the diff LLMs aren't going to magically fabricate a commit message that gives that context.
              • khalic 1y ago
                If you were having a Claude code session, it will know the context from the discussion.
• hansmayer 1y ago
  [flagged]
  • khalic 1y ago
    [flagged]
    • hansmayer 1y ago
      I own my own company, so I kind of already have "jobs" that I do not need to compete for.
      • khalic 1y ago
        [flagged]
        • hansmayer 1y ago
          [flagged]
          • khalic 1y ago
            [flagged]
            • hansmayer 1y ago
              [flagged]
              • tomhow 1y ago
                > My man Not here, please.
            • hansmayer 1y ago
              [flagged]
            • 1y ago
• carderne 1y ago
  Do you feed the LLM additional context for the commit message, or it is just summarising what’s in the commit? In the latter case, what’s the point? The reader can just get _their_ LLM to do a better job. In the former case… I’m interested to hear how they’re better? Do you choose an agent with the full context of the changes to write the message, so it knows where you started, why certain things didn’t work? Or are you prompting a fresh context with your summary and asking it to make it into a commit message? Or something else?
  • khalic 1y ago
    Depends, I have a prompt ready for changes I made manually, that checks the diff, gets the context, spits a conventional commit with a summary of the changes, I check, correct if needed and add the ticket number. It’s faster because it types really fast, no time thinking about phrasing and remembering the changes, and usually way more complete then what I would have written, given time constraints. If I’m using a CLI: the agent already has: - the context from the chat - the ticket number via me or when it created the ticket - meta info via project memory or other terminal commands like API call etc - Info on commit format from project memory So it boils down to asking it to commit and update the ticket when we’re done with the task in that case. Having a good workflow is key For your question: I still read and validated/correct, in the end I’m the one committing the code! So it’s the usual requirements from there. If someone would use their LLM the results would vary, here they have an approved summary. This is why human in the loop is essential.
    • paffdragon 1y ago
      Interesting approach. I'm a bit old-school, when I make a change I already have all the context and beyond in my head, plus all the expectations from colleagues, historical context etc that might be useful to remind people about. At least for me, it is easier to formulate the commit based on that, than trying to formulate a prompt to formulate what I want to have in the commit. But I have the same with code. When it is born in my head, it's usually easier for me to write what I want, than trying to explain it to an LLM. I find the LLM a bit lacking precision when it comes to comprehension, a little like trying to explain something to a child (with superpowers, but still need step by step directions). But I find it very interesting how others find prompting more productive for their use cases. It's definitely a new skill. Over years I also built my skill to write commits, so it comes natural to me as opposed to prompting, which requires extra effort and thinking in a different way and context and it doesn't work well for something that I do basically automatically already.