The setting
builds delivery drones and the hardware and software that run them, for businesses, healthcare providers and governments. is a loading pod at partner sites where packages are left for pickup by Zipline's autonomous aircraft.
Passing tests leave reviewers uncertain about what a result-format change actually covers.
Faster preparation protects engineering capacity, while explicit coverage gaps protect the evidence used to release production testers.
Who you’d be doing this for
“I’ve already scheduled two people for the first pickup shift, and we’re still waiting for the unit to be cleared.”
Dalia Ndungu · Fulfillment Shift Lead · a character in this brief
Prepares staff to use newly installed package-loading hardware at a partner business.
What is at stake
Engineers reviewing test software retrace result fields even when checks pass. You decide whether AI can mark a path as covered from code analysis, or only after an executed test supports that claim.
Why it isn’t already fixed
Every obvious fix costs something else. That’s the part you’d have to decide.
- current-version simplicity vs. supported firmware compatibility
- broad behavioral insight vs deterministic reproducibility
- realistic replay vs production tester availability
- concise markings vs visible uncertainty
Why Zipline
Production test evidence connects delivery-pod software changes to the reliability of hardware installed at expanding partner sites.
Written with these in mind
Not your kind of problem? 94 more at Zipline, or browse every organization.
Where the organization context comes fromThe postings this brief was written from, and the reporting read before it.
The organization context comes from public information. The situation and characters are written for the brief.
Job postings it was written from
Public descriptions of the work at Zipline. They are listed as sources, not as openings. The lines under a posting are its own words, where it meets this brief.
- Staff Motion Planning Software Engineer (opens in a new tab)
- Design safety-critical software for avoiding obstacles and interfacing with humans while delivering and picking up packages
- Software Engineer Intern (Spring 2027) (opens in a new tab)
- Software Engineer, Production Test (opens in a new tab)
- Working closely with electrical, mechanical, firmware, quality, and manufacturing partners, you will debug test behavior and maintain traceable software changes across production testers.
- You will develop reproducible test flows, instrument interfaces, data logging, and MES integration, and carry that software through tester validation, deployment, and sustainment.
This is the setup. The work is inside.
Running it puts you in the room: the full situation and its constraints, stakeholders who push back in their own words, and the decisions that are yours to make. What you produce becomes a Day One Plan — work you can show someone instead of describing.
Where similar work appears
Other live briefs connected to this one, and what connects them.
Similar problems at other organizations
Like this one, each of these turns on crossing a deadline that can't be undone.
Reviewers repeatedly reconstruct lifecycle context across Python services and PostgreSQL records.
You must decide at which point in preparing a review the AI's assembled context stops and an engineer's own reading of the audit events and approval states begins.
Seven of twelve reviewers could not reconstruct approval evidence in the audit dry run.
You have to weigh a review people can complete under release pressure against evidence that survives a later challenge.
Known Buildkite failures are consuming release-cut time while reviewers rebuild the evidence by hand.
You must decide which runbook steps AI can perform and where an engineer must take over.
The same setting, from another role
Each is set around Zipline’s Dropbox Package-Loading Product, written for a different role. They’re separate briefs, not the same scenario.
Access-related alerts are arriving without enough connected evidence to classify quickly.
You must decide where the route stops: at correlating field notes, photos and records, at suggesting a severity, or at the point an engineer first sees the case.
Incomplete issue reports are sending field support into visits without enough context to triage the problem quickly.
You decide where an issue's notes, photos, and Fleetdeck context stop being enough for the intake to route it and start needing a field support supervisor or flight operations lead to read it first.
Repeat repairs and crowded loading areas are disrupting autonomous pickup at busy partner sites.
You must weigh site preparation against the technician time needed for urgent equipment failures.