Predict before you push: have your human explain an AI-written change before it ships

An AI-written change can run while its human misunderstands it. Before code, a script, a spreadsheet formula or an automation goes live, pause for a few predictions about the people and data it affects.

Learning objectives

Help your human:

• Predict a normal outcome, a failure outcome and something that must stay true.
• Read the change, correct a mistaken prediction and try a fresh scenario.
• Recognise what a short prediction conversation can and cannot establish.

Explanation

Guide the checking, then step back covers coaching the human's judgement of AI output.

Try first, then hints covers supporting a learning attempt without taking it over.

This lesson focuses on the moment before a working change goes live.

One real example: Sphinx

The open-source project Sphinx builds this pause into Git pushes. Its default protected branches are main and master. A separate reviewer model reads the committed change through read-only Git tools, without seeing the conversation that produced it. It asks about behaviour, failure modes and invariants. The check is open-book; a wrong answer brings an explanation and a new scenario.

Its README calls this practice, not a security gate. Hooks can be bypassed, a pass does not prove unaided understanding, and the examining model can be wrong. Changed code goes to the chosen reviewer provider. Its tagline is “Outsource your thinking, not your understanding.” Source: Sphinx README.

The package is named sphinx-understand. The npm registry lists version 0.1.0 as published on 16 October 2026. Source: npm registry.

There is no evidence in these sources that Sphinx improves comprehension. It is one example of someone building the habit into a tool. The coaching method below needs no tool.

Apex guidance: ask for predictions

This routine is Apex guidance, not a research finding or a requirement from the sources. Before the change goes live, ask two or three questions. Cover these three areas; combine two areas in one question when appropriate.

• Behaviour: “This class has exactly three sign-ups. What happens?”
• Failure: “The booking sheet cannot be read. What happens next?”
• Invariant: “What must never happen to a paid booking?”

An invariant is something that must stay true. For example, a cancellation must never leave paid attendees without notice. Ask both what the change currently does and whether that matches the human's intended rule. Those answers may differ.

Ask about scenarios, rather than file names or syntax. Let the human read the change and give a short reason. Keep it open-book.

Apex guidance: explain briefly, then change the scenario

If a prediction is wrong, explain the relevant behaviour briefly. Offer a fresh case about the same idea. Repeating your answer tells you little.

If the conversation reveals unwanted behaviour, pause the release. Agree the intended outcome, change the implementation and add an appropriate test. A misunderstanding can reveal a learning gap, a flaw in the change, or both.

Keep the pause short and proportionate to risk. A small formula change may need two compact questions. Booking cancellations warrant a failure question and a must-keep rule. Resolve serious concerns before release.

A quiz pass does not prove deep understanding. It is not a safety check. Tests and review still apply, and your interpretation of the change can be wrong too.

Worked example

Fictional scenario: Juno coaches Amara, who manages bookings for a small yoga studio. All events are invented.

Amara had an AI write a script that sends class reminder emails and cancels classes with fewer than three sign-ups. It runs fine on a test. Before it goes live, Juno keeps the change open and asks three prediction questions.

1. Behaviour: “A class has exactly three sign-ups. Does it run or get cancelled?”

Amara says it gets cancelled. Juno briefly explains that “fewer than three” excludes three. Amara reads the change, sees that three means the class runs, and decides that is what she wants.

Juno offers a fresh scenario: “One person withdraws from a class of four. What happens at the next run?” Amara predicts that the remaining three keep the class running.

2. Failure: “What happens if the booking sheet is empty or cannot be read?”

They inspect both paths. The empty-sheet question reveals that the script treats missing booking rows as zero sign-ups and would cancel every class. Amara wants uncertainty to stop the script. They add a stop for empty or unreadable booking data, with no cancellations or reminder emails, and a test covering those cases before it goes live.

3. Invariant: “What must never happen when a class has paid sign-ups?”

Amara says: “It must never be cancelled without a notice to the people who paid.” They make that rule explicit for review and testing. A reminder email alone would not satisfy a cancellation-notice rule.

The predictions expose a misunderstanding and unwanted behaviour. Tests and review still apply.

Check yourself

Q1. A script runs successfully on one test. Which next question best checks a prediction about behaviour?

• “Which files did the AI change?”
• “Can you repeat the AI's summary of its edits?”
• “A class has exactly three sign-ups. What will the script do, and why?”
• “What syntax does the script use for a condition?”

Q2. The human predicts the wrong outcome. What follows Apex guidance?

• Explain the relevant behaviour briefly, then offer a fresh scenario with the change still available to read.
• Explain the answer, then count its immediate repetition as a successful prediction.
• Hide the change and repeat the question to test recall.
• Replace the scenario with a request to list the changed files.

Q3. What does passing a short prediction quiz establish?

• That the change is safe enough to release without review.
• That the human can explain the change unaided in every context.
• That the examining model has interpreted the change correctly.
• That the human answered those scenarios correctly; deep understanding and safety remain unproven.

Sources

• Sphinx README (parthh01/sphinx on GitHub)
• sphinx-understand on the npm registry