Take your AI coding workflow to the next level

For a long time, I worked with one editor open and Claude Code beside it. One task at a time.

I tried using worktrees to work on several things at once. But each additional task brought more housekeeping: create the worktree, copy over the environment files, install dependencies, and open another session. Then get the changes into a PR and clean up afterward, before old checkouts and their node_modules folders filled the disk.

At that point it was easier to just skip the entire worktree workflow and work on a single branch at a time. But that was also annoying, as you just spend so much time waiting for Claude.

I wanted to make starting another task easy enough that I’d actually do it, with the setup, progress, and cleanup handled in one place. That’s what I built Farero for.

“

You just spend so much time waiting for Claude.

Starting another task

With Farero, I can start another task in its own workspace and let it run while I’m working on something else. Each workspace has its own branch, files, and conversations, so an unrelated fix doesn’t get mixed into the feature I was already working on.

The repository’s setup can be configured once and reused when creating workspaces. Things like installing dependencies and copying the environment files belong there, instead of being something to remember every time.

Then there’s keeping track of it all. With several terminal windows open, I’d have to go through them to see what was happening. In Farero, I can see which agents are working and which tasks need my attention, then open the conversation when I need the details.

When the work is ready, I can review the changes and get them into a PR. Afterward, I can archive the workspace and keep the conversation history. Starting more tasks is a lot more useful when finishing them doesn’t leave another pile of folders to deal with.

Browser QA alongside the implementation

But working on multiple things doesn’t always mean separate features. Sometimes it’s different parts of the same task.

Browser QA is a good example. An agent might spend quite a while opening pages, clicking through a flow, and checking that everything works. That’s useful work, but I don’t always need my main coding agent to do all of it.

Instead, it can hand the browser checks to a separate QA agent and continue with the remaining code and tests. The findings come back into the same conversation, so it can follow up on anything that failed.

I used this while working on how Farero updates its chats. One agent checked the behavior in the browser while the main agent continued fixing the code. The browser checks covered things like loading the chat, receiving a burst of updates, and reconnecting.

Different models for different parts of the work

This also gives me a reason to use different models. I can keep a stronger model on a difficult implementation and use a cheaper one for a focused QA assignment. The QA agent needs the right tools and a clear idea of what to check. It doesn’t need to take over the entire task.

Reviews work in a similar way. I can ask another agent to look at a change while the first one is still working, or get a second model’s opinion on an approach before going further. If they disagree, I can bring the findings back into the conversation and work through them.

The useful part is being able to do this without setting up another little workflow each time. Give the work a clear scope, let it run, and come back to the result.

There’s still plenty for me to do. I need to explain what I want, answer questions, look at the changes, and decide what’s ready. But I can spend more of the time doing that, while other work keeps moving.

Next time you’re waiting for an agent, try giving an unrelated task its own workspace. Or let a second agent handle the browser checks while the first one finishes the code. Start with something you can review, and see how it fits into your day.