Augmented and verified review

How can you use AI to identify defects in a code change without publishing unfounded comments?

1250 € per session, excl. VAT

In short

This half-day session of 3 hours covers preparing a review, asking an AI about a targeted change and verifying its observations. Participants produce actionable comments, distinguish demonstrated defects from hypotheses, then measure the quality of their review on a fictitious patch with accompanying tests.

Why this training?

A review can miss an edge case while accumulating style comments. AI helps to broaden the perspectives used to read the code, but its observations must be linked to the code and requirements to avoid false positives. A useful comment describes problematic behaviour, its impact and a way to reproduce it. The training therefore puts human verification and tests before publication, without delegating the merge decision to AI. Running case study: The fictitious organisation Tessoria Réservations modifies a stock reservation function. The patch must reject negative quantities and prevent reservations exceeding available stock. The case materials include the code diff, the expected rules and incomplete tests; several known anomalies are used to evaluate the review. Transfer to work: On a forthcoming authorised change, reuse the prompt template and verification checklist. Compare the observations proposed, retained and rejected after human checking; record defects discovered later to adjust the context provided to AI.

Objectives of this training

  • Define the scope of the change and select the context needed to analyse it
  • Formulate a review request that distinguishes functional correctness, robustness and readability
  • Verify each finding by reading the code or running a targeted test
  • Write comments that are tied to specific code locations, reasoned and actionable
  • Measure detected defects and false positives using a case with a worked solution

Who is it for and what are the prerequisites?

Roles and tasks concerned

  • Developers who regularly participate in change reviews
  • Technical leads seeking to improve the reliability of comments in AI-assisted reviews

Prior skills

  • Be able to read a code diff and run unit tests in the selected language.
  • Have previous experience of using generative AI and be able to rephrase an instruction.

What you will work on

  1. Define the scope of the change

    Objective: Prepare sufficient context without sharing the entire repository. Code diff, functional contract, relevant dependencies and exclusions; protection of secrets and personal data.

  2. Obtain traceable observations

    Objective: Generate leads for the review rather than a verdict. Structured instruction: expected behaviour, analysis perspectives, location, impact, expected evidence and uncertainty.

  3. Confirm or refute warnings

    Objective: Turn suggestions into demonstrated findings. Critical cross-checking, boundary tests, false positives and the distinction between a proposed test and an executed test.

  4. Publish and evaluate the review

    Objective: Produce proportionate comments and measure their reliability. Comment structure, severity, optional suggestions and indicators calculated with their denominators.

What you take away

  • Change context sheet and review scope
  • Review prompt template with evidence requirements
  • Log of findings that are confirmed, rejected or require further investigation
  • Comments ready for publication, targeted tests and measurement grid

Method and assessment

  • Short instructional sessions followed by immediate practice on the running case study.
  • Individual work followed by work in pairs, with peer review of the outputs.
  • Guided group discussion: what works, what needs correcting and what remains a human decision.
  • Preparation: Have a development environment available with the fictitious repository and its tests, prepared in a language shared by the group. Check access to an AI authorised by the organisation; use only fictitious or anonymised data, with no secrets or confidential code that has not been authorised for use.

Observable criteria: The context specifies the expected behaviour and the boundaries of the scope provided. ; Each retained finding refers to a line or function and to verifiable evidence. ; Comments distinguish between a blocking defect, an improvement and a question where there is uncertainty. ; Targeted tests compare expected behaviour with observed behaviour. ; The grid calculates the proportion of confirmed findings and the proportion of known anomalies detected..

Frequently asked questions

Do you need to share the entire repository?

No. The relevant excerpts and their dependencies are sufficient; any missing context must be flagged.

Does AI decide whether to merge?

No. Approval remains a human responsibility and follows the organisation’s review rules.

Can you work with internal code?

The exercises use fictitious or anonymised code, exclusively in authorised tools.

Does this review replace a security audit?

No. It can highlight risks, but it replaces neither specialist analysis nor existing checks.

Last updated: