A small museum sells timed-entry tickets through a custom checkout. A visitor reserves the last seat, but the browser is abandoned. The reservation should expire after a documented hold period. In a bug report, two customers can appear to claim that seat when a hold expires at the same instant a second checkout completes. A natural-language coding agent might fix the visible error message without actually closing the inventory race.
GitHub Copilot cloud agent can work from a GitHub issue, research the repository, make changes on a branch, and open a pull request for review. This walkthrough uses a fictional ticket service and illustrative code states; it does not report a run against GitHub or measurements from a real checkout system.
Define the defect as an invariant rather than an error message
Write the invariant first: for a given seat and time slot, no more than one valid confirmed sale can exist. A temporary hold is different from a sale, and an expired hold must not continue reducing availability. Record the exact states the service already uses, such as available, held, expired, and purchased. Do not ask an agent to invent a new state machine based on a screenshot alone.
Attach sanitized reproduction steps with two simulated clients, the server time assumption, and expected responses. A useful acceptance test asserts the final database record, not merely a successful-looking green button. Include the condition that the same checkout retry cannot create a second charge or second ticket. Remove payment tokens and patron identities from issue examples.
Prepare the repository before assigning the issue
Choose a repository where Copilot cloud agent is enabled and an appropriately scoped paid Copilot account can access the feature. GitHub documents that organizations may disable cloud agents and that enterprise administrators may need to enable them. Give the agent only the work it actually needs. An agent is not a reason to grant broad production credentials or to weaken normal branch protection.
Check the project instructions, testing commands, dependency lock files, and migration policy. GitHub recognizes repository instructions such as .github/copilot-instructions.md and AGENTS.md. State that existing database schemas and payment semantics are authoritative, and require a proposed diff rather than direct production edits. A clear local test harness is far more valuable than a long generic instruction to “make it safe.”
Assign a small issue and examine the plan
On GitHub, assign the scoped issue to Copilot where supported and provide the expected behavior in the optional instructions. GitHub also documents a research-and-plan approach before committing to a pull request. Ask which function owns the transition from a temporary hold to a confirmed purchase, and which database constraint should enforce uniqueness under concurrent requests.
Treat the agent’s plan as a hypothesis. If it proposes a client-side timer as the only solution, request a server-side inventory guarantee. Browser clocks can drift and separate checkout workers can execute at once. Confirm whether the plan handles payment retries, abandoned sessions, and an already-expired hold without silently changing unrelated cancellation logic.
Test expiration and competing buyers separately
Make a table of conditions: a hold that has not expired, a hold expired one second earlier, two simultaneous purchase attempts, and a network retry after success. Each test should specify expected confirmed-seat count and error response. Use an isolated test database with deterministic clocks; a wall-clock delay in a test can be flaky and may miss the narrow collision window.
The process diagram describes issue intake, plan review, test inspection, and human merge. An AI-generated test that simply checks an HTTP 200 response does not prove single-seat inventory integrity. Require assertions against the persisted confirmed booking and a uniqueness constraint or equivalent atomic server operation, with the actual implementation chosen by the maintainers.
Read the diff for hidden changes to business rules
Compare every touched file with the stated scope. A convenient but unsafe edit might delete the hold timeout, allow purchases without confirming a hold, or turn duplicate errors into silent successes. Follow the change through the controller, transaction boundary, database layer, and test fixture. Ask why each database migration or configuration change is required.
If the agent edits unrelated revenue reporting or promotion rules, separate that work into another issue. The comparison diagram illustrates a wrong final state with two accepted purchasers versus a reviewed final state with one confirmed purchaser and an expired hold. These are teaching diagrams, not screenshots or measured results from a deployed service.
Use pull-request reviews as real approval gates
GitHub says Copilot cloud agent returns work through a pull request and can respond to human review comments. Keep required reviewers, status checks, and code-owner rules in force. Ask a reviewer familiar with transactional inventory to inspect locking and idempotency rather than accepting an automatically generated green test summary as proof.
Run the normal CI suite plus the specific adversarial test. Confirm that dependency changes are pinned, logs avoid patron data, and the agent did not add secrets or permissive failure modes. A pull request can be readable and still be behaviorally wrong; record the review decision and test evidence in the repository where teammates can audit it later.
Verify rollback and real-world release boundaries
For a payment-adjacent application, review the deployment and rollback path before merging. Ask what happens to holds created under the old code while the new code is rolled out. Confirm that existing sold tickets remain valid and that a deployment does not reset their state. An application release should not depend on trusting the model’s verbal confidence.
After release, monitor duplicate-purchase prevention and failed-checkout alerts using the museum’s approved monitoring procedure. Do not present an improvement percentage without measured production evidence. If the issue cannot be reproduced in a controlled test, report that limitation explicitly instead of marking the problem resolved because a plausible-looking patch was proposed.
Keep evidence for the next agent-assisted change
Archive the original issue, narrowed acceptance criteria, agent plan, test run identifiers, reviewed diff, and merge approval. A future maintainer needs to know why hold expiry is implemented in a specific place. Reusable repository instructions can describe the invariant, while test cases remain the definitive executable check.
Before handing off, ask another developer to read only the acceptance criteria and reproduce the intended final state in a clean environment. Their independent interpretation can expose ambiguity the original author and agent shared. A small, well-reviewed change to a hard invariant is a better outcome than a wide rewrite that nobody can confidently certify.
How We Research
For our November 5, 2026 documentation review we consulted these named official sources: GitHub Docs: Get started with Copilot agents on GitHub; GitHub Docs: Best practices for using Copilot on tasks; GitHub Docs: About GitHub Copilot agents. We mapped documented access requirements and controls to a narrowly defined hypothetical workflow, then wrote independent checkpoints that an editor or operator could verify. We did not purchase a subscription, use customer records, operate equipment, execute production code, or measure tool accuracy for this article. The diagrams are original instructional artwork, not screenshots or proof of vendor output. Plans, availability, legal rules, and organizational procedures may change; confirm current documentation and authorized source materials before acting.
Frequently Asked Questions
Yes, when enabled for an eligible repository and account, GitHub describes assigning an issue to the agent and receiving a pull request for review.
Do not assume that. Follow repository reviews and branch protections; keep the merge a deliberate human-controlled decision.
No. Add deterministic expiry, retry, and concurrent-purchase tests against persistent state.
No. Use sanitized fixtures, scoped permissions, and approved secrets management.
No. The issue, code states, and diagrams are fictional examples informed by GitHub documentation.