Product manager
Turns the PRD into a backlog of stories with acceptance criteria and measurable goals.
Nebula Swarm: A Full Engineering Team, Installed in Your Repo.
Nebula Swarm is an agentic engineering harness. It gives your AI coding tools a product manager, an architect, developers, a tester and an independent reviewer, then makes them work the way a good team does: plan first, build in small tickets, review everything, write down what they learned. Every one of those steps serves one outcome: higher-quality software. In Deliveri's first six weeks, that meant 7,673 automated tests and 0 production rollbacks.
It installs into your repository and runs in the terminal inside your IDE, on the AI models you already pay for. We set it up with your team in a one-day on-site Rollout.
Works Where You Already Work.
No new IDE and no new chat window. Nebula Swarm drives the coding CLI your team already uses, files its work in your tracker and opens pull requests on your Git host.
- AI models and CLIs:
-
- Claude Code
- OpenAI Codex
- Gemini CLI
- GitHub Copilot
These four work out of the box. Nebula Swarm also runs on other models, including DeepSeek and local LLMs, when you point one of these tools at them. Work in progress is saved in files, not held in a chat, so you can switch models mid-task.
- Dev tools:
-
- GitHub
- Jira
- Confluence (read-only)
Jira and Confluence are optional. Nebula Swarm has its own ticket board and project memory, kept as plain files in your repo.
- IDEs:
-
- VS Code
- Cursor
- JetBrains
- Any terminal
One Lifecycle, Four Phases, Humans at the Gates.
Every piece of work goes through the same loop. Agents do the drafting, building and checking. People make the calls that matter: approve the plan, answer open decisions, merge the pull request.
-
Plan: turn a PRD into tickets.
Several planning agents draft and challenge the plan; the strongest parts become one plan and ordered tickets.
PM · architect · UX · dev manager
You approve the plan.
-
Build: each ticket on its own branch.
Plan, build and review per ticket, several tickets at once.
developers · architect · reviewer
You approve each ticket plan, or let autopilot run.
-
Test & Review: nothing merges unchecked.
Tests mapped to requirements, an independent reviewer, your CI, a human merge.
tester · code reviewer · you
You merge.
-
Learn: write down what happened.
What each ticket taught the team is written down before the next one starts.
the whole crew
Project memory, in plain files in your repo. Updated after every ticket, so the next ticket starts smarter than the last one.
The loop runs per ticket. Learn feeds the next Plan.
A Written Plan Before Any Code.
You bring a product requirements document. Nebula Swarm turns it into a reviewed plan and a ticket backlog your team can read, argue with and approve.
Many Drafts, Merged Into One Plan.
You type /prd-extend. Several planning agents draft and challenge the plan in parallel, and the strongest parts are merged into one.
- Several planning agents draft in parallel. They draft and challenge the plan side by side, so no single view decides it.
- The strongest parts become one plan. Where the drafts disagree, the conflict is settled and the reasoning is written down.
- Gaps are closed and open decisions are put to you. You settle the open questions before anything is built.
- The plan becomes tickets, in order. Each ticket carries acceptance criteria, the PRD sections it comes from and the tickets it depends on. They land in Jira, or on the board in your repo.
Every Ticket Gets Its Own Mini-Project.
Tickets don't go straight to a coding agent. Each one is planned, built and reviewed in its own isolated workspace, and several run side by side. Run /dev-task for one ticket, or /dev-autopilot for many at once.
- Its own branch and workspace. Each ticket is built in its own isolated workspace, so parallel tickets never step on each other.
- Plan the ticket. Every ticket is planned before it's built. The code reviewer sends the plan back until it passes.
- Build it. A developer agent writes the code against the approved plan. The code reviewer checks it and sends it back until it passes.
- Run your checks. Your own lint, type, test and build checks run before anything is committed. Failures go back to the developer.
Autopilot: Many Tickets, One Approval.
Pick a set of tickets, or everything that's ready, and run /dev-autopilot. Nebula Swarm works out which can safely run side by side, shows you that plan once, then takes each ticket through plan, build and review on its own. Overnight work lands as one pull request for a person to review.
At Deliveri the goal is to keep the crew working around the clock: queue approved work before signing off, review it in the morning, and queue the next batch. In the last 14 days measured, at least one agent was working about 12.5 hours a day on average, and the agents logged about 32 agent-hours of work a day across parallel tickets. Jason Brown estimates that one author keeping it running around the clock could complete 9–18 tickets every 24 hours (founder estimate, running around the clock); five authors, the most the base license covers, could have 45–90 a day (estimate, not measured), if there's enough approved backlog, a person reviewing and merging, and enough model and plan capacity. [confirm: founder estimates 16–19 hours a day including the second director's machine, which the audit didn't capture]
Checked by Someone Who Didn't Write It.
The agent that writes the code never approves it. Review is a separate agent with a separate brief, and the last word is always a person's. This is where Nebula Swarm's quality comes from: the reviewer won't pass a ticket while a fixable problem remains, so fixes happen on the ticket's own branch, before the work reaches main or your users.
Adversarial Review on Every Plan and Every Pull Request.
Every reviewer is a separate agent whose job is to find what's wrong and say exactly what to change. Work goes back until it passes, and nothing is approved while a fixable gap is still open.
None of them grade their own homework.
In this run, the code reviewer sends the dev manager's plan back with two gaps. Plan v2 fixes both, and only then does it come to you for approval.
Who Checks What.
The plan
From the planning agents
Checked by the code reviewer, before any code
The code
From a developer agent
Reviewed and tested, before it can merge
The merge into main
Every change, before it lands
A person on your team reviews it and merges it
Work goes back until it passes, and a person steps in if it can't. Only approved work moves on to the next step.
Why Does Nebula Swarm Do All This Extra Work?
Because it produces better software. Nebula Swarm is built to catch problems before they merge, not after.
What you get is code your team can trust, and room to take on more complex products. Optiverse, the real-time desktop app for options traders that our co-founder Claudio Cannizzaro built with Nebula Swarm, is one example.
In Deliveri's first six weeks on Nebula Swarm, nothing was rolled back in production, and both hotfixes fixed dev, not production.
Doesn't all that work slow it down? It doesn't need to be fast. Nebula Swarm keeps working overnight and on several tickets at once, so your team's capacity is set by the clock, not by how fast anyone types.
- Requirements mapped to tests. Every ticket records which PRD sections it serves. The tester agent writes a test plan that covers every acceptance criterion, then writes and runs the tests.
- An independent code reviewer. The reviewer reads the pull request against the approved plan and your conventions, and sends the work back with a written report while a fixable problem remains.
- Reviewed and tested, every time. Every change is reviewed and tested before it can merge. A failed check sends the ticket back to the developer.
- Nothing quietly dropped. A finding that genuinely can't be fixed in this ticket becomes a new ticket in your backlog.
- Your CI, then a human merge. Nebula Swarm, by default, never merges to main on its own. The pull request goes through your CI and waits for your team.
- developer
- reviewer
- tester
- your CI
- your engineer merges
The Team Remembers.
Lessons and project knowledge are kept as plain files in your repo, so every ticket starts smarter. They're updated after every ticket and reviewed in the same pull request as the code.
The Crew.
Eight specialist roles, each with one job. You can add your own.
Architect
Shapes how the product fits together, then plans how each ticket gets built.
UX designer
Works out user flows, screen states and accessibility before any code.
Dev manager
Breaks the plan into small tickets, in order, and files them in your tracker.
Developers
Write the code for each ticket, backend and frontend, against the approved plan.
Tester
Maps acceptance criteria to tests, writes and runs them, and reports coverage.
Code reviewer
Reviews every plan and every change, and sends work back until it passes.
Doc writer
Plans and updates the docs that each change needs, with examples.
What Makes It Work.
Six choices sit underneath the lifecycle. Each one is built in, not a setting.
Multi-LLM.
Runs on Claude, Codex, Gemini or Copilot, with the same workflows on each, so you aren't locked in to one vendor.
In practice
- No vendor lock-in. Change AI tools without changing how your team works.
- Other models through the same tools. DeepSeek and local LLMs work when you point one of the four tools at them.
- Switch models mid-task. Work in progress is saved in files, not held in a chat, so a different model can pick it up. [confirm]
Token-Efficient.
"Deliveri runs Nebula Swarm mostly on a single Claude Max 20x plan."
Founder-reported, not measured.
More agents doesn't have to mean a bigger bill. The harness spends tokens on the work, not on re-reading everything.
In practice
- Each agent gets only what it needs. A developer works from the approved plan, not the whole planning history.
- On the plans you already pay for. It runs on your existing AI tools, and model usage is billed by your own provider.
Context Discipline.
Long AI sessions drift: the context fills up and quality drops. Nebula Swarm is built so no single session has to hold the whole job.
In practice
- No single session holds the whole job. Each step starts fresh with only what it needs.
- Long runs stay focused. Work doesn't pile up in one conversation, so the last ticket of an overnight run gets the same clean start as the first.
- Grounded in your code. What Nebula Swarm learns about an existing repo is tied to real files in it, so agents aren't misled by generic advice.
Extensible and Malleable.
Nebula Swarm is a set of plain text files in your repo, so you can read it, change it and add to it like any other code.
In practice
- Add your own agents and skills. They're plain files, written and reviewed like any other change.
- It runs your own checks. Your lint, type, test and build commands, and your house rules, are what every change is held to.
- It learns your existing repo. Your patterns and terms are recorded before the first ticket.
- Upgrades keep your changes. Updates refresh Nebula Swarm and leave your project memory alone.
Mono-Repo or Multi-Repo.
Works in a single repository out of the box. If your product spans many, an optional LightRAG knowledge graph, on a server you run, links them so agents can see across the boundaries.
That matters most when your services depend on each other. Agents planning a change in one service can see how the others work, so the change is planned against the real contracts between them.
In practice
- One graph, many repositories. Every repository you connect shares the same knowledge graph.
- Agents query it while planning. The architect asks how other services behave before it writes a plan.
- Answers say where they came from. Facts are labelled with their source repo; other repos are treated as contracts to respect, not code to change.
- Optional. It needs a LightRAG server you host. Without one, everything else works and the step is skipped.
Built for a Whole Team in One Repo.
Several people, each running their own agents, can work in the same repository at the same time without stepping on each other.
In practice
- Every ticket gets its own workspace. Each ticket is built on its own branch, apart from the others, so two builds never share files.
- A ticket is claimed once. Two people can't pick up the same work.
- Real code conflicts stop for a person. Nebula Swarm doesn't guess at a conflict; it hands it to someone on your team.
- Nothing lands on main directly. Every change arrives as a pull request a human merges, so the shared branch stays clean.
Nebula Swarm vs AI Coding Tools Alone.
AI coding tools are good at writing code when someone tells them exactly what to write. Nebula Swarm adds the parts of an engineering team that sit around the code.
| Compared | AI coding tool alone | With Nebula Swarm |
|---|---|---|
| What it's built for | Writing the code you asked for, quickly. | Quality first. Each change reaches your engineer already planned, tested and challenged. |
| Planning before code | Whatever the person prompting writes down, if anything. | A PRD becomes a reviewed plan and ordered tickets before any code is written. |
| Independent review | The same session that wrote the code checks it. | A separate reviewer agent approves or rejects every plan and diff, then a person merges. |
| Tests mapped to requirements | Tests when asked for, with no link back to the spec. | Every ticket traces to PRD sections; the test plan covers every acceptance criterion. |
| Project memory | Starts each session from scratch, or from one hand-written notes file. | Lessons and project knowledge, kept as plain files in your repo and updated after every ticket. |
| Multi-model | One vendor per tool. | The same workflows on Claude, Codex, Gemini or Copilot. |
| Jira and Confluence | Copy and paste. | Tickets created and moved in Jira, or on the built-in board in your repo; Confluence specs read directly. |
| Team trained | Each engineer works it out alone. | A one-day on-site Rollout trains your team on your own codebase. |
What Changed When Deliveri Installed Nebula Swarm.
- 7,673Automated tests added in Nebula Swarm's first six weeks, against 56 from the human team in two years.
- 0Production rollbacks over the same six weeks.
- 15.2 h → 3.3 h Median build time per ticket.
- 2.0 → 29.4 Tickets completed per week.
Human team (109 weeks) vs. first 6.2 weeks on Nebula Swarm. From git, GitHub, Jira and CI history. Rollbacks are counted for the Nebula Swarm period only; earlier periods have no deploy records. AI coding tools in general also helped; this comparison doesn't isolate Nebula Swarm's share.
See It on Your Own Codebase.
On a scoping call we look at your repositories, your roadmap and the AI tools you already pay for, and tell you plainly whether Nebula Swarm fits. If it does, we install it in one day on site and train your team on real tickets from your backlog.