delivery studio
how a working delivery lead runs AI builders: specs with acceptance checks written before the build, a review that runs the checks instead of admiring the demo, status roll-ups computed from acceptance records instead of standup vibes, and the not-ready call made on evidence you can read out loud to a steering committee.
The build stopped waiting for you
For your whole career, delivery had a built-in speed limit: developers ask clarifying questions. Hand a vague ticket to a human team and someone pushes back by Thursday standup — "what does 'validates properly' mean?" Hand the same ticket to an AI builder and it ships a confident, plausible, wrong implementation before you've closed the tab. The pushback you were counting on is gone. Whatever ambiguity is in the ticket gets built, at full speed, exactly as ambiguous as you wrote it.
That flips where your leverage lives. When the building was slow, the PM's job was mostly unblocking. Now the building is instant and the spec, the acceptance check, and the status call are the slow parts — which means they're your parts. This chapter turns all three into code you run: a spec linter that blocks vague tickets before an AI wastes a night on them, a review gate that holds output against checks written before the build, and a roll-up that computes RAG status from acceptance records instead of asking the room how everyone's feeling.
Why it matters
- The evidence says AI delivery is jagged, and the delegation call is yours. A preregistered field experiment on 758 consultants at a major strategy firm (published in Organization Science, March 2026) found that on tasks inside AI's capability frontier, AI access raised speed about 25%, human-rated quality about 40%, and completion about 12% — and on one task deliberately chosen outside the frontier, AI users were 19 percentage points less likely to reach the correct answer. Same tool, same people, opposite result. Routing work to the right side of that line is a triage decision, and triage is a PM verb.
- The canonical delivery failure already has an invoice. In October 2025, Deloitte's Australian arm shipped a A$440,000 government report containing AI-fabricated references and an invented quote from a federal-court judgment. The firm repaid the final instalment — A$97,587.11 — after an outside researcher, not anyone on the delivery team, caught it. That wasn't a model failure. It was a deliverable that never met an acceptance check on its way out the door.
- Nobody else teaches the checking. The training market for AI-assisted client work grades slide formatting and sells prompt courses; no scanned commercial offering teaches holding an AI deliverable against pre-agreed acceptance criteria before it ships. The gap between "can prompt" and "can accept or reject" is exactly the gap between a coordinator and a delivery lead.
What AI specifically gets wrong
- It builds the ambiguity instead of surfacing it. "Make the export robust" becomes some implementation of robust, chosen by the model, discovered by you in review — or worse, by the client in production. An untestable acceptance criterion isn't a criterion; it's a deferred argument.
- It fabricates the parts you were trusting it on. The Deloitte report's citations looked exactly like real citations. Fluency is not evidence. A review that reads for polish will pass fabricated content every time, because fabricated content is polished — that's what generation optimizes for.
- It reports progress the way it writes prose: confidently. Ask an AI builder how the workstream is going and you get the textual equivalent of a green status dot. "90% done" from a model means even less than it meant from a developer, and it never meant much. Status has to be derived from artifacts — acceptance records, check results — because nobody's gut, silicon or otherwise, is an audit trail.
- It never says not-ready. The model will happily demo a workstream with two blocking checks failing. The no-go call has no autocomplete. It's a human reading real evidence and disappointing a room on purpose — the single most senior thing you do, and the one this chapter makes cheap by making the evidence undeniable.
What you'll be able to do at the end
- Write build tickets as data — goal, scope fence, owner, acceptance checks — and lint them so nothing vague reaches a builder: every check testable, every ticket owned, every scope boundary explicit before the first token of code gets generated.
- Triage tasks across the frontier: delegate what has checkable ground truth, pair-review what doesn't, and send under-specified work back for spec-first treatment instead of hoping.
- Run the acceptance gate: hold every AI deliverable against the checks written at spec time, return ACCEPT / ACCEPT-WITH-NOTES / REWORK with named failing checks, and stop a rework loop that isn't converging instead of feeding it forever.
- Generate the status roll-up from acceptance records — task RAG derived, workstream worst-of, project line computed — and make the go/no-go call with a blockers list you can read out loud, unedited, to the people who least want to hear it.
Every drill runs in plain Python, no Jira login required. The logic is the point: the same gate works whether it lives in a script, a ticket template, or the delivery platform your PMO buys next quarter.