Case Study
LoopCodeLab: multi-agent software delivery
LoopCodeLab turns a plain-language requirement into working software. A planner agent breaks the request into stories, worker agents implement them in parallel on isolated git worktrees, and a reviewer agent checks and merges each change. One idea can ship to web, mobile and the app stores. You bring your own AI keys and own every line of the output.
Problem and context
Single-agent coding tools stall on anything larger than a snippet. They lose track of a multi-step plan, they work one file at a time, and there is no independent check on what they produce before it lands. Getting from an idea to something deployable still means a person stitching the steps together by hand.
I wanted a system that treats software delivery as a pipeline of specialised roles, the way a small team actually works: someone plans, several people build in parallel, someone reviews, and the result gets merged and shipped. The hard parts are isolation, so parallel work does not collide, and control, so a human can watch and steer.
Users and use cases
LoopCodeLab is for developers and technical founders who want to move from a requirement to a running application without babysitting every step. Typical uses:
- Turn a product brief into a planned set of stories and a first working build.
- Run several implementation tasks in parallel and have each one reviewed before it merges.
- Take one idea and deliver it to web, mobile and the app stores from a single workspace.
Because it is self-hosted and uses your own AI keys, it also suits people who need their code and prompts to stay on infrastructure they control.
My role
I designed and built the whole system: the agent roles and how they hand work to each other, the isolation model over git worktrees, the review-and-merge step, the web and phone workspace, and the self-hosted infrastructure it runs on. I also published smart-name, the zero-dependency npm package LoopCodeLab uses to turn an idea into a clean, DNS-safe project name.
Architecture
A requirement enters as plain language. The planner agent decomposes it into stories. Worker agents pick up stories and implement them in parallel, each on its own isolated git worktree so their changes never collide. A reviewer agent checks each change and merges it into the main line. The merged result is built and delivered to its targets.
How a build flows
- Plan. The planner turns the requirement into a set of discrete, buildable stories.
- Branch. Each story is assigned to a worker on its own git worktree, so parallel work is fully isolated.
- Build. Workers implement their stories concurrently, driven by AI CLIs over a tmux session bridge.
- Review. The reviewer agent checks each change against the story and merges it into the main line.
- Deliver. The merged build is compiled and delivered to its targets: web, mobile, and the app stores.
Every session is observable from a browser or a phone, so a human can watch progress and step in at any point.
Technology choices and trade-offs
The engine is webtmux: a Node.js service that bridges browser terminals to real tmux sessions over xterm.js and a PTY, exposed as an installable PWA and run under systemd. Git worktrees give cheap, first-class isolation without spinning up a container per task. Model routing lets each agent use an appropriate model, with bounded retries so a failing step does not loop forever.
- Git worktrees over containers for isolation: lighter and faster to create, at the cost of sharing the host environment.
- tmux as the execution substrate: real, inspectable sessions that a human can attach to, rather than a hidden subprocess.
- Bring-your-own keys: the user controls cost and data, and no keys live in the platform.
- Bounded retries and model routing to keep runs predictable and costs in check.
Deployment, reliability and security
LoopCodeLab runs on an Ubuntu server I administer. Nginx terminates TLS, the Node services run under systemd, and the workspace is reachable as a PWA from a browser or phone. Because agents drive real tmux sessions, a stuck or crashed run can be attached to and inspected rather than lost.
Reliability: parallel work is isolated per worktree, so one failing story does not corrupt another, and the reviewer step gives every change an independent check before it merges. Security: the platform is self-hosted and uses the operator's own AI keys, so prompts, code and credentials stay on infrastructure the user controls.
What I would improve next
- Richer observability: structured logs and metrics per agent session, not just an attachable terminal.
- A formal evaluation harness to score generated changes before the reviewer, reducing review load.
- Tighter per-worker sandboxing to move from process isolation towards full environment isolation.