How version control will evolve for the agent boom
31–40 of 72 posts
Re: How version control will evolve for the agent boom
#32Re: How version control will evolve for the agent boom
#33Has 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.
Re: How version control will evolve for the agent boom
#34The 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
#35I 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...
https://github.com/obra/superpowers/blob/main/skills/brainst...
Re: How version control will evolve for the agent boom
#36I 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…
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
#37Has 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.
Disclaimer - I am a co-founder of GitButler
Re: How version control will evolve for the agent boom
#38Re: How version control will evolve for the agent boom
#39I 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…
Re: How version control will evolve for the agent boom
#40Anyone 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 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.