The build stopped waiting for you

You're in the delivery studio. What this chapter is: write a ticket AI can actually finish, define "done" before the build, compute status from the checks (not the room), and attach hours and dollars to one shipped function. A spec is the written ticket. An acceptance check is a named test of "done." You do not need Jira to start.

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, the status call, and the value question are the slow parts — which means they're your parts. This chapter turns the loop 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, a roll-up that computes RAG status from acceptance records instead of asking the room how everyone's feeling, and an hours-and-dollars receipt for one accepted function — before/after hours, finance's loaded rate, a named owner, what actually shipped — small enough to read out loud in a staff meeting this week.

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 25.1% and completion 12.2%, with quality significantly improved — 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.
• This studio drills acceptance before ship. Every AI deliverable has to clear the checks written at spec time — ACCEPT, ACCEPT-WITH-NOTES, or REWORK — before it leaves the room. Fluency is not a pass. The move from "can prompt" to "can accept or reject" is the move this chapter writes as code.

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.
• It reports value the way it reports progress: confidently, and in the wrong units. Token counts and "40% faster" slides are the watermelon of ROI — green on the outside, no named function underneath. Hours and dollars only count when they attach to something that shipped, someone who owns the row, and a loaded rate finance already defends. Company-wide savings with no rows under them are not a receipt.

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.
• Write the hours-saved receipt for one accepted function: before/after hours, finance's loaded rate, a named owner, and what actually shipped — and refuse to total rows that cannot survive a staff meeting.

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. This is one role's loop, made runnable — not a company-wide transformation slide.