12 ms·

It is missing the (to me) most important part. The reason why these changes are made.

stpedgwdgfhgdd 1y ago
True, you need to instruct the AI agents to include this. In our case the agent has access to Jira and has wider knowledge. For commit messages i don’t bother that much anymore (i realise typing this), but for the MRs I do. Here i have to instruct it to remove implementation details.
- DaiPlusPlus 1y ago
  > you need to instruct the AI agents to include this. The agent can't do that if you told Claudepilotemini directly to make some change without telling it why you were prompting it to make such a change. LLMs might appear magic, but they aren't (yet) psychic.
  - ffsm8 1y ago
    I think you're missing context. He's saying that he likely has an MCP connected to jira on the LLM he's developing with. Hence the prompt will have already referenced the jira ticket, which will include the why - and if not, you've got a different issue. Now the LLM will only need something like "before committing, check the jira ticket we're working on and create a commit message ... But whether you actually want that is a different story. You're off the opinion it's useful, I'd say it's rarely doing to be valuable, because requirements change, making this point in time rational mostly interesting in an academic sense, but not actually valuable for the development you're doing It depends on a ton of factors, and at least I'd put very little stock in the validity of the commit message that it might as well not exist. (And this is from the perspective of human written ones, not AI)
jjcob 1y ago
I hate it when I look at some code, wondering why I added a refresh call at that point, I do a git blame to find the commit message, and it says "add refresh call".
- rkomorn 1y ago
  But... I keep being told that commit messages are useless because the code is the documentation, so code diffs are self-explanatory...
  - dspillett 1y ago
    That only works if the code is good enough to be the documentation. In DayJob prefer to cover all the bases: ∞ Try make the code sensible & readable so it can be the documentation. ∞ Comment well anyway, just in case it isn't as obvious to the reader (which might be me in a few months time) as it is to me when making the change. Excess comments can always be removed later (and, unless some idiot rewrites history, can potentially be referred to after removal if you have a “why t f” moment), comments you never write can't be found later. ∞ Either a directly meaningful commit message, or at very least ticket references to where more details can be found. For personal tinkering, I'm a lot less fastidious.
    - rkomorn 1y ago
      > That only works if the code is good enough to be the documentation. It never actually is at any non-minimal scale (and not even the code authored by the the people who claim code is self documenting). My comment was rhetorical and sarcastic.
  - cratermoon 1y ago
    The code is the "how", sometimes it's necessary to explain the "why".
    - rkomorn 1y ago
      Sometimes I wonder if I really do just need to add /s every time I'm being sarcastic.
      - cratermoon 1y ago
        Sometimes I think that people who can't write well enough to convey sarcasm when they mean it should just avoid using it and say what they mean.
darrenf 1y ago
Isn't "Fix dynamic channel list" the reason?
_joel 1y ago
Set a PR template up, that demands those sections are filled in. Could probably do that down to the commit level with pre-commit but realistically you'd want that level of detail in the in the PR. Also add issue id to the commits too, that way you can pull them up easily and get more context.

True, you need to instruct the AI agents to include this. In our case the agent has access to Jira and has wider knowledge. For commit messages i don’t bother that much anymore (i realise typing this), but for the MRs I do. Here i have to instruct it to remove implementation details.

DaiPlusPlus 1y ago
> you need to instruct the AI agents to include this. The agent can't do that if you told Claudepilotemini directly to make some change without telling it why you were prompting it to make such a change. LLMs might appear magic, but they aren't (yet) psychic.
- ffsm8 1y ago
  I think you're missing context. He's saying that he likely has an MCP connected to jira on the LLM he's developing with. Hence the prompt will have already referenced the jira ticket, which will include the why - and if not, you've got a different issue. Now the LLM will only need something like "before committing, check the jira ticket we're working on and create a commit message ... But whether you actually want that is a different story. You're off the opinion it's useful, I'd say it's rarely doing to be valuable, because requirements change, making this point in time rational mostly interesting in an academic sense, but not actually valuable for the development you're doing It depends on a ton of factors, and at least I'd put very little stock in the validity of the commit message that it might as well not exist. (And this is from the perspective of human written ones, not AI)

jjcob 1y ago

I hate it when I look at some code, wondering why I added a refresh call at that point, I do a git blame to find the commit message, and it says "add refresh call".

rkomorn 1y ago
But... I keep being told that commit messages are useless because the code is the documentation, so code diffs are self-explanatory...
- dspillett 1y ago
  That only works if the code is good enough to be the documentation. In DayJob prefer to cover all the bases: ∞ Try make the code sensible & readable so it can be the documentation. ∞ Comment well anyway, just in case it isn't as obvious to the reader (which might be me in a few months time) as it is to me when making the change. Excess comments can always be removed later (and, unless some idiot rewrites history, can potentially be referred to after removal if you have a “why t f” moment), comments you never write can't be found later. ∞ Either a directly meaningful commit message, or at very least ticket references to where more details can be found. For personal tinkering, I'm a lot less fastidious.
  - rkomorn 1y ago
    > That only works if the code is good enough to be the documentation. It never actually is at any non-minimal scale (and not even the code authored by the the people who claim code is self documenting). My comment was rhetorical and sarcastic.
- cratermoon 1y ago
  The code is the "how", sometimes it's necessary to explain the "why".
  - rkomorn 1y ago
    Sometimes I wonder if I really do just need to add /s every time I'm being sarcastic.
    - cratermoon 1y ago
      Sometimes I think that people who can't write well enough to convey sarcasm when they mean it should just avoid using it and say what they mean.

darrenf 1y ago

Isn't "Fix dynamic channel list" the reason?

_joel 1y ago

Set a PR template up, that demands those sections are filled in. Could probably do that down to the commit level with pre-commit but realistically you'd want that level of detail in the in the PR. Also add issue id to the commits too, that way you can pull them up easily and get more context.