Agree the answer before judging the code.
A calculation can run without errors and still answer the wrong question. In our software-productivity example, one accepted change takes 190 person-minutes and a rejected attempt takes another 95. The figures are invented. The code that totals them is part of our own published example.[S1]
The business rule is simple: rejected work still consumes effort, but it does not become an accepted result. The expected answer is therefore 285 person-minutes for one accepted change. Dividing by two attempts gives 142.5, a plausible-looking number that answers a different question.
We tested the calculation used by the page and separately constructed that wrong-denominator version. The targeted test rejected it. This is the useful question to bring to a code review: would our check notice the mistake that matters to the person using the result?[S1]
Make the expected results inspectable.
Before asking an assistant to implement a small change, write its inputs and expected outputs with the person who needs it. Work the answer out separately from the proposed implementation. For this calculation, we use the following checks; they are examples of scope, not a universal test count.
| Invented input | Required result | Mistake the check targets |
|---|---|---|
| One accepted attempt: 190 minutes; one rejected attempt: 95 minutes | 285 minutes in total, one accepted result, 285 minutes per accepted result | Counting attempts as accepted results, or dropping rejected effort |
| Only the rejected 95-minute attempt | 95 minutes, zero accepted results; the ratio is undefined | Reporting zero effort per accepted result when there is no accepted result |
| No attempts | Zero total minutes and zero accepted results; the ratio is still undefined | Confusing an empty sample with evidence of efficient work |
| Missing, negative or non-numeric effort | Reject the input and leave the observation unresolved | Silently treating an unknown value as zero |
Our correct implementation passed four targeted tests. We then introduced two faults separately: counting all attempts as accepted, and returning zero for an undefined ratio. Both faulty versions failed. This checks that the relevant assertions can detect those faults. It is not a defect-rate estimate and does not prove that the test suite finds every error.[S1]
For your own change, choose a failure that follows from the actual task. A paid invoice appearing in an overdue list is a meaningful wrong result. A test that only checks whether the function returns an array would miss it.
A working calculation still needs a code review.
Ask a qualified developer to inspect what changed and how it connects to the application. Does the implementation match the agreed rule? Does it read or write data, change permissions, add a dependency or expose a new action? The answers determine which integration and security checks are needed beyond the small example.
GitHub’s current guidance says Copilot review can miss problems, flag problems that do not exist, and suggest incorrect or insecure code. It recommends careful review and testing. Another AI review is useful input, but its approval is not proof that the change is ready.[S2]
Keep the tested code version, test inputs, actual results and unresolved findings together. If the code changes after review, check the affected parts again. Our agent acceptance guide covers the separate question of whether a whole agent works with its intended model, data and permissions.
Decide which version may be used.
The person who understands the required outcome and the person authorised to release the software need an explicit decision. Record what passed, what remains untested and whether the remaining risk is acceptable for this use. A developer’s completed implementation and a production approval are different events.
Agree a response if the change fails in its intended environment. Check the version you would restore and whether data or dependencies would also need attention. The oldest available version is not automatically an acceptable fallback. Our proposed review record keeps the distinction visible.
| Before release | Record |
|---|---|
| Required behaviour | The task owner, examples and expected results |
| Technical review | The actual reviewer, exact version and unresolved findings |
| Observed checks | Inputs, results and the intended environment; distinguish executed tests from planned tests |
| Release and response | Who may approve this version, which limits apply and the checked response if it fails |
This is one practical part of a hybrid organisation: people and agents share work while approval remains explicit. Start with one small change, its task owner and a qualified developer. Agree an expected-result table, then have the developer demonstrate one relevant wrong version being rejected before considering the release.
