Fleet Engineering Is Insane... The Next Evolution Of Vibe Coding

[00:00:00]We never run claude code in just one session and our whole team works this way. While one session is busy, we're reviewing what another just handed back and sending it the next thing to work on. So nobody's actually waiting on a single agent. That's the whole point because your time stays fully used while one session works and you deal with another. But the second you run them in parallel, you run into problems and nothing looks wrong on the surface.

[00:00:22]Every session seems busy and the output reads fine, but underneath they get in each other's way and you don't catch it until something's broken. And even when they're not stepping on each other, you still hit a point where you've got so many sessions going that you lose track of what each one is doing or what each one was even for. So, like always, we had to find ways to manage it. And some are already built in, while others are outside tools that work insanely well.

[00:00:45]If you don't know us, we're a software company. and this is our channel AI Labs where we show you how to optimize your processes with AI just like we've optimized our own. So in this video we'll go over everything we use to keep a bunch of sessions running in parallel without them falling apart. If you're working with multiple clawed code sessions at once, there's a bunch of problems you usually run into. You don't know which session you're in or what each one's actually doing. It gets hard to keep up with all of them and the output they're giving you. Sometimes you need to come back to a specific session that had some important context and you don't remember where you saved it. And if you've started too many sessions, you can easily forget what this one was even for. But that's just keeping track of them. The real trouble starts when they're all working at the same time.

[00:01:27]Because if you're using multiple sessions, you already know they don't share live context with each other since they each have their own memory. So if all your context and settings are in the global claude.md, basically the main instructions file Claude reads to understand your project or any other file that one session keeps updating, the other sessions won't know that context changed. They won't refresh from the global files on their own. So they just keep working off the outdated info.

[00:01:52]Each session only reads the global files at the start or later if you manually ask it to. And if they need to edit the same files, they'll end up overwriting each other's changes, too. Now, claude code isn't just for coding anymore. So, you can use multiple sessions for non-coding stuff as well. But in the coding task specifically, the complexity of the issues really start to add up.

[00:02:12]So, that's why we've split this video into two parts. First, we'll go over how to get past the basic issues you face just using cloud code in general. And then we'll focus on the problems you hit in your coding tasks and how you can fix them. And the solutions we cover in the general section are going to help you with the coding tasks as well. So, we'll start with the basics. You probably already know some of these, but they're what everything else builds on, and we get into the more advanced stuff right after. If a session gets closed for some unexpected reason, you don't actually lose it. You can pick the last one back up by running the clawed command with the continue flag, and it'll continue the last session you had running on your device. And if you want a specific session instead of just the last one, you run the clawed command with the resume flag, which lets you resume one from a list. or you can add the session name right after it to jump straight back into that exact session with all its context. Once you're back in a session, you might not even remember what it was doing. So to catch back up, you just run the recap command in your terminal and it gives you a quick summary of what that session was working on. And if you want to move from one session into a new one, but carry everything over, you use the export command. It basically turns your whole chat into a text or markdown file which you can then drop into a new session so it picks up where the old one left off.

[00:03:24]They're all really basic commands, but in day-to-day use, they make a big difference to both your productivity and what the model gives back. Take the animations in our videos. They're built with an internal animation system and clawed code. So, when we go back to change an animation, we resume the session we built it in or continue it if it closed on us. And if it's been sitting so long we can't remember what that session was even doing, recap catches us back up. But let's say you've got multiple sessions all working on the same shared file. Now you don't want them to collide or overwrite each other's changes. So you decide file ownership right at the start. You give one session ownership of a file and that's the only one allowed to change it. The rest can read it and use it as a reference, but they can't write to it.

[00:04:05]And you set this up by just telling each session right in its prompt not to write to those files. Now, let's say you're building something from scratch that's got independent parts, the kind of thing you can build in parallel to get it done faster. In that case, the workflow our team follows is to first make a plan using Claude codes plan mode. During planning, you give the agent all the information you have about the task, and you ask it to break that down into independent tasks that each session can run in parallel to hit one single end goal. This planning and breakdown phase really matters because it gets you an almost perfect setup for your sessions to work on without fighting over files or overwriting each other's changes. It also makes sure every session has the same shared context it needs to finish the task. Once the planning is done, you hand over each independent task to a separate session so they can all work together to finish the whole project.

[00:04:55]And to do that, we use the handoff skill. Now remember the export command from earlier. Handoff is basically the smarter version of that. Export just dumps your whole chat into a file. So the new session inherits all that messy slowed down context. Handoff actually compresses everything into a clean handoff document that points to your existing files instead of copying them in. So the new session starts fresh and focused. That document holds all the necessary information plus references to the files tied to that context and it even lists the skills the agent should install to get the task done properly.

[00:05:27]You install the skill with this command and then invoke it in your session using the handoff keyword. So once planning is done, you just ask your planning session to create handover documents for each task with the handoff skill and it generates one handover document per task, each pointing back to the plan file it made. Now to actually hand each task off to a separate Claude session, you use the Claude agent dashboard. The dashboard is basically an interactive interface right inside your terminal where you can see all the sessions currently running in the background. You can move through them or open anyone to see what it's working on. You open it using the claude agents command and you'll see a list of sessions that are either finished or still running. You can also type in a prompt and it'll launch a background claude code session for it. So you point it at each handoff document separately and it starts working toward your final goal in parallel across different sessions. All of which you can keep an eye on from the dashboard. You can also start background sessions another way by running the claude command with the background flag and then your prompt. And if you're already in a session and want it to keep running in the background, you just use the bg command which is short for background and it carries on running in the background and leaves your terminal free. Either way, you can see all your background sessions and how they're progressing in the dashboard. Using this workflow, you can break down almost any task into smaller pieces and control them from the clawed agent dashboard. So those fixes cover you for general use.

[00:06:49]But the moment you're actually building software, a whole new set of problems shows up on top of the ones we just talked about. When you run multiple clawed code sessions on the same project, they can trample over each other by editing the same files. They overwrite each other's changes because they don't have the context of what the other sessions are doing. If you've got a remote GitHub repo, which means your code is online, then the sessions also start fighting when they have to push new code online and when they have to switch GitHub branches. One session might push to one branch while another switches to a different one and that quickly messes up your branches and your whole repo. And if you're running the app on local host and you've got multiple localhost servers going, they'll try to kill each other because they all want to start on localhost 3000. All your cloud sessions also share the same project dependencies. So if one session swaps out a dependency or changes how the whole app is built or changes the database, the other sessions break because they've got no idea that change ever happened. To overcome these development specific issues, the first solution we have is git work trees. Git work tree is a built-in git feature that lets you work on multiple branches at the same time, each in its own folder, all from the same project on your computer. So instead of cloning the whole project into a separate folder every time you want a different branch, each branch just gets its own folder and you don't have to keep switching back and forth. To use work trees, you can just ask Claude Code to create a new work tree for you and then you can start your experimentation in that work tree.

[00:08:14]So when you're running multiple sessions, each one works in its own separate work tree. That means they can't override each other's changes by editing the same files and they won't clash over branches either because each session has its own isolated copy to work on. And if you're enjoying the video so far, subscribe to the channel and hit the hype button. This small gesture of support goes a long way for us. Work trees stop your sessions clashing over code, but you're still the one manually handing each task to each session. OpenAI Symphony automates that part. You might have heard of this tool already, but we've never actually covered it on the channel. It's an open-source orchestrator, which is basically a system that manages a bunch of coding agents working at once, and it was built for OpenAI's own Codeex agents. The main idea is that your to-do list becomes the single place that tracks everything. So, it shows the live progress of every session working on it.

[00:09:03]That way, you can see how much is done and how much is left, and it makes sure all the tasks stay independent of each other. Symphfony does this through linear, which is a project management tool where each column stands for the current state of a task. and OpenAI built according to the harness engineering principles which just means the whole code base is planned then written and then also tested by AI agents instead of people. Now since Symfony is open- source someone made their own version of it that works with clawed code. What it does is run a demon which is basically a background process that's always running on your computer and it keeps checking the issues in your GitHub repo which are the tasks you make there. So if a new issue shows up with a specific label like to-do, it automatically launches a background clawed code session and starts working on it. Then it creates a separate branch for that task. And when it's done, it opens a pull request, which is basically asking to merge its finished work into your main code. But work trees and the symfony forks only fix part of the problem. Work trees just stop your sessions overwriting each other's files and causing git chaos, and the forks just smooth out your workflow. The sessions will still break when one of them makes a dependency change, and they'll still fight over each other's local host servers. To actually solve these development problems, you need sandboxing. That's basically running the agent in a disposable, fully isolated copy of your development environment, so it can work on its own without touching your real machine. And for that, we use Docker Sandbox, who also sponsored today's video. Each sandbox runs on a dedicated microVM with a hard security boundary. Meaning when Claude installs packages or builds the project, all of that stays contained inside the sandbox and your real system is left untouched.

[00:10:41]It's the only sandboxing approach that lets a coding agent build and run containers while staying isolated and it pairs naturally with Claude Codes parallel sub aents each in its own git workree. To install Docker Sandbox on your computer, you run the installation command and then you log in with this command. Once you're logged in, you create a sandbox with the sbx command using the name flag, then your sandbox name, then claude. Once it's launched, the AI agent you talk to runs inside that isolated sandbox. By default, the agent inside the sandbox writes its changes straight to your working tree, meaning your actual project files. To take it a step further, Docker sandboxes give you clone mode. When you create the sandbox, you add the clone flag and it makes the sandbox with a clone of your project. That way, any changes the agent makes inside the sandbox don't touch your real files. They only happen inside the clone. Now, let's say you need to build a big feature in your app and you're thinking about manually firing up multiple clawed code sessions to do it.

[00:11:38]You don't really need to do that anymore. The models today are powerful enough to handle that whole workflow for you because their ability to spin up and manage different sub aents or tasks has gotten really better. Nowadays, you can just ask claude code to plan out the entire feature first, then take each subtask one by one, spin up a Docker sandbox for it and hand that subtask to the sandbox. That way, every subtask gets done in its own isolated environment and the changes don't affect what the other sessions are doing. That same planning session acts as the orchestrator, managing all the sandboxes and pulling in the changes from each one. When a sandbox finishes its work, the planner can delete it once it's confirmed the task is done. And while the sandboxes are running, you can watch their progress from the sandbox dashboard. Now, all the skills and workflows and everything else we build and show you in these videos can be found in AIABS Pro, which is our community. That's where you'll get the resources, the starter packs, and more, along with a place to interact with a bunch of like-minded people, including our team. So, if you found value in what we do and want to support the channel, this is the best way to do it. The links in the description. That brings us to the end of this video. If you'd like to support the channel and help us keep making videos like this, you can do so by using the super thanks button below.

[00:12:49]As always, thank you for watching and I'll see you in the next one.