Approve the Plan After Lunch. Open One Pull Request With Your Coffee.

On September 18, Deliveri's founder approved a plan for nine tickets at 2:14 in the afternoon. By 4:20 the next morning, Nebula Swarm had built all nine, had a separate agent review every step, sent work back whenever it fell short, merged them into a batch branch and opened one pull request for a human to read. This page walks through that run, using the run's own log.

  • 2:14 PMPlan approved · Thu Sep 18
  • 4:15 AMLast ticket merged · Fri Sep 19
  • 4:20 AMBatch PR opened

Real run, anonymized · Deliveri, Sep 18–19, 2026 · All times US Eastern (EDT, UTC−4)

[Video: screen recording of the run, ~4 min]

The Request: Tell Customers When Their Package Will Arrive

After "did it ship?", the question a seller and their buyer care about most is "when will it get there?" Deliveri's order page answered it badly. Only UPS supplied an estimate, it showed at one order status and vanished once the package moved, USPS stored no estimate at all, and the dashboard's "Est. Delivery" cell was really showing the time of the last tracking scan. The founder wrote a short product spec with every decision already made: save the courier's first estimate, its latest prediction and the actual delivery date; show the estimate from the first scan until delivery; and say plainly when the date moves and how delivery compared with it. The spec was already split into nine ready tickets. Nebula Swarm's job was to build them.

The Plan: Nine Tickets, Three Levels

Before any code, Nebula Swarm's planner turned the nine tickets into a dependency plan, and a separate reviewer checked it. The reviewer rejected the first two drafts. The second was rejected for two critical problems: an ordering rule between three tickets that edit the same dashboard file was written only in prose, where the scheduler would never see it, and one setting would have quietly made all nine tickets run one at a time. The third draft passed, and that is the one the founder approved.

Scroll sideways to see the whole plan →

Dependency plan for the nine tickets Level 0: tracking number from the label on (DLC-697), date formatter and day-gap helper (DLC-699), store the three delivery dates (DLC-698). Level 1: Pending Pickup over the pickup date (DLC-706), tracking card shows the estimate (DLC-702), USPS saves its delivery dates (DLC-700), UPS saves its delivery dates (DLC-701). Level 2: dashboard shows the real estimate (DLC-704), delivered row compared with the estimate (DLC-703). The critical path is DLC-698, then DLC-702, then DLC-703. Level 0 · 3 at once Level 1 · 4 at once Level 2 · 2 DLC-697 · needs nothingTracking number from the label on DLC-699 · needs nothingDate formatter + day-gap helper DLC-698 · database changeStore the three delivery dates DLC-706 · needs 699, 697"Pending Pickup" over the date DLC-702 · needs 698, 699Tracking card shows the estimate DLC-700 · needs 698USPS saves its delivery dates DLC-701 · needs 698UPS saves its delivery dates DLC-704 · needs 698, 699, 706Dashboard shows the real estimate DLC-703 · needs 699, 702Delivered row vs. the estimate
Needs the other ticket's code or data Same file, so they take turns Critical path
Arrows are drawn between neighbouring levels only; each box lists everything that ticket waits for. The database change gated five of the other eight, so it sits on the critical path with the tracking-card work that depends on it.

Scroll sideways to see the whole night →

When each ticket ran, drawn to scale Horizontal lines from 2 PM Thursday to 4:30 AM Friday, one per ticket, from the start of its planning to its merge. Three tickets start at 2:14 PM. Four run together from 9:11 PM. The last merges at 4:15 AM, and the batch pull request opens at 4:20 AM. Red circles mark the four times the reviewer sent work back. 2 PM 4 PM 6 PM 8 PM 10 PM 12 AM 2 AM 4 AM Tracking number Delivery-date columns Date helper Pending Pickup USPS dates UPS dates Tracking card Dashboard estimate Delivered row DLC-697: 2:14 PM to 5:23 PM DLC-698: 2:14 PM to 9:08 PM DLC-699: 2:14 PM to 5:28 PM DLC-706: 5:28 PM to 9:48 PM DLC-700: 9:11 PM to 1:52 AM DLC-701: 9:11 PM to 12:44 AM DLC-702: 9:11 PM to 1:15 AM DLC-704: 9:48 PM to 1:43 AM DLC-703: 1:15 AM to 4:15 AM 3:25 PM: reviewer sends the date helper back 11:10 PM: reviewer sends USPS dates back 11:16 PM: reviewer sends the tracking card back 2:42 AM: reviewer sends the delivered row back 2:14 PM plan approved 4:20 AM batch PR opened
Level 0 Level 1 Level 2 Planning starts · merged Reviewer sent work back
Each line runs from the moment Nebula Swarm started planning that ticket to the moment it merged into the batch branch. Each ticket went through its own plan, build and review before merging. At the busiest point, four tickets were in flight at once.

The Night, Hour by Hour

Every entry below comes from the run's log. The highlighted ones are the moments the reviewer, a separate agent that reads the code and the evidence cold, refused to pass a ticket and sent it back to be fixed. Each one was fixed in the same ticket before it merged.

  1. 1:45 PMThu Sep 18

    Planning starts. The planner reads the nine tickets and drafts the dependency plan. The plan reviewer rejects two drafts before approving the third.

    Planner + Plan reviewer

  2. 2:14 PM

    The founder approves the plan. The three level-0 tickets start at once, each with its own branch and its own planning step.

    The founder → Orchestrator

  3. 3:25 PM

    Sent back · Date helper

    An odd input could show a customer "1 day undefined". The helper's guard against bad input let some values through, and the existing test only tried one of them, so the suite stayed green.

    Fixed in the same ticket: an explicit check before the lookup, plus tests for the cases that slipped through.

    Reviewer · DLC-699

  4. 5:23 PM

    First ticket merged: the dashboard shows the tracking number as soon as a label exists.

    Merge agent · DLC-697 · PR #261

  5. 5:28 PM

    Date helper merged. That unblocks "Pending Pickup", which starts planning straight away.

    Merge agent → Orchestrator · DLC-699 · PR #262

  6. 9:08 PM

    Database change merged, adding three new delivery-date columns. The founder merged this one by hand. Five tickets were waiting on it.

    The founder · DLC-698 · PR #263

  7. 9:11 PM

    Three more tickets start in parallel: USPS dates, UPS dates and the tracking card. With "Pending Pickup" still running, four tickets are now in flight.

    Orchestrator · DLC-700 · 701 · 702

  8. 9:48 PM

    "Pending Pickup" merged. The dashboard-estimate ticket, which edits the same file, takes its turn and starts.

    Merge agent → Orchestrator · DLC-706 · PR #264

  9. 11:10 PM

    Sent back · USPS dates

    One failed save would lose a delivery date for good. If saving the dates failed on a package's final "Delivered" check, nothing would ever retry it, even though the code comment promised the next check would.

    Fixed: the failure is now logged with the dates needed to repair it by hand, the comment and docs say what really happens, and a test covers the case.

    Reviewer · DLC-700

  10. 11:16 PM

    Sent back · Tracking card

    The screenshots showed the card on its own, not on the real pages. The run required proof on both the order page and the order drawer, and a box the drawer's width isn't the drawer.

    Fixed: new screenshots with the card mounted in the real order page and drawer, with the widths measured, plus a test that both show the same thing.

    Reviewer · DLC-702

  11. 12:44 AMFri Sep 19

    UPS dates merged.

    Merge agent · DLC-701 · PR #266

  12. 1:15 AM

    Tracking card merged. The last ticket on the critical path, the delivered row, starts.

    Merge agent → Orchestrator · DLC-702 · PR #268

  13. 1:43 AM

    Dashboard estimate merged, followed at 1:52 AM by USPS dates.

    Merge agent · DLC-704 · PR #265 · DLC-700 · PR #267

  14. 2:42 AM

    Sent back · Delivered row

    The demo showed a delivery that couldn't happen. The sample screens read "Delivered On: Sep 24" above a tracking history saying the package was delivered on Aug 19. Production can't produce that, so the screenshots proved nothing.

    Fixed: sample data that matches real deliveries, and fresh screenshots of both pages.

    Reviewer · DLC-703

  15. 4:15 AM

    Delivered row merged. All nine tickets are in.

    Merge agent · DLC-703 · PR #269

  16. 4:20 AM

    One batch pull request opens, carrying all nine tickets, one changelog entry for the batch and a summary of what the founder should check.

    Orchestrator · PR #270

The Morning: One Pull Request to Read

The founder didn't read nine pull requests. Each ticket had already been reviewed, tested and merged into a batch branch overnight. What was left was one pull request and a written summary.

  • 49 product files changed across the web app, the Node backend and the Go services, with 9,966 lines added and 595 removed. The agents' own run notes are counted separately.
  • 13 new test files, and 3 existing test files extended.
  • One database change, adding columns only.
  • A short list of things to check by hand, including a look at the live tracking card, since the screenshots came from the component library, not the running app.

The founder merged the batch into the main branch that evening.

PR #270 · changelog

PUBLIC · Added · The Tracking card on the order page and in the order drawer

The order page and drawer show the courier's Estimated Delivery Date

Your order's Tracking card now shows an Estimated Delivery Date row with the courier's first estimate of when the package will arrive. When the courier updates their prediction and the date moves, a second line shows "Now arriving Sep 24, 2026 (2 days later)" or "(1 day earlier)" in amber or green.

One of six entries the run wrote for the batch: five for customers and one internal.

What It Cost

Only what the run's files show. The run kept no token or dollar log, so we don't quote one.

MeasureValue
Wall clock, plan approved to batch PR2:14 PM Thu to 4:20 AM Fri. About 3 hours of it, one ticket sat waiting for the founder to merge it.14 h 06 m EXACT
Tickets built, reviewed and merged9 of 9 EXACT
Most tickets in flight at once4 EXACT
Written reviews3 on the plan and 128 on the tickets, covering their plans, test plans, builds and final reviews.131 EXACT
Reviews that sent work back2 on the plan, 85 on the tickets. Four of them are in the timeline above.87 EXACT
Model spendNot logged. Founder-reported: Deliveri runs Nebula Swarm mostly on one Claude Max 20x plan.— FOUNDER-REPORTED

Those 87 send-backs are where the extra work goes: each one named gaps the author had to close before the work could move on.

Counts come from the run's status log and the review and verdict files in each ticket's run folder. Times are converted from UTC to US Eastern (EDT).

How to Run Your Own

The same three steps work on your backlog. We set them up with your team during the rollout.

  1. Pick ready tickets Choose tickets whose specs are written and whose decisions are made. Nebula Swarm won't guess at product calls; it builds what the spec rules.
  2. Approve the parallel plan Nebula Swarm drafts the dependency plan and has it reviewed. You read one diagram and approve it before the day ends.
  3. Review in the morning Every ticket arrives built, tested and independently reviewed, in one batch pull request with a summary of what to check.
See How Nebula Swarm Works See the Rollout Agenda

Run Your First Overnight Batch With Us

On a scoping call we'll look at your backlog and tell you plainly which tickets are ready for an overnight run, and which need a decision from you first.

Book a Scoping Call Read the Deliveri Story