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, and landed the night's work as one pull request for a person to review. This page walks through that run, using the run's own log.

  • 2:14 PMPlan approved · Thu Sep 18
  • 4:15 AMLast ticket done · Fri Sep 19
  • 4:20 AMOne pull request 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, Mapped Before Any Code

Before any code, Nebula Swarm turned the nine tickets into a dependency plan, and a separate reviewer checked it. The reviewer rejected the first two drafts and caught two ordering problems before they shipped. 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 Can start first: tracking number from the label on (DLC-697), date formatter and day-gap helper (DLC-699), store the three delivery dates (DLC-698). Next: 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). Last: 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. First · 3 at once Next · 4 at once Last · 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
Waits for the other ticket Critical path
Arrows are drawn between neighbouring columns 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 the moment it was done. Three tickets start at 2:14 PM. Four run together from 9:11 PM. The last is done at 4:15 AM, and the 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 pull request opened
Starts first Starts next Starts last Planning starts · done Reviewer sent work back
Each line runs from the moment Nebula Swarm started planning that ticket to the moment it passed review and was ready for the morning's pull request. Each ticket went through its own plan, build and review. 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 could move on.

  1. 1:45 PMThu Sep 18

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

    Nebula Swarm + Reviewer

  2. 2:14 PM

    The founder approves the plan. The three tickets that need nothing else start at once, each on its own branch and planned on its own.

    The founder → Nebula Swarm

  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 done: the dashboard shows the tracking number as soon as a label exists.

    Nebula Swarm · DLC-697

  5. 5:28 PM

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

    Nebula Swarm · DLC-699

  6. 9:08 PM

    Database change done, adding three new delivery-date columns. This one waited for the founder's sign-off. Five tickets were waiting on it.

    The founder · DLC-698

  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.

    Nebula Swarm · DLC-700 · 701 · 702

  8. 9:48 PM

    "Pending Pickup" done. The dashboard-estimate ticket, which was waiting on it, starts.

    Nebula Swarm · DLC-706

  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 done.

    Nebula Swarm · DLC-701

  12. 1:15 AM

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

    Nebula Swarm · DLC-702

  13. 1:43 AM

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

    Nebula Swarm · DLC-704 · DLC-700

  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 done. All nine tickets are in.

    Nebula Swarm · DLC-703

  16. 4:20 AM

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

    Nebula Swarm · PR #270

The Morning: One Pull Request to Read

The founder didn't read nine pull requests. Each ticket had already been built, tested and reviewed overnight, and the night's work landed as one pull request for a person to review, with 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 that pull request 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 pull request2:14 PM Thu to 4:20 AM Fri. About 3 hours of it, one ticket sat waiting for the founder's sign-off.14 h 06 m EXACT
Tickets built, tested and reviewed9 of 9 EXACT
Most tickets in flight at once4 EXACT
Written reviews3 on the plan and 128 on the tickets. Every ticket passed review.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 own log and its written reviews. Every ticket was reviewed before it reached the morning's pull request, and the reviews are kept in your repo. 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 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