How We Measured Deliveri's Results

Every number on this site links here. Each figure is labelled as measured or estimated, each estimate states its method, and every caveat from the underlying reports is on this page, including the ones that make Nebula Swarm look less impressive. If a number isn't defensible, we don't quote it, and the last sections say which ones and why.

EXACT measured from a system of record
EST estimated, method stated
N/A could not be measured

Jason Brown, founder of Deliveri and co-founder of Sidera Labs · Data as of October 8, 2026

Three Periods, Not Two

We split Deliveri's engineering history at two dates that are visible in the record: the last human engineer's final commit, and the commit that installed Nebula Swarm.

2024-04-26 → 2026-05-29109 weeks
Human era
Starts at the first commit in any company repo; nothing exists before it, so per-week averages start there. Ends with the last engineer's final commit. Up to six engineers at the peak; from May 2025 one engineer made 97% of the commits.
2026-05-30 → 2026-08-2612.6 weeks
Plain Claude Code (transition)
No engineers. Two directors worked hands-on, and from 2026-06-10 drove Claude Code directly, with no harness. The code moved into a single monorepo from 2026-06-12.
2026-08-26 10:32 ET → 2026-10-086.2 weeks
Nebula Swarm
Starts at commit 8fafb458d (DLC-611), which installed the harness. The first Nebula Swarm run and the first overnight batch followed within a day. 44 days, 32 weekdays.

Why the transition is kept separate

The first agent co-authored commits by the directors are dated 2026-06-10, eleven weeks before Nebula Swarm was installed. If the human era ran right up to the Nebula Swarm cutover, it would include 12 weeks of AI-agent work and the "human" baseline would no longer be human.

Keeping it separate also answers the question most evaluators actually have: if you already pay for AI coding seats, what does a harness add? "AI agents vs our old team" and "Nebula Swarm vs plain Claude Code" are different claims, and we report both.

For completeness: if the human era is stretched to the Nebula Swarm cutover, it becomes 121.8 weeks with 437 completed tickets and 2,405 test cases, and Nebula Swarm's ticket multiplier falls to about 6.2× (on Jira weeks). We don't recommend that framing, because 12 of those weeks were already agent-driven.

Side by Side, Per Week

Same product, same Jira, three ways of building it. Rates are per week unless the row says median. Source lines are secondary and shown in grey; tickets, build time and tests carry the argument.

Scroll the table sideways →

Per week · Deliveri, both products (DLC + GEN)
Measure	Human era	Plain Claude Code	Nebula Swarm	Basis
Output
Tickets completed UAT or Done, DLC + GEN	1.97157 ÷ 79.6 Jira wk*	22.2280 ÷ 12.6 wk	29.4182 ÷ 6.18 wk	EXACT
Feature and capability tickets Story + Task	1.55	17.6	22.5	EXACT
Bug tickets	0.43	4.6	7.0	EXACT
Speed (median, not per week)
Build time per ticket Jira In Progress → complete	15.2 hn = 131	4.3 hn = 208	3.3 hn = 134	EXACT
Quality
Automated test cases added	0.5156 in total	~186 EST~2,349 in total	1,2427,673 in total	EXACT ESTtransition is EST
Reverts + hotfixes per merged PR matched on names, not on actual regressions	4.0%(2 + 8) ÷ 253	0.4%(1 + 0) ÷ 276	1.3%(1 + 2) ÷ 227	EXACTlabel-based
Production rollbacks	N/Ano deploy records	N/A	0	EXACTNebula Swarm only
Secondary
Source lines added tests, lockfiles, generated, migrations, vendored code excluded	2,268	8,891	15,025	EXACTfiltered

Complete means UAT or Done: the code is finished and deployed to dev. A ticket counts at its first move to UAT, or at Done if it skipped UAT. Epics and Won't Do tickets are excluded. The Genesis (GEN) project only started during Nebula Swarm, so all 68 completed GEN tickets fall there.

* Human-era Jira rates use the weeks Jira existed (from 2024-11-25, 79.6 weeks), not the full 109. Jira was barely used from June to December 2025, so the human rate is understated. Build time is like for like because both eras used the same Jira "In Progress" status. It measures time in progress only; Nebula Swarm also works several tickets in parallel.

Reverts and hotfixes, read honestly. Nebula Swarm's 1.3% is lower than the human era's 4.0% but higher than plain Claude Code's 0.4%. Nebula Swarm's two hotfixes both fixed dev, not production: one for deploy workflows still pointing at an old folder, one for a migration that crashed the dev migration run. Its one revert was to the harness's own workflow, internal tooling. The human team used "hotfix" loosely, often for styling fixes, which may overstate their rate. Neither era records actual regressions, and the PR unit differs between eras (see What Makes This Comparison Unfair, below).

Source lines favor the human era in the counting method: their lines are summed commit by commit, Nebula Swarm's come from squash merges. In the transition, two sync commits on 2026-07-18 imported about 26,000 lines from the old repos into the monorepo.

What Nebula Swarm Added Over Plain Claude Code

Most of the jump from the human era happened before Nebula Swarm: plain Claude Code already completed about 22 tickets a week. Credit that jump to AI agents in general. These are the further gains from the harness, with the arithmetic. Its largest gain is in tests: the tester maps every acceptance criterion to a test before any code is written.

~6.7×Automated tests added per week. Approximate, because the transition figure is an estimate.1,242 ÷ ~186 = ~6.7~186 = ~2,349 ÷ 12.6 wk EST
+32%Tickets completed per week.29.4 ÷ 22.2 = 1.324→ +32%
23% fasterMedian build time per ticket.(4.3 − 3.3) ÷ 4.3 = 0.233→ 23% less time

The transition's test count is the monorepo's count at the Nebula Swarm cutover (2,405) minus the human era's 56. It is approximate because code moved between repos. Bug tickets completed also rose (4.6 → 7.0 a week) and reverts + hotfixes per merged PR rose (0.4% → 1.3%); both are in the table above.

Nebula Swarm Against One Engineer

The human team shrank, so two-year averages mix a four-to-six person period with a solo year. This table corrects for that by comparing Nebula Swarm with one engineer's weekly output, two ways.

Scroll the table sideways →

Per week · one engineer vs Nebula Swarm
Measure	Per engineer, human era EST	Solo-engineer year EXACT	Nebula Swarm	Nebula Swarm ÷ one engineer
Tickets completed	1.0–1.3	0.99	29.4	22–30×
Feature and capability tickets	0.8–1.1	0.75	22.5	20–30×
Test cases added	0.22–0.29	~0	1,242	quote absolutes
Source lines added	963–1,263	1,500	15,025	10–16×

Per engineer EST: era totals divided by engineer-weeks. The low end assumes everyone active in a month worked all of it (257 engineer-weeks); the high end counts only weeks in which a person committed (196). Real effort is in between, because part-time and contract status isn't recorded. Ticket rates use the 117 commit-weeks inside the Jira period at the high end and about 153 at the low end EST.

Solo-engineer year EXACT: 2025-05-01 to 2026-05-29 (56.3 weeks), when one engineer made 97% of the commits, with a short-term contributor and a director making the rest. It's the cleanest one-engineer baseline, with no team coordination, but it covers the period when Jira was barely used, which lowers its ticket rate.

The Nebula Swarm column isn't zero people. A director spends an estimated 22 to 47 hours a fortnight directing the agents. Per director-hour, the ratios are smaller than per engineer-week.

What It Took, and What It Would Have Taken

~35 h/ fortnightDirector hands-on time, range 22–47 hours in the last 14 days (mid 35, about 2.5 hours per active day). EST
699agent-hoursAll parallel agents summed, last 30 days. 449 in the last 14 days. At least one agent was working in 285 of ~730 elapsed hours. EST
~10engineersLow end of the FTE range for the six weeks on Nebula Swarm, on standard 8-hour days. The full range is 10–19. EST

Sources: 5,022 Claude Code transcripts (140 sessions and their subagents) and Jira status history. Method below.

Director hours EST

Prompts typed by a human were grouped into sittings: prompts within 15, 30 or 45 minutes of each other count as one sitting, with 2, 5 or 10 minutes added per sitting for reading and thinking. That gives low / mid / high of 22 / 35 / 47 hours in the last 14 days (374 prompts on 14 days) and 51 / 77 / 103 hours in the last 30 days (846 prompts on 28 days).

Undercounts: reviewing and merging PRs in GitHub, Jira, hands-on browser testing. Overcounts: sittings that weren't engineering, such as PRDs, mockups and offer work. Since-Nebula Swarm total: N/A, because transcripts before 2026-09-08 are gone.

Agent-hours EST

Each gap of 5 minutes or less between consecutive messages in a transcript counts as working time; longer gaps count as idle. Summed across all parallel agents: 449 hours in 14 days, 699 in 30 days. Hours with at least one agent working: 183 of ~350 elapsed (14 days), 285 of ~730 (30 days).

Transcripts are kept for 30 days, so the since-Nebula Swarm figure is a floor (≥ 699). A second director's agent sessions run on his own machine and aren't included; he had no PRs in the 30-day window.

The FTE estimate EST

FTE = tickets completed ÷ (tickets per engineer per day × weekdays)

182 ÷ (0.6 × 32) = 9.5 → ~10 · 182 ÷ (0.3 × 32) = 19.0 → 19

Throughput assumption. A competent mid-to-senior engineer finishes 1.5 to 3 tickets of this size a week, including tests, review and PR overhead (0.3 to 0.6 a day). This is a working assumption: we found no credible public benchmark for tickets per engineer, because ticket size varies too much between teams.
Weekdays only. 32 weekdays since Nebula Swarm started, though the agents also ran on weekends.
12-hour days. If engineers worked 12-hour days, the range is 7–17. Output per engineer is assumed to be 1.15 to 1.35 times an 8-hour day, not 1.5, because research on long hours (Pencavel, 2014) finds output per hour falls sharply past about 50 hours a week.
Ticket size drives the spread. It alone accounts for the 2× range. Weighting the small Genesis tickets at half brings the 14-day, 8-hour figure from 14–28 to about 9–19.
Cross-check. Task PRs divided by LinearB merge-frequency benchmarks (1.2 to 2.5 merged PRs per developer per week) gives 13–27 on 8-hour days. Our PRs are much larger than LinearB's elite size, so this probably understates the human effort per PR.

That's why we say "output in line with a team of roughly 10 engineers": it's the low end of the since-Nebula Swarm range, on standard days, with the full method here.

What Makes This Comparison Unfair

No before-and-after comparison of a team is clean. These are every factor we found, and which way each one pushes the result.

Favors Nebula Swarm

Greenfield vs mature codebase: Humans built the product from nothing: 30+ repos, carrier API certification, infrastructure. Nebula Swarm works in an established monorepo with conventions, CI and a written memory of past decisions. External carrier work is slow regardless of who does it.
Multi-repo overhead: Human-era work was split across 37 repos with separate deploys. The monorepo removed that overhead before Nebula Swarm arrived (from 2026-06-12).
Team shrank to one engineer: Two-year averages include a solo year. The per-engineer figures above correct for this.
Quiet periods: September 2024 was nearly silent. Jira was nearly unused from June to December 2025. No repos existed from January to April 2024, which is excluded from the denominator.
Ticket size and Jira use: Nebula Swarm plans work as many small tickets, Genesis especially: 60 of the 92 tickets completed in the last 14 days are Genesis slices. Human-era Stories are often larger. Jira only exists from 2024-11-25.
Short Nebula Swarm sample: 6.2 weeks of a planned build-out, against 109 weeks that include maintenance and slow periods.
Director time: Nebula Swarm's output includes a director's hands-on time, which isn't counted as an engineer.

Favors the human era

Commit and squash habits: Humans committed small changes straight to develop; Nebula Swarm squashes on merge. Line counts sum human churn but only Nebula Swarm's net change.
AI tools already in use: Some May 2026 human-era commits, all from one engineer, carry Claude co-author trailers. Of the 56 human-era tests, 20 are in the backend, some from that AI-assisted work. Copilot or Cursor leave no trace in git and can't be ruled out.

Could favor either

PRs used differently: Human PRs were mostly release promotions (131 of 253 merged). Nebula Swarm opens one PR per ticket plus batch roll-ups. PR counts aren't compared directly.
Contractors and part-time work: Employment type isn't recorded, so engineer-weeks are given as a range.

Context

Most of the gain came before Nebula Swarm: Plain Claude Code already completed about 22 tickets a week. Credit the jump to AI agents generally, and the further increase to Nebula Swarm.
Production releases: Not a productivity measure. Releases are batched on purpose so each can be tested, and cadence is similar in both eras (about 0.6 a week). Work in UAT is on dev and goes to production in the next batch; 112 completed tickets were on dev at the time of the audit, planned for the 2026-10-09 release.

Numbers We Don't Quote, and Why

Some figures in the reports are exact and still misleading. These never appear in our marketing.

Commit counts

Nebula Swarm squash-merges every PR, so commits on trunk fall, while commits inside PRs include merge commits from syncing integration branches. Either way the unit isn't comparable with the human team's habit of committing straight to develop.

Instead: tickets completed.

PR multipliers

The human team used PRs mainly to promote releases. Nebula Swarm opens one PR per ticket, and its batch roll-up PRs re-merge the task PRs. A ratio of PR counts compares two different things.

Instead: tickets completed and build time.

Total lines changed

Agent run logs and memory committed to the repo add about 1.73 million lines since Nebula Swarm started, 18× the source code. Test lines are 2.2× source lines on their own.

Instead: filtered source lines added, as a secondary figure.

The test-rate ratio

Dividing Nebula Swarm's weekly test rate by the human era's produces a multiplier in the thousands. A ratio that large reads as a gimmick; the honest story is that the old codebase had almost no tests.

Instead: absolutes: 56 tests in two years, 7,673 in six weeks; 2,405 → 10,078 on main.

Created → complete time

It got slower under Nebula Swarm (4.3 days → 7.5 days median) because the backlog is planned weeks ahead and Genesis tickets were filed in bulk, then built 1 to 3 weeks later. It measures how far ahead work is planned, not how fast it's built.

Instead: In Progress → complete.

"All tests passing" and coverage

On 2026-10-08, CI on main was red: one Go test failed in the run for PR #390. No CI job collects coverage, so we have no coverage number. Neither claim appears on this site.

Instead: declared test cases, and executed counts from a dated CI run.

"Fewer bugs"

Against plain Claude Code, bug tickets completed rose (4.6 → 7.0 a week) and reverts plus hotfixes rose (0.4% → 1.3%). Neither era records actual regressions.

Instead: 0 production rollbacks, and both hotfixes fixed dev, not production.

Where Every Number Comes From

Two reports, both dated 2026-10-08: a before-and-after comparison across all of Deliveri's repositories, and a productivity audit of the six weeks on Nebula Swarm. [Link to the redacted PDFs, if we publish them]

Git: All 37 repositories in Deliveri's GitHub organization, cloned including every refs/pull/* head so deleted PR branches count. "Trunk" means commits reachable from main, master, prod, develop, dev or qa. The monorepo at origin/main 3803e9d10 for the Nebula Swarm audit.
Deduplication: The monorepo imported the old web app and backend histories, so duplicate commits were removed by matching author, subject, date and diff size. For test counts, identical files copied between repos are counted once. Known aliases of the same person were merged before counting people (11 distinct people across the human era).
Exclusions: The github-actions[bot] account (production image-tag syncs); no other bot accounts exist. The Claude Code git identity is treated as an agent, not a human. Epics and Won't Do tickets. For lines of code: lockfiles, build output and vendored code (node_modules, dist, build, .serverless, storybook-static, source maps), generated files (Swagger specs, changelog HTML/JSON, snapshots), migrations, binary assets, docs, agent run logs and agent framework files. No individual is named or ranked.
GitHub: 780 PRs across all repos (393 in the monorepo), with per-PR commit counts via GraphQL, and GitHub Actions history for every deploy and promote workflow.
Jira: 823 issues across projects DLC (customer app) and GEN (Genesis admin app), with full status history via REST v3. Jira starts on 2024-11-25. The human team filed features as Story; agent-era DLC work is mostly filed as Task, so Story + Task is the fair feature count.
"Complete": UAT or Done: the code is finished and deployed to dev. A ticket counts at its first move to UAT, or at Done if it skipped UAT. Build time is first "In Progress" to that moment. Production releases are batched by choice and aren't a productivity measure.
Tests: Static count of it( / test( declarations in *.spec / *.test files and func Test in Go. Each it.each table counts once and Go t.Run subtests are left out (416 more today), so it understates what runs. The human-era figure scans the last trunk state before 2026-05-30 in every repo. Executed counts come from CI runs 37781086749 (main) and 37798707490 (web suite) on 2026-10-08.
Lines of code: Per-commit numstat over trunk-reachable, deduplicated, non-bot commits with rename detection; for Nebula Swarm, git log --first-parent --numstat on main, bucketed by path. "Source" includes config, CSS, Terraform and workflow YAML.
CI: Logs of the two runs above, plus Actions history for every Promote and Deploy workflow. All four NEB-era production promotes succeeded; one staging promote failed on 2026-09-17 and succeeded on the re-run the next day.
Transcripts: 5,022 Claude Code transcripts (140 sessions and their subagents), kept for 30 days; the earliest surviving event is 2026-09-08 10:27 ET. Used for agent-hours and director hours only.
Benchmarks: LinearB Engineering Metrics Benchmarks and community benchmarks (PR cross-check). Pencavel, "The Productivity of Working Hours", Economic Journal, 2014; cited from memory in the audit, not re-fetched. [verify citation before launch]

We'll Measure Your Team the Same Way

On day one of the install we record your baseline from your own git, Jira and CI history, using these definitions. At day 15 and day 30 we show you the change, with the same labels and the same caveats.

Book a Scoping Call Read the Deliveri Story