4 ms·

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 d

by uhhhd 6mo ago

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.

MeetingsBrowser 6mo ago
I disagree. Easily reviewing and combining multiple streams of parallel work is more valuable than ever.
- riwsky 6mo ago
  With jj worktrees, you can even have agents working on each of those sub-megamerge branches in parallel.
- rndhouse 6mo 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 https://github.com/draxl-org/draxl
- uhhhd 6mo ago
  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.
  - qsera 6mo ago
    > 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..
  - skydhash 6mo ago
    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.
    - uhhhd 5mo ago
      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.
nozzlegear 6mo ago
I've found agents like Claude are absolute ass at fixing any halfway complex merge conflict. I won't trust them to do it.
- rstuart4133 5mo ago
  You trust Claude (or any AI) to do anything right? The odds are good - but never 100%. That said, "jj new -A @", get Claude to do it's thing, "jj squash" is going to be pretty safe.
  - nozzlegear 5mo ago
    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.
quicksnap 6mo ago
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.
baq 6mo ago
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.
chrishill89 5mo ago
Let's say that this is obsolete for professional programming. Can't us hobbyists be left alone to our hobby by the LLM demoralization patrol?
JonGretarB 5mo ago
Oh I would say that jj is exactly the kind of VCS needed for agentic workflows. Anonymous branches. Easy to move things around. Always succeeding merges. Megamerges. Worktrees not bound to branches.

by uhhhd 6mo ago

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.

MeetingsBrowser 6mo ago

I disagree. Easily reviewing and combining multiple streams of parallel work is more valuable than ever.

riwsky 6mo ago
With jj worktrees, you can even have agents working on each of those sub-megamerge branches in parallel.
rndhouse 6mo 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 https://github.com/draxl-org/draxl
uhhhd 6mo ago
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.
- qsera 6mo ago
  > 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..
- skydhash 6mo ago
  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.
  - uhhhd 5mo ago
    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.

nozzlegear 6mo ago

I've found agents like Claude are absolute ass at fixing any halfway complex merge conflict. I won't trust them to do it.

rstuart4133 5mo ago
You trust Claude (or any AI) to do anything right? The odds are good - but never 100%. That said, "jj new -A @", get Claude to do it's thing, "jj squash" is going to be pretty safe.
- nozzlegear 5mo ago
  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.

quicksnap 6mo ago

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.

baq 6mo ago

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.

chrishill89 5mo ago

Let's say that this is obsolete for professional programming. Can't us hobbyists be left alone to our hobby by the LLM demoralization patrol?

JonGretarB 5mo ago

Oh I would say that jj is exactly the kind of VCS needed for agentic workflows. Anonymous branches. Easy to move things around. Always succeeding merges. Megamerges. Worktrees not bound to branches.