[federiconafria]

Anyone else finds the LLMs version control discipline lacking?

The engineering practices in general are lacking. Not tests nor assumptions validation ever, unless explicitly asked.

[dumbfoundded]

Have you tried creating skills for your agents to follow your patterns?

[clintonb]

> Anyone else finds the LLMs version control discipline lacking?

No? How do you define discipline? Claude code knows how to read and write commits. My team just granted it limited force push access a week ago. We’ve taught it to make more human-friendly commit messages.

What’s missing?

[t-writescode]

I think a useful question here is “what is a good commit?”, specifically at the MR stage. I don’t care what commits look like on your local machine.

I tend to like to treat commits at that stage as complete, atomic thoughts.

  “This commit is a refactor of this function name”
  “This commit defines all the data classes we’ll use”
  “This commit writes the new function and all its tests”
  “This commit injects the new code into the old path with a feature flag”
  “This commit fixes the tests that broke from that change”

Some of these would be better served as separate MRs entirely; but I imagine my idea stands.

[clintonb]

I primarily care about the pull request title and description since we squash-merge and those values end up populating the squashed commit.

[t-writescode]

What do you do to keep the cognitive load of reviewers at a minimum?