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.
How version control will evolve for the agent boom
11–20 of 72 posts
Re: How version control will evolve for the agent boom
#12I am anticipating a move away from git-style version control entirely.
One possible shape is something like unison-lang's CAS AST model:
https://www.unison-lang.org/docs/the-big-idea/
This model has some significant downsides for humans, but less so for automatons. It eliminates some major problems of software development like merge conflicts, dependency hell, etc.
Re: How version control will evolve for the agent boom
#13Has 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
#14I 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 future is a complex "gate" that checks, weighs and measures everything before it gets committed --- a local (or remote) "CI" but... more granular and far more specific and turned to the needs of the project you work on.
Re: How version control will evolve for the agent boom
#15> Our hypothesis is simple: session logs are now the most important artifact in software development, and should be stored alongside the code itself in the repository. Pi.dev has a feature where you can export the session as a html file and look at it later. I foresee that potentially you could store this in the same Git repository and get the benefit of reviewing how a particular code change came about during a sess…
entire cli maintainer here: the entire cli does exactly this, with support for agent native clis but also pi or opencode. We take the raw session logs, put it in the repo with a stable link to the commit, and then you can render it in the cli or see it in on entire.io.
Re: How version control will evolve for the agent boom
#16Followup announcement post:
An Entirely New Git Hosting Network
Re: How version control will evolve for the agent boom
#17I 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…
Hi! I work at Entire. We actually have another feature that we announced called Trails which indicates Confidence, Risk, Drift of code changes to give the maintainer more confidence that the code is high quality.
Each of those signals -- confidence, risk, drift are determined by a workflow file that the maintainer can create.
And trails continuously evaluate every time a change is made.
So that's exactly what we're doing..a gate that checks and weighs and measure everything before it gets committed.
The point of us capturing the agent sessions is so we can do more things with it..like adding "gates" that verify quality!
Re: How version control will evolve for the agent boom
#18We need to store CHOICES with the commit or branch. Not the whole session. Conscious, summarized choices
Re: How version control will evolve for the agent boom
#19Has 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.
> Has anyone tried teaching the agents to use jj or gitbutler-cli to do their ideas of lightweight branches?
This is very trivial if your coding agents supports hooks like Pi. I have demo repo that goes over how rules work at https://github.com/gitsense/gsc-rules-demos
The basic idea is, you always ensure you inject the instructions for how to use jj or any other scm. LLMs are pattern matchers and they can fully map behaviour, but due to heavy training on git, they can forget.
With hooks, you can easy detect when 'git' is used and basically tell the agent "As stated earlier you must use jj". So it will try again using `jj` and you block the agent when ever it tries to use git.
It is a wasted turn but the reality is, it won't cost must since you can leverage caching and you only waste tokens on the invalid command and not the output generated from git.
Re: How version control will evolve for the agent boom
#20Anyone 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?