Every parent knows this moment. You ask your kid to clean their room, they come back grinning and say it is done, and the floor really does look spotless, until you open the closet.
Last week my AI agents did the same thing. I opened the Image Studio launch that every agent on my “team” had signed off on, and the product in front of me was not the one we had agreed to ship. The FAQ look was off, a white border sat where it should not have been, the desktop split was missing, there was no dark mode, the slider did nothing, and where we had promised two examples there was only one, yet every check that had been run had still passed.
If this were your launch, that is the moment your board deck still says you are on track while a customer is about to find the gap instead of you, and your team is about to pay the rework tax in time, attention, and millions of tokens spent doing the work again. The agents were not wrong about what they checked. They were wrong about what ready meant for the whole room, closet included, and nobody had told them the difference.
We had rules. We still had to prove the agreed work was complete.
Saying something is ready falls short unless you can show it covers the outcome you already agreed to ship. Matching the exact commit under review is needed, but it is not enough on its own, because it only proves you looked at the right tree. It does not prove you asked the questions that protect the business result. That gap matters more as companies go AI first, because agents will give you speed along with tidy summaries and narrow passes that feel like progress while the agreed product is still incomplete.
How Image Studio actually shipped
I fixed the gaps I found inside the same change before it merged. Desktop got a draggable comparison divider so the split view and the slider finally did real work. We added a dark mode theme switch and fixed dark contrast and fullscreen. A second example called Glass bloom sat beside the first, and we rewrote the FAQ so it was truthful, including that it needs a connection to open.
Quality did not stop at a pass that only proved paths worked. QA built a checklist from the approved spec, the mockups, and the accessibility checklist, covering ten behaviors I had approved. Each one was checked in two browsers, in light and dark, and at desktop and phone widths. All ten passed, and the gaps from my open were folded into that set of ten, though I am not claiming a neat one to one map from six items to ten checks. Review cleared the exact commit under test, quality passed that same commit, I merged it, and the site deploy on that merge commit succeeded with production smoke checks on the Image Studio pages.
How the hidden infrastructure failures got fixed
In the same stretch of work, a quality pass on a heavy infrastructure change had rested on a single test file, so review blocked on a broken check and then found a second stale check sitting behind the first. The earlier pass was pulled back because the full set of affected tests had not been run.
The first stale check still expected eight routes on a function after a new route had made nine. The fix stopped bumping a count and instead checked that the new route goes to its own function, while the original function kept exactly eight. That let the suite reach the next test, which had counted functions and picked one by runtime, so we rewrote it to require three distinct functions, each with its own identity, role, and route. Final quality ran the full affected set on a fresh clone against the exact commit review had cleared, showed the test fails on the prior commit and passes on the new one, and passed, and that change merged.
How ready works in my shop now
Those two packages did not only produce code. They also shaped how I run the agents now, through human review habits rather than automated gates. Branch protection is off, and checkboxes in a pull request writeup are not a merge gate, so what holds is review discipline.
Proof must name the exact commit it ran on, with the commands and the raw output, and any new commit needs new proof. The full affected test set must be mapped and run before handoff to review. Approved changes go into the spec before review and quality. Every UI change gets a checklist from the spec and mockups before testing. Quality tests only the exact commit review cleared. A language or stack choice needs its own approval. Review clearance is never permission to ship.
If you are a leader or operator putting AI into delivery, ask which approved behaviors this pass checked, by name. Ask whether the full affected set ran, or only a slice. Ask which commit this proof ran on, and whether that commit is the one under review. Ask whether this is a review clearance or a ship decision. Ask who owns the check against the outcome the business already bought.
What ready means now
Ready means proven against the agreed outcome, on the exact commit, with proof from every test the change touches. In my shop that means we open the closet before we call the room clean. That is the verdict this week earned, and it is exactly what our services are built for, helping leaders going AI first turn faster output into delivery commitments they can stand behind.