AI writes code in seconds. So why didn’t it ship on Day 0?
Day0 is a delivery crew of AI agents and your team, working in one room, that checks, de-risks, releases and lands every change with customers. You pay only when a change lands.
Read-only GitHub access. We analyze pull request timing, not your code. About ten minutes.
Idea
Day −14 Debated in four meetings
Hour 0 Captured with customer evidence
Problem framing
Day −3 Spec rewritten twice
Hour 2 Framed, scoped and risk-scored
Code
Day 0 AI wrote it in 30 seconds
Hour 3 AI wrote it in 30 seconds
Review
Day 4 Waiting in the queue
Hour 4 Reviewed by the crew
Testing and CI
Day 9 CI red. Flaky test.
Hour 5 Verified in parallel
Release
Day 14 Shipped, then rolled back
Hour 6 Released behind a guard
Customers
Day 21 Still don't have it
Day 0 Landed with customers
35 days
Day 0
Illustrative example of one change. Hover to pause.
- 8.4×lines of code
- 3.4×commits
- 1.3×releases
- 1×customer usage
Demirer, Musolff and Yang, NBER, 2026. Day0 works on the part that shrinks.
“Lines of code grew 8.4×. Software releases grew just 1.3×, with no measurable change in customer usage yet.”
“Writing and testing code is only about 25–35% of the time from initial idea to product launch.”
From idea to customer, AI sped up one step. Everything around it still waits.
- 1Weeks of debate
Spot the idea
A customer need or business opportunity
- 2Specs rewritten, still manual
Frame the problem
The business agrees what to solve and why
- 3Commits +180–240%
Write code
Turn the plan into code
- 4Review time +441.5%
Code review
A colleague checks each change
- 5Time in QA +300.6%
Testing
Make sure it works
- 6CI jobs 25× in six months (Anthropic)
Build and integrate
Merge and run automated checks
- 7Deployments −11.7%
Release
Approve and ship to users
- 8Incidents per change +242.7%
Run and fix
Keep it running
- 9No usage gain yet
Customers adopt
People actually use it
Day0 works on steps 4–9.
Review waits grew more than fivefold. Problems per change more than tripled. Releases didn't speed up. That isn't a coding problem. It's a delivery problem.
Why 10× faster coding makes delivery about 1.4× faster
Picture a 100-day project. Move the sliders.
- Project length
- 73 days
- Overall speedup
- 1.37×
- Best possible
- 1.43×
Coding drops from 30 days to 3, but the project still takes 73 days: 1.37× faster, not 10×.
See your real ceiling from your GitHub historyA crew for everything after the code is written
| Crew member | What it does | What it hands you | How far it can act by default |
|---|---|---|---|
| Conductor | Moves every change to the next step, chases owners, escalates, forecasts dates | Status updates, “who's holding what”, delivery forecasts | Suggests and nudges |
| Spec | Turns a ticket into acceptance criteria and a definition of done | A checklist the change is judged against | Suggests |
| Context | Keeps a fresh map of your code, owners, tests, runbooks, incidents and customers | Cited answers to any agent or person | Answers only |
| Risk | Scores each change and picks a lane | Risk score, top factors, blast radius, rollback plan | Routes within your policy |
| Review | Does the first pass and prepares humans | A review packet: intent, risky lines, questions, test evidence | Comments |
| Test | Finds the tests that matter and the ones missing | Impacted tests, gaps, suggested tests | Suggests |
| Release | Plans flags and staged rollouts, watches guardrails | Rollout plan, next-stage approvals, rollback | Acts with your approval |
| Watch | Links incidents and reverts to the changes that caused them | Incident links with evidence, lane quality reports | Suggests |
| Adoption | Tells each customer what changes for them and tracks usage | Impact notes, release notes, in-app guide drafts, CS briefings | Drafts for approval |
Every crew member shows its sources. You decide how far each one can act.
Everyone who touches a release, in one live room
- R
Risk routed to human lane
Touches billing/proration.ts, a critical path. 2 past incidents here.
rcpt_7f3a · INC-412 · L88–131
- MO
Marcus @Risk why is this high?
- R
The change edits rounding in proration, and INC-412 in March came from the same function. Test coverage for annual plans is 41%.
Sources: INC-412 · coverage run 9a12c4e · CODEOWNERS
Approve 25% rollout
Release plan: 5% → 25% → 100%. Guardrail: payment errors under 0.2%.
ApproveHold
- See who's holding every change right now.
- Ask any agent why, and get its sources.
- Approve a rollout in the thread, not in a meeting.
- Unlimited seats. PMs, SREs and customer teams join free.
Send the routine through. Put people on what's risky.
Autoland lane
- docs: fix typo
- deps: bump eslint
- config: timeout 30s
- ui: button spacing
Human lane
- billing: prorationreview packet
- auth: session rotationreview packet
Day0 scores every change using what it touched, who owns that code, which tests cover it and what has broken there before. Low-risk changes take the Autoland lane. Risky ones go to a named reviewer with a packet that explains the intent, the risky lines and how to roll back.
Meta's published low-risk review lane has landed over 331,000 changes, reverted at a third of the rate of other changes.Meta's lane selected lower-risk changes, so this is not a causal result.
You set the thresholds. Day0 reports the defects that reach customers from each lane every week, so you can see whether the routing is earning its keep.
Ship code continuously. Release to customers on purpose.
The Release crew member plans each rollout in stages, watches error rates and your key metric at every step, and rolls back when a guardrail breaks. The Adoption crew member writes a “what changes for you” note for each customer segment, drafts release notes and in-app guides, and briefs customer success.
80%
In the average product, 80% of features are rarely or never used. A change hasn't landed until customers use it.
Measure delivery, not how fast it feels
In a controlled study, experienced developers believed AI made them 20% faster. The clock said 19% slower.
| If you track this | Day0 always shows it next to |
|---|---|
| Changes landed per engineer | Review wait and rework |
| Deployments per week | Change failure rate and incidents |
| Share of code written by AI | Code churn and duplication |
| Hours saved | Share of time spent on new work |
| AI spend | Cost per landed change |
Every landed change comes with a receipt: the PR, the risk call and its sources, who reviewed it, the tests, the deploy, the rollout and the 7-day check.
You pay when a change lands. Not per seat. Not per token.
- Unlimited seats
- PMs, SREs and customer teams join free.
- Billed after 7 days
- Only after a change stays healthy for 7 days.
- 3× back
- If a landed change causes a Sev1 or Sev2 within 30 days.
| Plan | Platform fee | Per landed change |
|---|---|---|
| Starter | $0 | $12 |
| Team | $400 a month | $10 |
| Scale | $2,000 a month | $8 |
| Enterprise | Custom | |
Critical and Micro changes are priced separately.
- Landed changes a month
- 756
- Monthly bill on Scale
- $10,437
Assumes 1.94 merged PRs per engineer a week and the default change mix.
Start with your delivery ceiling
Connect GitHub read-only. In about ten minutes you'll see where your changes wait, how much of your cycle is actually coding, and what a two-lane policy would have done to your last 90 days.