Programmers and AI: Proving That the Code Works

A passing test can answer the wrong question

Imagine a fictional shop where delivery becomes free at a basket value of exactly 50 units. An AI assistant changes the checkout and adds tests for 40 and 60. Both pass, yet a basket worth exactly 50 still receives a delivery charge. The missing case is small; the rule being broken is real within this invented example.

GitHub's application card says Copilot code review can miss problems and report problems that do not exist. It calls for human review and testing of generated suggestions. An automated reviewer therefore supplies another source of findings to assess; its approval alone does not establish that the change meets its requirements. [GitHub Docs: Application card — GitHub Copilot Agents]

Follow the change from rule to result

Google's engineering guide asks reviewers to examine design, functionality, complexity and tests. It specifically asks whether tests would fail if the code were broken. This guidance applies regardless of who produced the code and gives a practical starting point for reviewing an AI-assisted change. [Google Engineering Practices: What to look for in a code review]

BELL RIVER recommends beginning with the intended behaviour before reading the implementation. For the shop, establish whether the threshold uses the basket before or after discounts. Then follow that value through the calculation and checkout display. A correct helper function is insufficient if the screen passes it the wrong amount.

Challenge the evidence

In our suggested workflow, ask which cases distinguish the required behaviour from a plausible mistake. Check the exact threshold and neighbouring values. Inspect assertions instead of relying on a test count. A test that only checks whether the page loads would not detect the incorrect delivery charge in this scenario.

Keep separate notes for confirmed defects, unanswered questions and optional improvements. Reproduce an automated review finding before requesting a fix. After a correction, rerun the relevant checks and inspect the final change, since the repair may alter behaviour elsewhere. Record what you actually checked and what remains outside the evidence.

Build judgement through small changes

Our editorial view is that reading unfamiliar code, constructing counterexamples and explaining failures will remain useful as code generation develops. That does not mean review can absorb every displaced coding task. For a learner, understanding a modest function and its callers is a stronger starting point than accepting a large generated feature that they cannot explain.

Catch an intentionally planted defect

Build a local toy function using integer units: delivery is zero for baskets of 50 or more and five otherwise. Deliberately implement 'greater than 50' first. Write expected results for 49, 50 and 51 from the stated rule, run the tests and preserve the failing result before correcting the comparison.

Then decide and document how this toy should handle an empty basket or a negative input; do not let an assistant silently invent those rules. Save the requirement, minimal example, failing test and repaired result. This small review record makes your reasoning visible without customer data or a live checkout.

Three practical first steps

• Pick a small change whose intended behaviour you can explain independently of its implementation.
• Write expected boundary results first, then check whether the tests would expose a deliberate defect.
• Produce a short review record with reproduced findings, completed checks and remaining uncertainties.

Vendor limitations and engineering guidance are not measurements of every AI system's accuracy. The fictional exercise covers one simple logic error and cannot establish production quality or professional testing competence. No employment or productivity outcome is promised. Sources checked 13 October 2026.

Sources & editorial note

• GitHub Docs: Application card — GitHub Copilot Agents
• Google Engineering Practices: What to look for in a code review

This career guide distinguishes source-backed descriptions from BELL RIVER’s editorial suggestions. Learning exercises are illustrative, not employer requirements, certifications or promises of employment. Overseas examples do not establish demand or eligibility in the UAE.