Hello friends!

Welcome to another Sloth Bytes. I hope you’re having a good week.

If you’re new, or not yet a subscriber, or just plain missed it, here are some of our recent editions:

🦥 GPT-6 Astra and Claude Fable 5.1

🦥 What the heck is a software factory?

🦥 Debian might ban AI contributions tonight

ChatGPT is insanely powerful.

But most people waste 90% of its potential by using it like Google.

These 1,000+ proven ChatGPT prompts fix that and help you work 10X faster.

Sign up for Superhuman AI and get:

Claim your free prompts

2 minutes. Your URL. A customer profile worth using.

Most founders can describe their product. They can't describe their customer. Not in a way that actually changes how they sell.

HubSpot for Startups built a free tool to fix that. Paste in your URL, answer a few quick questions, and it generates a structured profile of your best-fit customer. Firmographics, buying triggers, the works.

Takes 2 minutes. No spreadsheet required.

Build Your Free ICP.

Git worktrees are having the best time of their lives.

A year ago, nobody knew they existed. You might’ve been using Git every day without ever touching one, or maybe you’d heard the name and said you’d learn it later.

Now worktrees have become essential for parallel-agent workflows and are probably the most used feature besides the big 3 (adding, committing, and pushing).

Which means it’s now something you should all definitely know.

Git worktrees let you work on different branches in separate folders at the same time.

Git added this command in 2015, and its original purpose was mainly fixing urgent bugs without disturbing unfinished work.

Coincidentally, it’s now a really good way to program with AI.

A working tree is essentially a copy of your project.

It looks similar to cloning the project again and creating another branch, but worktrees share the same Git repository.

Each worktree has its own files, staging area, and HEAD, which identifies its current checkout. They also share Git’s saved history and branches.

Let’s say you’re working on a sick new dashboard, but while testing it, you notice a login bug. Uh oh.

In order to create a worktree with the Git CLI, you would run these commands when you’re in the root of the sloth-app folder:

Your unfinished dashboard edits stay in the original folder. They aren’t copied into the new one.

Now you can go to the new worktree and confirm you’re on the new branch:

If it worked correctly, you should now be on the fix/login branch.

Edits you make to files here won’t change those files in your original folder.

Now you can make and push those changes with the same Git workflow:

Open your pull request normally, and hopefully merge that fix.

Keep in mind that the usual Git rules still apply. After the fix is merged into main, you still need to bring those changes into your dashboard branch.

After the fix is safely merged, stop any servers or agents running in that folder.

Before removing it, check for anything you need to keep:

This includes ignored files like .env. Save anything important outside the folder first.

Then return to your original project:

The extra folder is gone. Your original project is still there.

Removing a worktree does not delete its branch. You can delete the local branch separately once its work is safely merged:

If Git refuses, check why before forcing anything.

If the branch already exists, you can simply open a new worktree for that branch:

The main difference is we removed the -b flag from the command.

If you get this, then the branch is already open in another worktree. You can check what worktrees are open with:

Open the folder listed for that branch, or give your new task a different branch name. No need to force it. Git’s worktree documentation covers both situations.

If your project isn’t working correctly, it’s most likely because Git didn’t bring over your untracked .env file or installed dependencies.

You’ll have to set up development credentials and install what this branch needs.

For example, in an npm project with a matching lockfile, run:

That installs the dependency versions recorded in the lockfile.

Deleting the worktree folder doesn’t remove it from Git’s records. Luckily, it’s easy to clean up. You just have to run:

That removes stale records, not your active project folders, but next time use git worktree remove.

This is where worktrees get really useful.

Instead of giving an agent one task and waiting for it to finish, you can start separate sessions for different jobs.

Give each session its own worktree, and they can work at the same time without changing each other’s working files.

Something like this:

Think of it as each new task getting its own workspace. Follow-up prompts stay in that task’s session. Please don’t create another worktree every time you say “no, that’s not what I meant.”

While those agents work, you can keep building your dashboard or review whichever task finishes first.

Each agent’s changes are separate, so you can review and merge them without dragging along another agent’s unfinished work.

You can also give two agents the same problem in different worktrees, compare their approaches, and keep the better result.

Even though worktrees separate each agent’s changes, they don’t prevent merge conflicts or guarantee everything works together afterward.

This also means that you SHOULD STILL REVIEW THE CHANGES.

Two copies of your app may try to use the same port. Give each running app a different one.

For separate test setups, you might use:

Also, check the database connection before running migrations. A separate folder does not create a separate database.

An agent may still have permission to read neighboring folders or access credentials.

Use actual sandboxing when you need to restrict what it can touch. Worktrees alone don’t do that.

Put repeatable setup commands in your tool’s worktree configuration. Use development-only credentials, and read the commands before allowing them to run.

I know it’s obvious, but I’m saying this because every worktree contains dependencies and build files, which take up A LOT of space.

You absolutely can. I can’t stop you.

If you’re working on one thing at a time, that’s usually enough.

The difference is that creating a branch doesn’t create another folder. When you switch branches, Git updates the files in your existing folder to match the branch you selected.

This could cause problems like:

With worktrees, each task keeps its own files open:

So my rule would be:

No need to make Git more complicated than it already is.

That’s all from me!

Have a great week, be safe, make good choices, and have fun coding.

If I made a mistake or you have any questions, feel free to comment below or reply to the email!

See you all next week.

If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.