Planning, Building, Reviewing: Why The JJ Workflow Works Better Than Git

After a week of experimenting with using git and jj to plan and build, I’ve landed on jj as the winner.

Rebasing Kills the Git Workflow

Automatic rebases are the winning feature here. When I tell Claude to update a change, it will automatically rebase all its descendants. This is a MASSIVE time saver for both me and Claude.

When I use empty commits in git, Claude performs the same until it has to start editing code. Then things get messy.

Rebasing in git is almost always painful. Claude can clunk through the rebase workflow faster than I can, but it still gets lost at times.

My Current Workflow

Here is the CLAUDE.md that’s been working well for me lately. It teaches Claude how to use the jj workflow.

1. Start plan mode

I start a new session in plan mode and give Claude Code all the information I can think of. I describe what I need, reference files, and explain the outcome.

2. Iterate on the Plan

I almost always refine the plan with Claude. I verify the code samples it provides and verify that the implementation meets my expectations.

3. Turn the plan into commits

I’m still in plan mode, and I ask Claude to break the plan down into empty jj changes.

4. Review the jj Plan

This is key. I am still in plan mode here, and I need to ensure the steps Claude has planned make sense and have no gotchas. Iterate on this step.

5. Auto-accept edits

Finally, I let Claude rip. Once the plan looks good, I auto-accept edits and allow Claude to use jj commands as needed.

6. Do Something Else

While I refined this workflow, I watched Claude work to keep it on track and assess whether we had come up with a good enough plan. But I’ve found that with a focused plan, Claude can work away just fine.

7. Code review with Claude

I use a code-review command to kick off code review with Claude. We walk through one change at a time. I sometimes make manual edits, other times I get Claude to refactor things.

8. Use gh to create PRs

Depending on the scope of the change, I’ll make a PR stack and ask Claude to manage the stack for me, or I’ll create a single PR with a linear history.

9. Code Review Again

Yes, I do code review again. The code is mine, after all. I go through the GitHub UI and review the code myself. If I want Claude to make a change, I ask it to edit the jj change set where the code was introduced.

The result is a clean commit history that implements a feature one change set at a time.

Why JJ Works So Well

In steps 7 and 9 above, I review code and often want to make changes to specific change sets. In git, this would involve git rebase -i, picking the commits to edit, making the edits, then git rebase --continue. In jj, all that is done for you.

Two Takeaways

Agent or not. These two things are true in software development. Planning and reviewing are the most critical steps.

Plan, Plan, Plan Again

Working with an AI agent emphasizes the importance of planning. Planning your work has always been essential for successful feature development. Now with agents, we have really fast researchers who can help us refine a plan.

The more time you put into planning, the more successful your work will be, regardless of whether you’re using an agent.

Review, Review, Review Again

Like planning, reviewing your work ensures it is accurate, bug-free, and performant. This is YOUR work after all. Even if an agent wrote it, you own the code.