← All work Daily driver

Four coding agents, one codebase, no collisions

Type
Desktop app · daily driver
Date
2026
Stack
Tauri 2 · React 19 · Rust · PTY orchestration
flightdeck · product showcase

The short version

Flightdeck is a desktop app that runs several AI coding agents at the same time on one codebase. Each agent works in its own isolated copy of the project on its own branch, so they cannot overwrite each other. I built it because running a squad of agents turns into a management job, and no tool I could find treated it that way.

It is the app I use every day. It replaced my editor as the thing I open first, and it is what I ran the six-week platform rebuild from.

The problem

Running one AI agent is easy. You give it a task, you watch the terminal, you approve things when it asks.

Running four is a different job. Three of them are waiting on an approval you have not noticed. Two of them are editing the same file. One has quietly gone down a path you would have stopped ten minutes ago. You end up doing nothing but tabbing between terminals, which is exactly the low-value work you started the agents to avoid.

Two things cost me time. Agents in the same working directory undoing each other's files, and not noticing an agent was stuck until it had been stuck a while.

What I built

1. Isolation by default. Every agent gets its own git worktree and its own branch. Same repository, separate working directory. Four agents can build in parallel and none of them can touch another's files, so parallel work stops being a merge risk and becomes the normal way to work.

2. One approval queue. The app watches every agent's output, detects when one is asking permission, and ranks the waiting prompts in a single list. Instead of hunting for the terminal that stopped, I answer a queue.

3. Review before merge. Nothing lands because an agent says it is done. A review screen shows every change as a side-by-side diff against the branch it came from, and I merge from there.

4. A board that dispatches. Work sits on a board. Sending a card to an agent starts it in a fresh worktree with the context already loaded, so the gap between deciding what should happen and something happening is a click.

5. Provider agnostic. Agents run as real processes under a PTY, the same way they run in a terminal, so it drives the coding agents I already use rather than reimplementing them. Swapping which model does the work is a per-agent setting.

6. Built as a desktop app, not a web app. Tauri 2 with a Rust core and a React 19 front end. It needs real filesystem and process access to do any of the above, and I wanted it fast enough to leave open all day.

Why worktrees and not containers

Containers were the obvious answer and I did not take it. Agents need the real repository, the real toolchain and the real dependency cache to be useful, and rebuilding that per agent is slow and fragile. A git worktree gives you the isolation that matters here, which is file-level and branch-level, at close to zero cost. Creating one takes about as long as a checkout.

The trade-off: worktrees isolate files, not the machine. Agents share the same OS, the same ports and the same credentials. For running agents against my own code that is the right line. For running untrusted code it would not be.

The result

Four agents in parallel is now routine, eight when the job is big enough, and the bottleneck moved from "can I keep them from colliding" to "how fast can I review". That is the right bottleneck to have, because reviewing is the part where my judgement is worth something.

The strongest evidence is the rebuild: a platform that took one to two developers about two years, rebuilt to the same spec in six weeks by a squad of eight agents I designed and ran. I could not have kept eight agents straight in terminal tabs.

One caveat: this is a tool built for one demanding user, me. It is not a product with a support line, and the parts I do not personally use are thinner than the parts I do.

Drive it yourself

The video above is the real application recorded end to end, with only the project data simulated. If you would rather push the buttons than watch, the demo below is the actual Flightdeck front end running in your browser against a scripted backend. Prompt an agent, work the board, open the review screen.

flightdeck · interactive · runs in your browser

This is the real interface running on simulated data. Nothing you click sends anything anywhere.

Tech used

Tauri 2RustReact 19PTY orchestrationgit worktree isolationside-by-side diff reviewxterm.js

Want the same squad pointed at your build?

Balu Premkumar, founder of Kove60-day warranty · pay the second half only on acceptance
Next case studyStop typing. Tell your machine what to do