VisualJJ – Jujutsu in Visual Studio Code

The OP is talking about the `jj workspace create` command, which creates a separate working copy backed by the same repository. It’s not a bad way to work with multiple agents, but you do have to learn what to do about workspace divergence.

Like git, you don’t lose any history.

Sibling comment from gcr has the right details.

This doesn't involve git use at all.

Even with multiple workspaces (like git worktrees), once you use something like jjk, both the agent and jjk in the associated VS Code are operating on the same workspace, so that doesn't isolate enough. I don't think jjk uses `--ignore-working-copy` for read-only status updates, so it's snapshotting every time it checks the repo status while the agent is editing.

On top of that, throw in whatever Claude does if you "rewind" a conversation that also "reverts" the code, and agents wrongly deciding to work on code outside their focus area.

It's possible watchman helps (I need to look into that), but I'm so rarely using jj in VS Code (all I really want is inline blame), that it was easier to remove jjk than try to debug it all.

Divergence won't hide or lose any work, but it's an annoying time-suck to straighten out.

The point of jj is that it supports lockless concurrent writes to the same repo out of the box. It is what makes it a lot more suitable than git for agent workflows

MCP solves the wiring problem nicely, but once you have more than one coding agent running, coordination becomes the real bottleneck.

I ran into repeated issues with agents editing the same files, losing decisions, and drifting away from the spec. I ended up building a small Rust MCP server that adds task claiming, file-level locking, and drift checks against SPEC.md.

It’s intentionally boring infrastructure… single binary, file-based state, deterministic orchestration. The AI tools stay interchangeable.

Repo if anyone’s curious: https://github.com/nxtg-ai/forge-orchestrator

Git's plumbing also kinda sucks (in places). Some of the current limitations of jj in what syncing state between repos is due to things missing from git that they are having a hard working around, at least based on what I've seen browsing their tickets. That inability to push the really useful jj state upstream for pulling from any machine seems like a major pain point in jj right now (was one of the major issues referenced in a jujutsu intro guide last year linked on HN)

The same issue hit the initial efforts (that I think were the inspiration for jj) when the mercurial folks, recognising git had kinda taken over the market, experimented in making a mercurial frontend backed by the git db. Limitations like the diff format (mercurial's weave one is one the jj folks also want to add at some point) and the lack of a method for tracking phases (mercurial relies on this for clean history without throwing out commits), and lack of file move/copy tracking.

For anyone that does not work at Google, it sounds like an implementation detail that does not matter.

Even if you're not authoring changes as much, change management is likely still to be a very useful activity for a long while. Also note that not everyone is using AI today, and many that do only use it as glorified auto complete. It will take many more years for it's adoption to put us in a situation like your describing, why halt progress in the meantime? My personal productivity increased greatly by switching to jj, perhaps more than adding Gemini CLI to my workflow. I can more confidently work on several changes in parallel while waiting on things like code review. This was possible before but rebasing it and dealing with merge conflicts tended to limit me from doing it beyond a handful of commits. Now I can have 20+ outstanding commits (largely with no interdependencies) and not feel like I'm paying much management overhead while doing so. I can also get them reviewed in parallel more easily.

Ah yes, the inevitable future where the only way we'll know to interact with the machine is through persuading a capricious LLM. We'll spend our days reciting litanies to the machine spirits like in 40k.

> For this reason, programming languages, at least how we understand them today, have reached a terminal state. I could easily make a new language now, especially with the help of Claude Code et al, but there would never be any reason for any other engineer to use it.

This is an interesting opinion.

I feel we are nowhere near the terminal state for programming languages. Just as we didn't stop inventing math after arithmetic, we will always need to invent higher abstractions to help us reason beyond what is concrete (for example, imaginary numbers). A lot of electrical engineering wouldn't be possible to reason about without imaginary numbers. So new higher abstractions -- always necessary, in my opinion.

That said, I feel your finer point resonates -- about how new languages might not need to be constrained to the limitations of human ergonomics. In fact, this opens up new space of languages that can transcend human intuition because they are not written for humans to comprehend (yet are provably "correct").

As engineers, we care about human intuition because we are concerned about failure modes. But what if we could evolve along a more theoretical direction, similar to the one Haskell took? Haskell is basically "executable category theory" with some allowances for humans. Even with those tradeoffs, Haskell remains hard for most humans to write, but what if we could create a better Haskell?

Then farther along, what if we created a LEAN-adjacent language, not for mathematical proofs, but for writing programs? We could throw in formal methods (TLA+) type thinking. Today formal methods give you a correctness proof, but are disconnected to implementation (AWS uses TLA+ for modeling distributed systems, but the final code was not generated from TLA+, so there's disconnect). What if one day we can write a spec, and it generates a TLA+ proof, which we can then use to generate code?

In this world, the code generator is simply a compiler -- from mathematically rigorous spec to machine code.

(that said, I have to check myself. I wonder what this would look like in a world full of exceptions, corner cases, and ambiguities that cannot be modeled well? Tukey's warning comes to mind: "Far better an approximate answer to the right question, than an exact answer to the wrong question")

I'm quite surprised to hear that "programming languages have reached a terminal state": there are (imo) at least four in-progress movements in the industry right now:

1. Memory safety 2. Better metaprogramming capabilities 3. Algebraic effects 4. Solver/prover awareness

Even if LLMs become capable of writing all code, I think there's a good chance that we'd want those LLMs writing code in a language with memory safety and one amenable to some sort of verification.

I noticed it get a lot better with the 4.5 models specifically. Before then, I would have to tell Claude "do a web search for the docs for jj, then do XYZ." Now I just tell it to "do XYZ using jj"

Why would I learn the abstraction of JJ on top of git when I've got a butler who's happy to deal with git directly?

You're right in principle, but it just seems JJ is a solution in search of a problem.

If it helps, this was all I needed in my CLAUDE.md to make it use jj perfectly:

  # Version Control

  - IMPORTANT: YOU MUST assume we use Jujutsu ("jj") for version control. Check by running `jj root` (or look for a  `.jj/` directory) to confirm.
  - If I say "commit", "branch", "squash", etc., assume jj equivalents first. 
  - You can ignore any `git add` command, since jj always auto-adds.
  - Use `jj` commands instead of `git`. Never run `git` in a jj repository.
  - ALWAYS prefer jj change IDs over commit SHAs. jj change IDs are stable.
  - jj doesn't usually require named branches
  - If you need named branches, use `jj bookmark`, but you must manually update the bookmark after making new commits, since they won't automatically get updated
  - When reading data from jj, always use `--ignore-working-copy` to avoid snapshotting the working copy (which is slow and unnecessary for read operations). But when writing (commit, squash, rebase, etc.), you MUST NOT use `--ignore-working-copy`.
  - If you get "Error: The working copy is stale", run `jj workspace update-stale` first

Given jj's rebasing tooling, rewiring precommit into "prepush" feels like the right way forward. There's a bit of a phase transition between commits on your machine and commits that are out in the wild, after all.

I mean the Google CLA kind of says otherwise.