Claude on enumerator.dev

Safe Claude Code Settings

Wed, 26 Nov 2025 03:08:00 +0000

Here are a few commands I have in my Claude Code deny-list to prevent bad things from happening. I wish Claude shipped with these by default!

The following commands disallow Claude from force pushing and skipping pre-commit hooks.

{
  "permissions": {
    "deny": [
      "Bash(git push -f)",
      "Bash(git push --force)",
      "Bash(git commit:*-n:*)",
      "Bash(git commit:*--no-verify:*)"
    ]
  }
}

To be extra careful, I also have a pretty thorough gitignore that I install globally which includes common patterns for secret credentials.

*.key
*.pem
*.p12
*.pfx
*.cer
*.crt
**/secrets/**
**/credentials/**
.env
.env.*
**/config/secrets.toml

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

Sat, 08 Nov 2025 14:04:00 +0000

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.

Use Git to Plan and Build With Claude

Sat, 01 Nov 2025 12:57:00 +0000

When I shared my new JJ and Claude workflow last week, I wondered whether JJ was too much friction for developers. It requires learning a new version-control tool in addition to learning to use Claude. I had an idea in the back of my mind to use plain git for this.

And then Claude did it for me!

Towards the end of the week, I was working in a codebase where I hadn’t initialized JJ yet. Claude tried to use the JJ workflow, saw that JJ wasn’t initialized, and started implementing the same workflow using plain old git. We were working on a relatively simple feature, and Claude created planning commits and implemented it.

You Don’t Need to Learn a New Tool

JJ is a good workflow if you need a graph of related features. I find this happens most often when I’m building a new feature or working in an old codebase where I find bugs.

Most day-to-day work can be done in linear branches. Plus, everyone knows git already.

This morning, I worked with Claude to refine a CLAUDE.md that uses plain old git to plan and build features. This looks really promising so far.

Why is Claude Code Different from Cursor if they Both Use Claude?

Mon, 27 Oct 2025 13:30:00 +0000

I get this question often. Here’s how the story goes:

Someone complains that AI is bad because it just does a bunch of stuff for you really quickly and does it wrong.
I ask what tools they’re using, and they say they’re using Cursor because it’s the most familiar IDE for them.
I ask them if they start a new chat for each feature, and the answer is usually “no” because this isn’t intuitive.
I suggest they try a different agent — Claude Code is my preferred tool — and they say, “It’s all Claude, though, how would that be different?”

Few developers have had time to learn these tools. They’ve been forced to use them as productivity enhancers, without the time to learn.

I have seen performance gains in my work. I shipped the first version of Uplift in a few hours! But I’ve also taken an enormous amount of time learning, training others, and trying terrible AI tools.

I work with many developers who use Cursor daily. This is good! Cursor seems to work better with their workflow. While I have a distaste for Cursor, others find it useful. Agents, like IDEs, are a preference, after all.

Going faster means slowing down to learn your tools. Changing IDEs or using a CLI is a BIG workflow change for most people, and if Cursor is your first brush with AI, I do not blame you for thinking it’s a waste of time.

In this post, I want to demystify “It’s all Claude in the end” to help people understand why some agents are good and others are frustrating.

Defining Terms

Let’s start with defining three standard terms. I’m going to use the common nomenclature in this post, but it’s important to note that their meanings are often blended in different contexts.

AI: These two small letters carry the weight of “agents”, “LLMs”, “automation”, “autocomplete”, and everything else. When someone says “AI,” they mean any one of these. In this post, “AI” refers to coding agents that have some autonomy in their work.
Agent: This term comes up in phrases like “agentic workflow” or “coding agent”. The agent is the engine of AI coding. The agent connects the user’s input to the local environment’s context (files, available tools) and provides it to the LLM. In this post, “agent” is a loop that takes user input, provides context to the LLM, and calls tools.
LLM: We all know LLMs like Claude, ChatGPT, or Codex. “LLM” stands for “large language model”. “LLM” is a misnomer. Many of these models accept multiple types of input and produce various outputs. A more accurate name is “Large Multimodal Model”. The models we use for coding are autoregressive, meaning they predict the following sequence based on previous context. For consistency with vernacular usage, I’ll refer to them as LLMs.

AI: Distinguishing the Agent from the LLM

In the diagram below, the “environment” is your computer and the tools you let your agent use. If you’ve given your agent access to find, for example, it will show up in the list. Depending on the agent, it might also collect some project stats to send to the LLM.

When you have a CLAUDE.md or AGENTS.md file, this will get sent with the context, too.

sequenceDiagram
    participant U as User
    participant AS as Agent
    participant E as Environment
    participant LLM as LLM (API)
    
    U->>AS: "Fix bug in auth.js"
    
    box rgba(0,0,0,0.05) Your Computer
      participant AS as Agent
      participant E as Environment
    end
    
    Note over AS,E: Agent Orchestration Layer<br/>Manages loop, provides tools, maintains context
    loop Until task complete
        AS->>LLM: Context + Available Tools + User Request
        Note over LLM: Parse intent<br/>Reason about next step<br/>Choose tool to call
        LLM->>AS: Tool call decision
        AS->>E: Execute tool (view/edit/bash)
        E->>AS: Return result
        AS->>AS: Append result to context
    end
    
    AS->>U: "Fixed: added null check<br/>Tests passing ✓"
    
    Note over U,E: Different agents = different tools, autonomy levels,<br/>and orchestration strategies (even with same LLM)

Notice that most of the work actually happens on your own machine. The agent interacts with your environment to collect information to send to the LLM, makes edits, and reports back.

An agent is not intelligent. This is really important to understand. An agent without an LLM is a loop with conditionals. Much like the code we write every day.

Adding an LLM into the loop gives the agent the ability to reason and make decisions beyond pattern matching.

Every agentic coding company will write its agent differently. The tools available, the actions the agent takes, and the system prompts it sends to the LLM are the product the company builds.

Cursor is different from Claude Code because Cursor’s agent is different, even if they both use a Claude model to reason and make decisions.

The LLM Reads the Entire Conversation Every Time

The LLM is an outside actor. If you are using Cursor or Claude code, every message you send and every agent loop involves API calls to the LLM provider you are using. If you are running a model locally, the model is separate from your agent system.

Every time the agent calls the LLM API, it is the first time the LLM has ever seen your message. The LLM reads THE WHOLE MESSAGE THREAD EVERY TIME.

That’s right. Do you have a long-running conversation where you’ve worked on three or four different tasks? When you ask the agent a question, the LLM reads the whole message thread and can easily confuse instructions you previously gave it with your current task.

In my experience, this is the most common reason agentic coding starts as highly accurate and quickly degrades into chaos.

How do you fix this? Start a new chat. It’s that simple. Start a new chat for every task you work on.

Warp has a great feature in its agent that detects a change in subject and suggests starting a new chat. I wish other agents would do that too.

This is an important distinction to make. The agent’s capabilities and system prompt affect how it works. Cursor tends to be very ambitious, which means the context window can quickly become bloated with failed attempts and misdirection.

More cautious agents will confirm actions with the user and detect when the conversation is drifting, keeping the context focused on the task at hand.

No agent is perfect, which is why I’ve explored using the Jujutsu VCS to give the agent memory between sessions and narrow the context the LLM receives on each turn.

sequenceDiagram
    participant CC as Agent
    participant LLM as LLM (API)
    
    box rgba(0,0,0,0.05) Your Computer

    end
    
    Note over CC: Context:<br/>[System prompt]
    
    CC->>LLM: [System prompt, User: "Fix bug"]
    LLM->>CC: "I'll check the file"
    Note over CC: Context:<br/>[System, User,<br/>Assistant]
    
    CC->>LLM: [System, User, Assistant, Tool: file contents]
    LLM->>CC: "I'll edit line 42"
    Note over CC: Context:<br/>[System, User,<br/>Asst, Tool,<br/>Asst]
    
    CC->>LLM: [System, User, Asst, Tool, Asst, Tool: edit result]
    LLM->>CC: "Fixed! Tests passing"
    Note over CC: Context:<br/>[System, User,<br/>Asst, Tool,<br/>Asst, Tool,<br/>Asst]
    
    Note over CC,LLM: Each API call sends the ENTIRE context<br/>Context grows with every message<br/>and tool result.

Key Principles

The diagram below illustrates the capabilities of a coding agent. The Agent Loop is the central capability. This is the part that each company builds (Claude Code, Cursor, Zed, Warp, etc.)

The LLM is separate from the agent loop. Many different agents can use the same LLM, and most agents let you pick which LLM to interact with.

flowchart LR    
    AgentLoop[Agent Loop] --> LLM[Calls LLM]
    
    AgentLoop --> AL1[Stateful Orchestration]
    AgentLoop --> AL2[Maintains state and history]
    AgentLoop --> AL3[Executes tools]
    AgentLoop --> AL4[Manages context window]
    
    LLM --> L1[Stateless Reasoning]
    LLM --> L2[Processes full context each turn]
    LLM --> L3[Selects tools & plans actions]
    LLM --> L4[No memory between calls]

Conclusion

Try lots of agents! I know this can feel slow and frustrating, but when you do this, you are learning how different agents work. You are learning the new tools you can use in your job.

Take 15 minutes each day to build a small project with an agent. Pick something simple, like a to-do list app. Build the same app with different agents and see how they perform.

In the future, I think we will standardize on a handful of coding agents that developers can pick to work with their preferred workflow, much as we have standardized on a handful of IDEs for different use cases.

I prefer Claude Code for its built-in protections and customization options.

If you want an agent integrated in your IDE, you can run /ide to hook Claude Code up to VSCode. It’s not as deeply integrated as Cursor is, but it works okay. Another good option is to try out Zed, their agent has similar capabilities to Claude Code and is built into the IDE.

I’ve tried Warp a few times, and the deep integration of chat, CLI, and editing is promising to me, but sometimes confusing.

In the end, Vim is my home row, so the setup that works for me is Claude Code in one pane and Vim in the other.

Use Jujutsu to Plan and Build with Claude

Sun, 26 Oct 2025 12:58:00 +0000

This week, I read about Steve Yegge’s Beads.

I was skeptical.

He writes like someone trying to prompt inject your LLM. But he’s always written that way.

I tried beads, and it was pretty good. I wrote all of uplift using beads.

But it was also pretty buggy. I noticed I had multiple bd daemons running and checking git status. Not cool.

Jujutsu

I shared beads with Nate Smith, and he said, “You could do that with Jujutsu.”

We both tried it and it rocks.

Here is my current CLAUDE.md , which teaches Claude to use Jujutsu to plan and track issue progress.

Jujutsu is a Git-compatible version control system. The graph foundation of Jujutsu makes it perfect for this kind of work because Claude can add empty TODO commits along the way and connect them to one or more tasks that also need to be done.

Here is the gist of the instructions Claude gets:

Planning Best Practices

Create Descriptive Empty Commits:

Each commit description should fully explain what needs to be done

Include acceptance criteria in the description

Note any dependencies or prerequisites

Use clear, actionable language

The steps for you are:

Enter plan mode and build a plan with Claude.
When you’re ready, tell Claude to make empty commits for each step in the plan.
Tell Claude to work through one commit at a time until it is done.
If at any point Claude struggles or decides to compact memory. Kill your session and start a new one with “We are in the middle of working through a to-do list created in jj. Find the task you were in the middle of and finish it, then move on to the next task until you are done.

On Friday, I refactored a small Ruby library with Claude and Jujutsu, and it was really nice. I knew what I wanted the end state to look like and described that to Claude. Claude then made a plan with detailed acceptance criteria for 12 distinct steps. Once I approved, Claude turned the plan into jj commits and worked through them.

Around step 7, Claude slowed down and suggested that steps 7 through 12 were tightly coupled. I ran /clear to start a new session and pick up where we left off. Claude still saw that steps 7 through 12 were coupled, but no longer tried to implement them all at once. It methodically worked through the steps.

At the end, Claude suggested a five-PR stack so developers could review PRs implementing the requirement in separate logical steps.

Why This Works (My Theory)

Steve Yegge is right about why this works, but more than a little off base about needing a whole buggy go program to do it.

Claude works better with this workflow because the context you send is focused and clear. A big old markdown doc is fine, but Claude has to read the whole thing multiple times to find the next task.

With the Jujutsu workflow, Claude can read a summary of what is done with jj log and pick up the following task with jj edit

The LLM on the other side of the Claude agent receives a more focused context. As the conversation continues, the thread narrows to specific tasks.

In past work, when I’ve used a plan.md or Claude’s default todo list, Claude struggles because it reads the entire plan every time, multiple times, since the whole chat is sent to the LLM with each message. This means the context gets bloated with planning and loses focus on accomplishing tasks.

With the Jujutsu workflow, planning shows up exactly once in the context. Then jj log shows incremental progress.

I Want This

It’s good! You should try it. Get Jujutsu set up and copy my CLAUDE.md.

If you don’t know how to use Jujutsu, Claude can learn by using jj help.

The most important thing to remember is: if you think the agent is lost, you’re probably lost too!

You can /clear your session, take a break, and start fresh. Claude will pick up where it left off because it knows to use jj log to find the next task.