>
Tools like git and jj exist to help humans manage state: branches, commits, rebases, conflicts, history curation. That whole model assumes a human is directly manipulating and reasoning about the codebase.Think about the following first. You got a problem in the real world and if you can subdivide it into smaller problems, you will find that some are simple enough that a computer can take care of it and never be bored while doing it. And due to the last decades a lot of them have ready-made solutions. But you have to coordinate those solutions and write a program. And for these you need to write instructions into a text files.
But the real world is not static and you can't figure out the solution in one go, so you have to do iterative works on it. And unlike real world, the only cost of modifications is time. But you still want backups and the ability to restore version. So here come version control for the code of the software.
So you start thinking about all the possible workflow you could do with checkpoints you can return to in a few minutes, and it will look very close to something like git (or cvs). The one thing is that the computer is very removed from the problem that is driving all the changes and instead is at the other side. So it can magically correct issues and instead you have to step in.
> With LLMs in the loop, that assumption breaks. I don’t need to think in terms of branches or commits. I describe intent, and the model handles the mechanics of editing, reconciling, and producing a coherent result.
That would be great if that was possible now, but that looks like a synopsis for some SF novel. I can use git or jj today, but your version is lacking the several steps that would be making this a daily occurrence.
> memory management or instruction scheduling
You may think that they did, but that's until you have to deal with a memory leak or concurrent tasks. What we want version control for is the capability to snapshot state and restore to a known state and to share changes (instead of whole folder) when collaborating. How it's done does not really matter but git's conceptual model is very close to be ideal (at least for text files and line based statements). And its UX is versatile enough to be adaptable for all sort of workflow.