Accepting AI-built software: from a working demo to a release decision

EDITORIAL PRACTICE

Agree what makes the work acceptable

A request to build an enquiry form leaves storage, notifications, confirmation and errors unclear. Pair the action with its outcome: valid input produces a reference number and the responsible team can find the same submission.

The scenarios here are editorial examples. Agree the actual checks for your users, data, integrations and publication scope.

FROM PRIMARY SOURCES

Combine review with tests

GitHub’s official guidance calls for careful review and testing of Copilot-generated work. Neither generated code nor review feedback should be assumed correct without checking.

Sources: [1]

EDITORIAL PRACTICE

Five acceptance scenarios for an enquiry form

Check visual completion separately from reliable behaviour. For external notifications, examine the receiving service’s result alongside the confirmation shown on screen.

EDITORIAL PRACTICE

Separate checked behaviour from unverified assumptions

Report the change, revision, environment, actions, results and open issues. A bare statement that tests passed does not tell the client whether mobile or failure cases were covered. Name untested environments and integrations that could not be checked.

• Deliverable: the URL or change to inspect.
• Scope: devices, browsers and access levels checked.
• Result: successful and failed scenarios.
• Open issues: impact, options and next owner.
• Decision: the person responsible for accepting and releasing the work.

EDITORIAL PRACTICE

Include production checks and recovery

Production configuration and integration permissions may differ from a test environment. Check representative behaviour after release and agree who can stop a failing workflow and how to restore it.

Start with one small feature and exercise the whole request, acceptance and release process. Consolidated evidence can replace the need for the client to monitor each execution.