I love this stuff as a hobbyist, but professionally I can't help but think this is all obsolete in the age of agent-driven development. I wish jj was around a decade ago.
I've been playing around with agent-native source annotation to specifically address the massively parallel work problem. Check it out here: https://github.com/draxl-org/draxl
You don’t need jj for this anymore. The whole premise of optimizing human workflows around source control is becoming obsolete.
When LLMs are driving development, source control stops being an active cognitive concern and becomes a passive implementation detail. The unit of work is no longer “branches” or “commits,” it’s intent. You describe what you want, the model generates, refactors, and reconciles changes across parallel streams automatically.
Parallel workstreams used to require careful coordination: rebasing, merging, conflict resolution, mental bookkeeping of state. That overhead existed because humans were the bottleneck. Once an LLM is managing the codebase, it can reason over the entire state space continuously and resolve those conflicts as part of generation, not as a separate step.
In that world, tools like jj are optimizing a layer that’s already being abstracted away. It’s similar to how no one optimizes around assembly anymore. It still exists, it still matters at a lower level, but it’s no longer where productivity is gained.
> The unit of work is no longer “branches” or “commits,”
It better be, now and going forward for people who use LLMs..because they will need it when LLM messes up and have to figure out, manually, how to resolve.
You ll need all the help (not to mention luck) you need then..
A lot of words to say "LLMs are good for this, trust me bro!"
You're bashing the old way, but you do not provide any concrete evidence for any of your points.
> The unit of work is no longer “branches” or “commits,” it’s intent.
Insert <astronaut meme "always has been">.
Branching is always about "I want to try to implement this thing, but I also want to quickly go back to the main task/canonical version". Committing is about I want to store this version in time with a description of the changes I made since the last commit. So both are an expression and a record of intent.
> Parallel workstreams used to require careful coordination: rebasing, merging, conflict resolution, mental bookkeeping of state.
Your choice of words is making me believe that you have a poor understanding of version control and only see it as storage of code.
Commits are notes that annotates changes, when you want to share your work, you share the changes since the last version everyone knows about alongside the notes that (should) explain those changes. But just like you take time to organize and edit your working notes for a final piece, rebasing is how you edit commits to have a cleaner history. Merging is when you want to keep the history of two branches.
Conflict resolution is a nice signal that the intent of a section of code may differ (eg. one wants blue, the other wants red). Having no conflict is not a guarantee that the code works (one reduces the size of the container, while the other increase the flow of the pipe, both wanted to speed up filling the container). So you have to inspect the code and run test afterwards.
Discard the above if you just don't care about the code that you're writing.
I think we’re talking past each other. My point isn’t that jj is bad. It’s that it’s solving problems that are rapidly becoming irrelevant.
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.
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. Source control becomes an implementation detail of the toolchain, not something I actively operate.
jj is an improvement over git for humans, but that’s exactly why it feels like a local maximum. It refines a workflow that is already being abstracted away.
I’m not saying version control disappears. I’m saying it moves down a layer, the same way memory management or instruction scheduling did. When that happens, optimizing the human interface to it matters a lot less.
> 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.
There are a lot of assumptions baked into your assessment. We are not at the point where manual workflows are obsolete. Maybe it is for folks who work on web apps, but it's certainly not the case for many others. AI Agents are constantly making mistakes and need oversight. Things have gotten dramatically better, but not enough for me to trust it to not create a terrible mess.
No, I don't trust AI to do much of anything. I've written in other comments on HN that I mostly use it to write draft commit messages and pull requests that I review and rewrite myself, now that the honeymoon phase has ended. But when I was still attempting to get it to do more, I found Claude Code was really bad at trying to fix conflicted merges and rebases, always dropping the wrong parts of the code and leaving me with a broken codebase and a commit message history that didn't make sense for the changes inside.
I have been using Claude for 95% of the mechanical coding for months, and jj has proven to be more relevant than not for me. Because it is a better VCS tool than git, it allows to work with the firehose of commits much more seamlessly.
Actually it’s more relevant than ever since agents trivially parallelize work, but it still needs to be validated together. You can work on individual branches in worktrees and have the ‘megamerge’ in yet another.
Spray painting a bunch of airplanes is terrorism. Got it.
Oh, and don’t come crying when the same authoritarian laws put in place for Palestine Action are used to label your cause as terrorism to quash dissent.
Even if I hadn’t, I surely would have by now given the amount of “gotchas” in this thread using this crime as some kind of smoking gun justification for proscription.
But it is good to know that criminal assault is now equivalent to terrorism.
1) Uh.. not terrorism? Hate crime perhaps, but that should be decided by a jury, not unilaterally determined by the gov.
2) So arms manufacturers participating in a war (at best!) are now equivalent to.. gay establishments? I suggest thinking through your examples before sharing them :)
People want to spend money to fix a problem that fundamentally requires effort on their part, not tech.
Vacuuming is actually the easiest bit of cleaning a house IMO - getting the floor clear (if you have kids, or out of control hobbies, or are just lazy or a bit of a horder) is hard.
People aren't stupid, they kind of know this. But just like buying expensive gym equipment they think that a new toy will incentivise them do the hard bits.
"If I buy a new gizmo I'll finally start cooking healthy delicious food" is a great pitch.
It was “easy” to vacuum before but we never did a thorough job. All too often we just vacuum what we can see, never under the couches, etc.
Now that we have to move everything so it can complete the full map we have a much cleaner house. It encourages us to move all of the chairs, toys, etc.
I worked on an IoT project at one of the big German car makers and it was a mess. More money than sense. They didn't really have any idea why they were putting software into stuff. Just some vague notion that some software systems needed to exist to then present its existence to the next boss up; presumably all the way up and out to investors. Discussing the actual functionality or how the product(s) would actually be experienced in the real world was essentially taboo.
There was a podcast called garbage.fm [1] with one of the hosts working for General Electric at the time it was recorded. It sounded like GE were yet another one of those incumbent companies doing "smart" Internet of Things products just because they were worried about being left behind.
Well, clearly, you know a lot about being a serious enterpreneur. Don't let us luddites drag you down, I'm sure your next 100% vibe coded B2B SaaS will be a massive success.
Nowhere in the article does he explain why the use of AI is inherently problematic or why it necessitates rewriting the project plan. Work product is either good or bad, and responsibility for its quality rests with the person delivering it. The tools used to produce the work are irrelevant. In fact, for those who prioritize execution speed, the use of labor-saving tools should be encouraged wherever feasible.
This comment was generated by chatgpt (inspired by me).
reply