My LLM workflow

I’ve been running Claude Code on multiple GitHub issues simultaneously using git worktrees, and it’s changed my development workflow. If you’re curious about the setup, read on.

I really enjoyed reading How I 10x My Engineering With AI because Kieran articulated something many of us are grappling with: the transition from traditional development workflows to AI-assisted ones. It got me thinking about documenting my own journey through this rapid adoption of AI tooling - especially since my approach has evolved quite a bit from the tools I mentioned in my April checkpoint.

Harper’s post about the developer’s codegen monomyth perfectly captures this journey. Having chatted with a number of my peers, I’ve noticed patterns emerging - many have reduced their Cursor usage and leaned fully into ‘agent’¹-driven workflows.

The most fascinating thing is that we’re all essentially vibing our own productivity, with wildly different results depending on workflow choices. Here’s how my workflow works, and why I think this approach hints at where AI-assisted development is heading.

Claude Code + Git worktrees

For the most part, I’ve settled into a workflow that heavily leverages Claude Code with git worktrees. If you’re not familiar with worktrees, they’re a git feature that lets you have multiple working directories for a single repository - basically, you can check out different branches in separate directories simultaneously without the usual branch-switching disruption.²

I know there have been a few references to them in Anthropic docs, but I hadn’t seen much chatter about them. I know a few heavyweight implementations like uzi³ and Claude Squad exist, but I wanted something lightweight that didn’t involve managing yet another binary.

My current workflow

The first lightweight implementation I came across was @jlehman_’s tweet and his subsequent gist. I really, really like this idea because it allows for the LLM to manage the worktrees. While the custom Claude commands worked, Claude would sometimes get confused about where the worktree lived, and I’d end up with changes bleeding into my primary repository. I also stumbled upon this helpful git worktree pattern field note in the Claude Code GitHub issues which got me most of the way there - I didn’t adopt the git-worktree-merge script because I had a slightly different workflow than the OP.

For a single project, my current process looks like the following:

1. Grab the work - Retrieve all GitHub issues (filter or ID)
2. Create isolation - Spin up a fresh worktree for each issue.
3. Deploy the agent - Echo a prompt into a Claude Code instance with –print and –dangerously-skip-permissions; even better yet, use a dev container.
4. Break time! - Make coffee, weed the yard, etc.
5. Review and ship - When all the issues are completed, jump back into each worktree, review the changes, and if they look good, use a few custom user commands for Claude to commit using conventional commits and file the pull request.

You might be wondering why I didn’t automate that last step - it’s because I prefer maintaining oversight of changes before shipping. In addition, if the agent does ‘go off the rails’, at the very least, I have a starting checkpoint to begin the work.

The beauty of this approach is that it lets me spin up isolated environments for different features or experiments without conflicts, all while allowing a human-in-the-loop to observe the changes being made. All the work I want the machine to perform is captured in GitHub issues.

While I can’t claim a 10x improvement (how would you even measure that?), and while not novel, this workflow has definitely cranked up my output.

Some of the benefits include:

• Have a starting point on every issue in my most active repositories
• Tackled issues in private repositories I haven’t touched in years
• Using this custom Claude command, fixed linting + type issues across a number of repositories

Currently, my only limiting factor is my token budget.

Implementation details

Note: You’ll need the GitHub CLI.

To accomplish the workflow above, I rely on a few Bash scripts (that Claude wrote for me, so PRs accepted!).

• github-issue-processor - The command center to run my workflow
• git-worktree-llm - I use this to manage creating / switching into a git worktree. Note: source this script in a Bash function to keep the cd into a worktree
• custom Claude user commands - Run these commands after jumping back into the worktree (or send them in as the prompt)

Notes

# How I run the script
$> ANTHROPIC_API_KEY=<foobar> CLAUDE_PROMPT_FILE="./do-work-prompt.txt" github-issue-processor.sh

# Example prompt (mine is a bit more complex using thinking tokens ie think, think-hard, ultrathink, etc.)
$> cat do-work-prompt.txt

1. Open GitHub issue.
2. Post a detailed plan in a comment on the issue.
3. Write robust, well-documented code.
4. Include comprehensive tests and debug logging.
5. Practice TDD.
6. Confirm that all tests pass.
7. Use commits as a form of checkpointing. Commit often.

I also export a bash function called git-worktree-toggle to source the git-worktree-llm:

# Bash function sourcing the script to not open it in a subprocess (for cd, etc.)
git-worktree-toggle() {
  source /path/to/git-worktree-llm "$@"
}

Tools I’m not using

While I have Cursor installed and Avante.nvim loaded in Neovim, I barely touch them beyond using them as a glorified autocomplete. When Claude Code can’t complete a task headlessly, I switch to interactive mode. If that fails, I use Claude Desktop for the final tweaks before copying back to my editor.

Model diversity

There’s growing evidence that using a consortium of models might yield better results than relying on a single one. To enable this in Claude Code, I’ve been experimenting with Claude Code Proxy, a nifty proxy that lets you route requests to Gemini or OpenAI models (via LiteLLM) while still using your Anthropic client. I still need a better way to quantifiably evaluate all of this so the jury’s still out on whether this meaningfully improves outcomes, but it’s been interesting to see how different models complete the same coding problem. Since different language models excel at different tasks, in the future, I expect multi-model workflows to become standard.

What’s next

As the landscape is constantly changing, I’ll be iterating on this workflow (or writing another post!).

While I’ve enabled Claude Code in GitHub Actions, I wanted to review their SWE-bench Verified/Terminal-bench results to better understand what I should tell Claude to route to the automatic action.

While this setup works for me in single-player mode, I’d love to see what others are doing in this space in multiplayer mode - I can only imagine what a mob programming situation might look like.

I think multi-model is where we’re headed - sending the same prompt to multiple models, capturing those changes in git branches, having a council/judge select the best, then automatically merging to main.

1. What’s your current workflow(s), and how are you leveraging these tools?
2. Are you doing anything interesting with git worktrees and similar isolation patterns? I was thinking about spinning these up in Morph Cloud.

I’d love to hear about your LLM workflow.

Hope to see y’all next time!

This post was written by yours truly; spellchecking, grammar-policing, title, and hook completed by AI.