Git Worktrees for Salesforce Devs: Run Three AI Agents at Once
>The AI isn't the bottleneck anymore. You are. Here's the workflow that lets three agents work three tickets at once without stepping on each other.
Ask a Salesforce developer what slows them down and they'll name the deploy, the org, the review queue. A year ago that was right.
It isn't right now. The agent writes the code faster than you can read it. Which means the slowest part of your workflow is the part that still runs at human speed, and that part is you.
Scott Covert put it as his hot take at the end of our conversation: "You are the bottleneck. Get out of your own way."
Scott is the founder of Tython, the Salesforce ISV behind Permissions Assistant, a security-reviewed access management app on the AppExchange with a free tier. He hosts Appsembly Line, the Salesforce ISV podcast. He ships a managed package for a living, which matters here, because the workflow below is what his team actually runs, not a conference demo.
The habit to break first
The standard flow is one branch at a time. You're three files into a feature, something urgent lands, and now you need a clean tree. So you stash.
It gets worse when the stash includes things that were never meant to be tracked, a tweaked .envor a local config, because now the drawer has your work and your machine's private state in the same pile. You come back two days later and you're doing archaeology.
The other escape is cloning the repo a second time. That works, and it means a second full download, a second set of dependencies, and no shared history between the two copies.
What a worktree actually is
A worktree is a sibling working directory that shares one Git history with your main checkout.
Not a branch. Not a clone. One repository, one .git database, several directories on disk, each sitting on a different branch at the same time.
git worktree add ../weather-forecast -b forecast git worktree list git worktree remove ../weather-forecast
That's most of the surface area. A branch checked out in one worktree is locked in the others, which is Git stopping you from having the same branch in two places at once.
This has been in Git since 2015. It isn't new, it's just unused.
The part that makes it work for Salesforce
Directories alone don't solve a Salesforce problem, because two branches still point at the same org.
So every worktree gets its own scratch org.
sf org create scratch -f config/project-scratch-def.json -a forecast -d 7
Now the isolation is real all the way down. Three tickets, three directories, three orgs, and nothing one agent does can touch what another is testing. Scott wraps both steps in a single script, so creating a worktree and its org is one command, and a second script tears the whole thing down when the sprawl gets out of hand.
There's a ceiling worth knowing about. You're capped by how many scratch orgs Salesforce lets you create per day, not by anything about worktrees. Scott's take on how many to run at once was three, with the note that there's no reason it can't be five if your limits allow.
Three agents at the same time
The live section of the episode is three real tickets against a weather proof of concept: a five day forecast, better error handling, and a new account weather card.
Each one gets a worktree, an org, and its own agent session. Then they run at the same time.
The moment that lands is small. One agent finished a ticket in about 40 seconds, while we were still reading the requirements on another one. Scott's framing: instead of starting a session, pasting requirements, and then sitting there watching it think, you go pull the next ticket.
That's the whole productivity claim, and it isn't about the agent being smarter. It's about you never being idle.
When an agent gets something wrong, and one did, the FlexiPage wouldn't cooperate, the move is the same. Tell it to fix it, then switch to another card while it works. You stop babysitting one process.
At the end, all three branches merge back to main, and the last scratch org standing doubles as your integration test, the first place all three changes exist together.
Where to draw the line
The back half of the episode gets into the part most parallel-agent content skips.
Running agents in auto mode across three orgs means three chances for something to go wrong unsupervised. Scott's own line is that a scratch org is the escape lever you designed on purpose, a throwaway environment where a mistake costs you nothing but a sf org delete.
Chase Brammer joined the closing Q&A and pushed back on the premise itself, asking whether a bottleneck is even a problem. It's a better objection than it sounds. A review step that slows you down is also the thing catching what the agent got wrong.
Where to start
You don't need the full setup this week.
- Next time you would stash, run
git worktree add ../hotfix -b hotfixinstead. Keep your main tree exactly as it was. - Once that feels normal, write the script that pairs a new worktree with a fresh scratch org. That one script is the whole unlock.
- Only then go parallel. Two tickets before three.
- Name your worktrees and orgs after the ticket, not after
test2. Sprawl is the actual failure mode here, and it arrives faster than you expect.
Worktrees are a Git feature, not a GitHub feature. This works the same on GitLab or Bitbucket, since the branching all happens locally.
Watch the full conversation
Building at the intersection of Salesforce and AI?
If this format is useful to you, subscribe on YouTube and sign up for the newsletter at revenueeng.com. New episodes and written breakdowns go there first.
Revenue Engineer is the community for working Salesforce professionals leveling up on AI-augmented development and modern GTM tooling. Weekly drops, live sessions, and a founding cohort opening soon. Join the waitlist and you'll be first in line.
Connect with Scott on LinkedIn, play with the demo repo, and if you manage access in Salesforce, his team's Permissions Assistant has a free tier. He also hosts Appsembly Line.
If you try worktrees on your own org, drop a comment on the YouTube video and tell me how many tickets you ran at once. I read every one.
// one email, no spam, first in line.