301 · Live virtual delivery

Review together.
Build your judgment.

Take a change an AI wrote, check what could be wrong, and explain what you would approve, send back, or ask an owner to decide.

A live online class with an instructor and coaches. Follow one payments change from the business request to a checked defect and a bounded repair plan, with the code and evidence beside you.

Explore the course Instructor playbook

What you will develop

Intuition. Language. Behavior.

Shared intuition: Understand what a tool notices, how it reaches its result, and what remains unchecked.Show the code or test behind the output and explain its limits.
Shared language: Distinguish a signal, a reviewer’s claim, checked evidence, a defect, and an owner’s decision.Describe what is known and what still needs a check or a decision.
Shared behavior: Follow the code, run a suitable check, preserve evidence, and keep a repair within its agreed scope.Explain what you would approve, send back, or refer to an owner.

How the experience works

Before, during, and after.

Before · arrive ready

Install Workbench and check your workspace. Open the payments fixture and read the business request. Be comfortable reading TypeScript and using a terminal; the class introduces SPEED vocabulary as it goes.

Your organiser confirms the joining link, schedule, pair assignments, and how to get setup help.

During · follow, check, explain

The instructor explains and demonstrates each stage. Use the reader’s three columns to keep chapter navigation, the explanation, and sources or commands together. Pairs discuss the evidence in breakout rooms; coaches help with code and environment questions.

Alternate who drives the shared screen. Ask your partner, then your pod, then a coach. Regroup to compare reasoning before the next chapter.

After · apply it independently

Revisit any chapter in the same self-serve reader. Retain your evidence and unresolved questions, then apply the approach to a change in your own work. Explain both the decision and the checks that support it.

Reader notes stay in your browser. Download them if you want a copy to keep or share.

How learning is demonstrated

The explanation is the evidence.

Explain a signal and its limits.Trace what matched and name what the tool has not checked.
Check a claim against code and evidence.Choose a suitable reproduction and distinguish its result from broader claims.
Defend a decision and name the unknowns.Connect the requirement, observed behavior, impact, and next owner or repair.

A command finishing or a chapter being visited does not establish these outcomes. Each learner needs to explain and apply the reasoning themselves.

For instructors

Instructor delivery playbook.

Use the spoken lesson for the explanations and demonstrations. The pair prompts and independent check below add participation for live virtual delivery; they are facilitation guidance added to the original script.

Session setup

Prepare the session and workspace

Agree the delivery plan. Confirm total duration, cohort size, coaching capacity, joining details, and the final individual exercise. The spoken walkthrough runs from 0 to 128 minutes, including a break at 70–78 minutes. Budget the added pair discussions and individual check before confirming the live schedule.
Check readiness before the class. Send the installation and readiness guide. Have participants confirm a healthy workspace and access to the payments change; route setup failures to help before instructional time.
Rehearse against the delivery checkout. Keep the fixture and SPEED implementation open. Run the demonstrations, record the revisions and environment, and check fresh Review output and generated fee-repair Plan tasks. The archived lesson identifies both as still needing verification.
Keep evidence identifiable. Retain the saved lesson evidence as a labelled fallback. Distinguish it from each live run, and update file references when current output differs. Use test-card data from the fixture.
Prepare an independent application task. The opening promises an individual round, but the continuation does not supply one. Choose an unseen change, provide its requirements and runnable checks, and prepare an evidence-based answer guide before delivery.

Set up remote pairs, pods, and coaching

Use a meeting platform with screen sharing, chat, and breakout rooms. Rehearse moving between rooms and how participants call a coach. Make the reader and joining instructions available outside the meeting chat as well.

Carry the lesson’s pairs in pods of four into breakout rooms: two pairs per pod. Each learner keeps their own checkout and notes. Alternate the driver after each step; the partner follows the source and explains what the output establishes.

Name the lead instructor and coaches. Keep a clear help channel, with coaches handling environment problems and visiting pods while the instructor holds the main explanation. Agree cohort size against the support you can provide.

Post each prompt, the expected evidence, and when to return before opening rooms. Allow questions through chat and spoken discussion; share the code directly so learners can inspect it without relying on a screen share.

Chapter-by-chapter facilitation

Explain and demonstrate first, then use the pair prompt. Check the reasoning before handing off. Timings below are from the spoken script; adjust the live schedule for discussion and coaching.

The payments change0–8 min · spoken script

Outcome: Understand the support request, the four-file change, and who owns the requirements.
Explain: Introduce the support request before the tool vocabulary. The agent was asked to resend a refund, with up to three attempts. Establish where the product and technical requirements live and who owns them.
Demonstrate: Show commit 965029f and its four changed files: retry.ts, service.ts, cards.ts, and refund-retry.test.ts. Point out the logging and fee edits without deciding whether either is a defect.
Participant work: Ask pairs to inspect the chapter sources and put their answer in their own words:
What was requested, what else changed, and where would you look for the required behavior?
Have the partner explain the evidence; regroup and compare answers before moving on.
Evidence to hear: Participants distinguish the requested retry from the other edits and point to the product and engineering owners in the specs. Hold questions about defects for the checks that follow.
Handoff: We know what the agent was asked to do. Next, inspect what Diagnose notices without deciding whether it is a defect.

Open this chapter and its sources

Diagnose8–23 min · spoken script

Outcome: Explain how the first F2 rule produces a signal and what that observation leaves unchecked.
Explain: Introduce the task record, failure class, rule, and signal in that order. Read the first F2 rule’s look, match, and say fields before interpreting any output.
Demonstrate: Follow Task 1 into the branch diff and the added log.error line, then into the matcher implementation and saved signal. Keep the serializer question open until Review.
Participant work: Ask pairs to inspect the chapter sources and put their answer in their own words:
Explain the match, its limits, and the question you would carry into Review.
Have the partner explain the evidence; regroup and compare answers before moving on.
Evidence to hear: Participants point to the text that matches and explain that a pattern match has not established a card-data leak. The next check must follow what serialiseFailure sends to the logger.
Handoff: The first F2 rule matched the added log.error line. Carry the question of what serialiseFailure sends to the log into Review.

Open this chapter and its sources

Review23–45 min · spoken script

Outcome: Check the reviewer’s claims against the code, requirements, and a suitable reproduction.
Explain: A reviewer’s finding is a claim to check. Trace its input and the requirements, then inspect the code beyond the changed line. Keep the saved finding’s run separate from any fresh output.
Demonstrate: Follow the logging claim into serialiseFailure and its redaction. Reproduce the failure path with the fixture’s test card and inspect the captured log. Compare the retry test’s calls with the helper, then inspect the fee requirement.
Participant work: Ask pairs to inspect the chapter sources and put their answer in their own words:
Which saved claims hold up, which do not, and what evidence is still needed?
Have the partner explain the evidence; regroup and compare answers before moving on.
Evidence to hear: Participants explain why the demonstrated logging claim does not hold, why the direct-refund test leaves retry-helper coverage open, and why the fee calculation needs its own reproduction.
Handoff: The demonstrated log path redacts the card number. Retry-helper coverage remains unproven; the fee calculation disagrees with its requirement. Take those questions into Eval.

Open this chapter and its sources

Eval45–70 min · spoken script

Outcome: Trace which test ran, what its pass establishes, and why the separate fee check is still needed.
Explain: Name the scenario, selector, assertion, criterion, and recorded result. Acceptance is bounded by what was selected and checked.
Demonstrate: Trace Task 1’s saved test plan and summary to RETRY-01. Show that the test calls refund directly. Run the separate RISK-02 fee check and retain its actual output.
Participant work: Ask pairs to inspect the chapter sources and put their answer in their own words:
Why can Task 1 be accepted while retry-helper coverage remains open and the fee check fails?
Have the partner explain the evidence; regroup and compare answers before moving on.
Evidence to hear: Participants distinguish the passing RETRY-01 result from proof about the helper or refund policy. They identify RISK-02 as a separate failing fee check, not a Task 1 Eval failure.
Handoff: Task 1 Eval passed RETRY-01. The separate RISK-02 check failed. Use that fee evidence to explain one bounded defect.

Open this chapter and its sources

Break70–78 min in the spoken script

Explain the fee defect78–88 min · spoken script

Outcome: Connect the reproduced fee failure to its requirement, account impact, and the decision the product owner needs to make.
Explain: Separate observed behavior, required behavior, account impact, and unknown production exposure. The rounding requirement is already written; priority and exposure investigation need an owner’s decision.
Demonstrate: Follow a capture of 200 minor units through the fee and merchant postings. Compare fee 2 / merchant 198 with required fee 3 / merchant 197. Both totals are 200.
Participant work: Ask pairs to inspect the chapter sources and put their answer in their own words:
Write the observed result, required result, impact, and specific decision for payments-product.
Have the partner explain the evidence; regroup and compare answers before moving on.
Evidence to hear: Participants explain the one-unit allocation error, cite the half-up requirement, and ask payments-product to set repair priority and agree whether to investigate affected versions and payments.
Handoff: Keep observed behavior, required behavior, impact, and unknown exposure separate. Bring those facts into the Define draft.

Open this chapter and its sources

Define88–108 min · spoken script

Outcome: Prepare an actionable defect draft with checked facts and provenance, then inspect the existing report without filing a duplicate.
Explain: Generated fields and an enabled submit button do not make a checked, new defect. The author supplies verified facts, reproduction, environment, impact, and the decision request.
Demonstrate: Inspect the blank fields in the generated draft and fill them using the lesson’s field-values file and current reproduction. Check the existing fee report, cancel the draft, and inspect the filed report and tracking state.
Participant work: Ask pairs to inspect the chapter sources and put their answer in their own words:
What must you add to the generated draft, and what should you check before filing?
Have the partner explain the evidence; regroup and compare answers before moving on.
Evidence to hear: Participants identify what the generated draft leaves out and why this demonstration cancels rather than files a duplicate. They distinguish historical report details from the current reproduction.
Handoff: The existing fee report supplies a bounded repair. Filing records a decision and its evidence; it does not repair the calculation.

Open this chapter and its sources

Plan108–128 min · spoken script

Outcome: Judge the proposed repair’s files, completion criteria, dependencies, and source references against the fee defect.
Explain: A repair plan describes pending work. Acceptance criteria, dependencies, and source references must let a reviewer trace each task back to the defect and judge completion.
Demonstrate: Use the existing fee-defect path for defect-driven Plan. Inspect the actual generated task files from the preparation run. Compare scope with service.ts, the existing applyRate helper, and the unchanged RISK-02 assertions.
Participant work: Ask pairs to inspect the chapter sources and put their answer in their own words:
What must the fee-repair plan include, what is outside its scope, and what evidence would establish completion?
Have the partner explain the evidence; regroup and compare answers before moving on.
Evidence to hear: Participants require the service repair, existing-test verification, and the source defect reference. They keep shared-helper changes and refund policy outside this repair and require execution evidence before calling it resolved.
Handoff: A plan proposes pending work. Require the actual repair and test evidence before calling the fee defect resolved.

Open this chapter and its sources

Troubleshooting

Handle different outputs and environment failures

Different AI output: Record the run and inspect its actual claims. Apply the same evidence checks rather than expecting the saved wording. If the live run does not expose the teaching case, use the archived result and name it as a saved run.
A command fails: Have a coach check the working directory, branch, runtime, and workspace health with the learner. Keep the pod discussing the shared source while the environment is repaired. Record whether a result was observed locally or on a partner’s screen.
Time is running short: Protect the outcome checks. Shorten optional implementation reading and provide a specific reader link for follow-up. Keep the distinction between the RETRY-01 pass and the separate RISK-02 failure explicit.
A policy question arises: Capture the unresolved question and its owner. The retry characterization does not decide refund-idempotency policy. The written half-up fee rule already decides rounding; payments-product decides priority and exposure investigation.

Outcome checks

Check independent application and give feedback

Finish with the individual task prepared before delivery. Each learner works without their partner and submits a short decision with source references, the chosen check and its result, and the remaining unknowns. An answer to the demonstrated fee case checks understanding; an unseen change checks application.

Intuition: Can the learner trace the output to the rule, code path, or selected assertion and explain what it leaves unchecked?
Language: Do they distinguish the signal, claim, evidence, defect, and owner’s decision, without overstating a pass or a reproduction?
Behavior: Do they choose and run an appropriate check, preserve its provenance, and propose a bounded next action or a specific owner question?

Give feedback against the evidence in the answer. If reasoning is incomplete, name the missing check, point to the relevant chapter, and ask for a revised explanation. Collect individual responses rather than treating the pod’s answer as everyone’s attainment.