AI Developer · Module 2 · The Craft of Developing

Prove: Review, Tests and Verification

The lesson treats D4 Prove: what review is for, which layer of testing answers which question, and why the test oracle must be independent of the generator. Participants learn the three rules of independence (authorship, source and protection), the volume problem that cheap generation creates for review, the design measures that keep review real, the limits of an AI reviewer, and how a verification plan and a review record carry the evidence.

Lesson 9 of 33Chapter 990 minutes

Read the chapterThe whitepaperThe slides

All courses / AI Developer / Module 2 / Chapter 9

Learning objectives

After the lesson the participant can:

Key concepts

The strength of the oracle
Testing is a set of layers (static analysis, example-based tests, property-based tests, mutation score, formal models, human review), each answering a different question. The strength of any pass is the strength of the oracle behind it.
Authorship, source and protection
The three rules of independence: the oracle is written or approved by someone other than the author of the change; it is derived from a source the implementation was not derived from; and the tool that produces the change has no permission to edit the oracle, review rules or gates.
The volume problem
When generation is cheap, review capacity bounds the merge rate. The chapter's own arithmetic leads to a choice between a visible cap on what is merged and an invisible thinning of the review each change receives.
Seeded defects
Known defects added by the quality function to a sample of changes, to measure how many each check catches. They are how independence and review quality are shown rather than asserted, and they are reported in aggregate.
AI as reviewer
A system that reads a diff and writes comments. Three limits are architectural: blind spots correlated with the generator, context it cannot see, and comments that look like approval. It is a useful additional check when evaluated like one and never counts as the human review.

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Interactive exercise 1 · Match

Which check answers which question

Match each kind of check to the question it answers in the chapter's division of labour.

Interactive exercise 2 · Scenario

Green tests from the same session

Apply the three rules of an independent oracle: authorship, source and protection.

Teaching plan

15 minLecture on what review is for and on the table of checks: the question each answers, who should write it and its typical blind spot.
15 minThe teacher presents the three rules of independence with the Hansa Mutual records VER-HM-2030-0007 and RVW-HM-2030-0412; participants identify who wrote the oracle and what the assistant could not alter.
15 minGroup work on the volume problem: each group estimates its team's weekly review hours and the number of open changes it can carry, then picks three design measures.
30 minExercise: pairs write a verification plan with an independent oracle for one change.
15 minPlenary on the duplicated settlements of June 2029: what a review without independence looks like when nobody used AI.

Discussion

  1. The chapter says the value of review for the stewardship principle is that it creates a second person who can explain the change. How often does your review achieve that?
  2. Between a visible cap on merges and an invisible thinning of review, organisations tend to drift to the second. Who in your organisation would have to agree to the first?
  3. Oversight-quality figures such as approvals within seconds are reported in aggregate and agreed with staff representatives. Why does the chapter insist on both conditions?

Written exercise

Exercise · 30 minutes

A verification plan with an independent oracle

Take one change that AI took part in, or a change to the deductible and cap calculation in the claims core of Hansa Mutual. Name the behaviour that must be true after the change and the behaviour that must not change, both taken from the specification. Choose the layers of checking and, for each, name who writes the check and the source of the expected result. Write two properties from the specification. Set a mutation target for the changed lines and name who may lower it. List the checks the generator can and cannot see. Name the reviewer and what they read first, the steward, and how the change is reverted outside the pipeline.

Deliverable: A verification plan naming layers, oracle authors and sources, properties, mutation target, protected checks, reviewer, steward and revert path.

Self-test

Choose an answer to see whether it is right, or open the answer below each question.

  1. What does the rule of protection require of an independent oracle?

    Show the answer

    C. That the tool producing the change cannot edit the oracle, the review rules or the gates
    Protection is the third rule after authorship and source: the generator of the change cannot edit what checks it. The rules make the oracle's errors different from the generator's, which is what independence means.

  2. What does the duplicated-settlements incident at Hansa Mutual (INC-HM-2029-0207) show, according to the chapter?

    Show the answer

    B. That a review without independence fails even when nobody used AI at all
    The reviewer was the only other person who knew the module, so reviewer and author shared the same knowledge and the same gaps. The review passed and 312 claims were paid twice, with no AI involved.

  3. In the chapter's division of labour, who should write a property-based test?

    Show the answer

    A. A person, working from the specification and not from the code
    The table assigns property-based tests to a person who derives the rule from the specification, not from the code. The platform team writes static analysis rules, and a specialist writes formal models.