How to review AI-generated code: a checkout exercise for beginners
Prepared with AI assistance and linked primary sources. Examples are illustrative unless stated otherwise.
Review AI-generated code by comparing it with a written requirement, calculating expected results independently and testing both valid and invalid inputs. An automated review can help identify concerns, but you still need evidence that the change does what your project needs.
What changed in Copilot code review this month?
On September 11, 2026, GitHub announced updates to Copilot code review. The announcement describes automatic resolution of addressed comments during a later review, suggested commit messages when applying fixes, and broader shell-tool use for analysis. That last change can help a review agent run checks such as build commands and tests. This article was prepared on September 18; the announcement is a week old, not a launch today.
For learners, this raises a useful question: when a tool can propose a change and help examine it, what should you contribute? Start by explaining the requirement and checking whether the evidence actually supports it. A resolved comment records progress on feedback; it should not be your only reason for accepting a change.
Source: GitHub Changelog: Copilot code-review updates, September 11, 2026
Write the checkout rule before asking for code
Here is an original practice exercise. A fictional shop sells notebooks for ₹100 each. Customers may buy between one and five notebooks. An order receives a 10% discount only when the subtotal is at least ₹300. There is no tax, shipping charge or payment gateway in this exercise. The total is the subtotal minus any eligible discount.
Ask an AI coding assistant to propose a small function for that rule. Request an explanation of the input assumptions and a few test cases. Keep its first answer so you can record what you changed. Use fictional data: this exercise needs no account credentials or real customer details.
Calculate your own expected results
Before running generated tests, write a small expectation table yourself. One notebook costs ₹100; two cost ₹200. Three reach the discount threshold, so ₹300 becomes ₹270. Five produce a ₹500 subtotal and a ₹450 final total. These values follow from our exercise brief and do not describe SPOTHUB course prices.
Now inspect a possible mistake: the generated function uses subtotal greater than 300 instead of subtotal greater than or equal to 300. Tests for quantities one and five would still pass, while quantity three would expose the error. This is why a boundary case can reveal more than several similar successful examples.
- Quantity 1: expect ₹100 with no discount.
- Quantity 2: expect ₹200 with no discount.
- Quantity 3: expect ₹270 because the threshold includes ₹300.
- Quantity 5: expect ₹450 after applying the discount once.
Review inputs and failure behaviour
Decide what zero, negative numbers, fractions, six notebooks and missing input should do. For this exercise, reject anything other than a whole-number quantity from one to five. Define that behaviour before changing the function; silently rounding a fraction or treating missing input as one would introduce a new business rule.
Read the proposed change as well as its test results. Does it add a dependency that a small calculation does not need? Does an error get hidden by a default value? Does the discount get applied twice? Ask the assistant to explain suspicious lines, then check its answer against the original brief. Keep accepted and rejected suggestions in your review notes.
Use the review tool as another source of evidence
GitHub’s guidance says to review Copilot-created pull requests thoroughly before merging. It also calls attention to proposed workflow changes before allowing those workflows to run. In your practice project, inspect the changed files and commands so you understand what the assistant wants to execute.
Run the focused tests after each correction and retain the result. A green run supports the scenarios you actually checked. It does not establish that a real store handles stock, payments, concurrent orders or every currency correctly. List those limits rather than presenting the small calculation as a production checkout system.
Turn the exercise into a project explanation
Save four things: the written rule, your independently calculated expectations, the final function with its tests, and a short explanation of one defect you found. If you did not find a defect in the generated answer, say so; you can introduce the threshold mistake yourself and label it as a deliberate experiment. Do not invent a debugging story.
For Chennai learners exploring software development, this is a practical starting point before a larger project: explain what the customer needs, implement a small rule and defend the checks you chose. SPOTHUB’s Full Stack learning path is a relevant next step to discuss if you want guided practice. Ask about prerequisites and current program details before enrolling; completing an exercise or a training program does not guarantee employment.
Sources and further reading
- GitHub Changelog: Copilot code-review updates, September 11, 2026 · checked 2026-09-18
- GitHub Docs: review output from Copilot · checked 2026-09-18
Spot an error? Email info@spothub.in with the article link and correction.
