Acceptance Criteria for AI-Assisted Development: Lessons from The Journey

A request such as "remember the visitor" sounds small. It leaves several product decisions unanswered. Remember what? For how long? What happens when storage fails? Does an existing subscriber need to sign up again?

Those decisions matter whether a person or an AI coding assistant writes the implementation. An assistant can produce working code while still solving a different problem from the one you intended.

The Journey, my personal story game, offers a concrete example: remembering newsletter access across its Play and Story modes. The useful lesson is how to define behaviour tightly enough to review it.

Start with the experience you want

The requirement is straightforward: after a successful newsletter submission, a visitor should be able to continue into either mode without another signup prompt in the same browser.

That statement needs boundaries. The remembered value is a convenience for the interface. It is not authentication, a paid entitlement, or proof that a subscription remains active.

This distinction changes what the implementation should store. The Journey keeps a simple unlock flag in browser storage, rather than the visitor's email address. Clearing that storage and reloading the page removes the remembered state. A different device does not inherit it.

Browser storage is local to an origin and can be unavailable under browser policies. MDN's Web Storage documentation describes the mechanism and its limitations. A product requirement should account for that possibility instead of assuming every storage operation succeeds.

Describe outcomes for each state

A single happy-path criterion would miss most of the decisions. A more useful acceptance table looks like this:

Starting condition	Event	Expected outcome
No remembered unlock	Visitor selects either mode	Show the signup prompt
No remembered unlock	Signup succeeds	Continue and remember access
Existing subscriber	The Journey receives its recognised duplicate response	Continue without requiring a second subscription
Submission fails	Visitor tries to continue	Keep the gate and show the failure
Browser has the unlock flag	Visitor returns	Permit entry to either mode
Storage rejects a write	Signup succeeds	Retain access for the current loaded session
Storage has been cleared	Visitor returns later	Treat the browser as a first visit

These are observable outcomes. They do not depend on a particular component name or storage helper. A reviewer can discuss them before reading implementation details.

The duplicate case also needs a boundary: The Journey's continuation behaviour should not silently change ordinary newsletter forms elsewhere on the site. A convenient exception in one flow should remain local to that flow.

Match each check to the risk

The repository separates the remembered-access helper from the form and landing experience. That makes the storage behaviour easier to exercise independently.

An isolated check can verify that a successful unlock remains available when storage throws. Another can verify that only the recognised duplicate response permits continuation in the relevant form context.

Those checks do not prove the whole experience works in a browser. The rendered flow still needs review: can the visitor read the error, change modes, return to the landing page, and continue after a successful submission?

Some of The Journey's tests also inspect source structure. Such checks can protect specific wiring, but they should not be presented as evidence that every touch interaction or rendered state has been tested.

A useful release review names the evidence precisely: logic checked, types checked, build checked, and browser journeys exercised. "All tests pass" is too broad when a production path has not actually been walked.

Make the change reviewable

For an AI-assisted task, include three things alongside the desired outcome: the states to handle, the existing behaviour to preserve, and the evidence expected before acceptance.

For this example, that means preserving the first-visit gate, sharing the unlock between modes, retaining failure messages, and checking both normal and blocked storage.

It also means keeping the patch focused. A request to remember access should not become an unrelated redesign of the newsletter or a migration of game analytics.

The same method transfers to other features. For a saved filter, define what survives a reload. For a checkout, define what a retry means. For a generated answer, define how failure is shown and what the person can do next. The details change; the need for explicit states remains.

Give the review a clear stopping point

The acceptance decision should answer a concrete question: does the implementation produce the agreed outcomes, including the inconvenient cases?

That is more useful than asking whether the code looks sophisticated or whether the assistant finished quickly. In The Journey, a small remembered flag has value only when the surrounding experience behaves consistently.

Explore The Journey, or read why I turned my story into a game.