Live data from Hacker News

How version control will evolve for the agent boom

entire.io

31–40 of 72 posts

Re: How version control will evolve for the agent boom

#33

Has anyone tried teaching the agents to use jj or gitbutler-cli to do their ideas of lightweight branches? I keep feeling like that would be a huge win for the multi-branch development I'm doing much more of with agents, but I haven't yet run that experiment.

Claude works with jj just fine.

Re: How version control will evolve for the agent boom

#34
When your AI consumes documents that are out of date it introduce bugs and incorrect behavior into the system. Code is the only source of truth that actually matters.

The only artifacts outside of code that I don't explicitly end-date are user-story style requirements documents that I periodically revisit with the AI to make sure they're up to date.

One of the most annoying things I've seen AI do is accidentally pull in old requirements and start building off of them.

Re: How version control will evolve for the agent boom

#35
post #27

I think a Q&A-based approach is could also be a suitable way to capture the reasoning behind a project. Instead of writing documentation afterward, an AI could interview the developer throughout the process and preserve the questions and answers as project context. Matt Pocock’s “grill-me” skill is a nice example of this idea: https://github.com/mattpocock/skills/tree/main/skills/produc...

Superpowers' brainstorming skill is another classic example of this. This skill with SOTA models is incredibly helpful. The results become very thorough specs/plans, ADRs, etc.

https://github.com/obra/superpowers/blob/main/skills/brainst...

Re: How version control will evolve for the agent boom

#36

I don't see this taking off. LLM's produce absolute novels worth of verbose text; and nobody wants to read someone else's conversation with it, and certainly nobody wants to read a multi-year old session log that's 20,000 words long. Also, this is what commit messages are supposed to solve! And the only reason anyone looks at logs are to see what's going wrong, and usually a bisect is easier for finding bad commits r…

I tend to find that such specs as committed to git best take the form of commit messages. And then a summary, in the pull request. We also did this in the before-time.

For what its worth, agents are very capable of navigating these. I highly recommend asking an ai to go do the same thing your colleague did half a year ago for this new context, or whatever.

Re: How version control will evolve for the agent boom

#37

Has anyone tried teaching the agents to use jj or gitbutler-cli to do their ideas of lightweight branches? I keep feeling like that would be a huge win for the multi-branch development I'm doing much more of with agents, but I haven't yet run that experiment.

I was interested in answering this question so I built a benchmark comparing git, jj and gitbutler in agentic context

https://vcbench.dev/

Disclaimer - I am a co-founder of GitButler

Re: How version control will evolve for the agent boom

#39
post #24
post #14

I find the value of someone steering an AI session to be practically nil for nearly everything. Nobody wonders out loud how a senior developer arrives at the result he does without an AI; they care that his deliverable is high quality and meets whatever standard/requirement exists. So I'm not sure why people going "chop, chop" and "nah make it more red and bigger" is a useful signal of much of anything. No, the futur…

> Nobody wonders out loud how a senior developer arrives at the result he does without an AI; they care that his deliverable is high quality and meets whatever standard/requirement exists. I think the issue that many may not want to think about is, how do we promote/reward/fire developers in the AI assisted programming age. As part of code reviews, I think it will be second nature to ask "how did you arrive at the co…

Can’t wait to get in trouble for having curse words in my chat with AI get flagged by the company’s anti-swearing-in-code automation.

Re: How version control will evolve for the agent boom

#40

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.

> 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?

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.
Post reply on HN