Context, plan, evidence: a change cycle you can defend in review

This is a representative sample session, not the complete course.

Session

SAMPLE SESSION · MODULES 02–03

Context, plan, evidence: a change cycle you can defend in review

A representative lecture from the middle of the course. It replaces ad hoc prompting with a repeatable cycle: build the context pack, get a plan before an implementation, and require evidence rather than reassurance.

Runtime

About 40 minutes of teaching plus a 35-minute exercise

Slides

Eyebrow

AI-NATIVE DEVELOPMENT · SESSION 02

Your next development skill is direction.

What to supply, what to ask for, and what to refuse to accept.

Notes

Ask how many have had a model confidently break something this month. Every hand. That is the session premise.

Eyebrow

THE UNCOMFORTABLE FINDING

Typing was never the bottleneck.

Understanding an unfamiliar system, choosing an approach, and deciding whether a change is safe are the constraints. None of them improve because completions arrive faster — but all three improve when you change how you direct the work.

Notes

Be specific that this is not anti-AI. It is about where the leverage actually is.

Eyebrow

THE CYCLE

Change cycle

Six stages, two checkpoints, one decision log

The checkpoints are before implementation and before merge. Everything else can move as fast as you like.

Notes

The plan checkpoint is the one people skip and the one that pays. Rejecting a plan costs a minute; rejecting a patch costs an afternoon.

Eyebrow

THE INPUT

Context pack

Output quality tracks context quality, not model size

Most disappointing results are context failures wearing a capability costume.

Notes

Ask what happens when you paste the whole repository. Answer: you have supplied volume, not context, and made the important files harder to find.

Eyebrow

WORKED EXAMPLE

A context pack that fits on one screen

Language

context.md · billing service

# Billing service — context for this change

## Shape
PHP 8.2, no framework. HTTP entry points in www/, domain logic in app/.
MySQL via PDO only — no ORM. Stripe is the single payment provider.

## The three files that matter here
app/registration.php      creates and transitions registrations
app/payment-confirmation.php  the only place a payment becomes 'paid'
www/webhook.php           the only trusted source of payment truth

## Invariants — must still hold after the change
I1  A registration is only ever marked paid from a verified webhook.
I2  Every outbound message is written to registration_emails first.
I3  No code path outside app/ opens a database transaction.
I4  Money is integer minor units. Never a float, anywhere.

## Conventions
Functions, not classes, unless state genuinely persists.
Errors throw; callers at the HTTP boundary translate to responses.
Every query is a prepared statement. No exceptions, including admin.

## Out of scope for this change
Refunds, currency conversion, the admin UI, anything in database/.

## How this will be tested
The existing webhook integration suite, plus one new boundary case.

Note

Six invariants and three file paths outperform forty thousand tokens of repository. State what must stay true — a model cannot infer what was never written down.

Notes

Have them write one of these for their own service in ten minutes. Most discover their invariants have never been written anywhere.

Eyebrow

THE ASK

Ask for a plan. Reject it cheaply.

Columns

What you ask for

The approach, in five sentences
Two alternatives considered and dropped, with reasons
Which files will change and roughly how much
Which invariant each change could threaten
The tests that will demonstrate it worked
Anything it had to assume because you did not say

What you look for

An assumption you did not intend
A change reaching outside the stated scope
A missing failure case
Tests that restate the implementation
Confidence where the context was thin

Note

The assumptions list is the most valuable output in the cycle. It is the model telling you exactly where your context pack was incomplete.

Notes

Frame the assumptions request as a diagnostic on your own brief, not on the model.

Eyebrow

THE REVIEW

Review lens

Six lenses, same order, every time

Generated code carries the same review obligation as any contribution — arguably more, since nobody has held the whole of it in their head.

Notes

Order matters: correctness before style, blast radius before bikeshed.

Eyebrow

THE DOMINANT RISK

Plausible failure: fluent, structured, confidently wrong

Bullets

The API that does not exist

A method with exactly the right name and signature for the job, on a library that never shipped it.

The test that agrees with the bug

Derived from the implementation rather than the requirement, so it passes and proves nothing.

The silent contract break

A refactor that preserves every call site and quietly changes what null means at one of them.

The convincing explanation

A fluent account of why the fix works, produced without executing anything.

The scope creep with good manners

Four improvements you did not ask for, folded into the diff you did.

Notes

Show a real example of each if you have them. Nothing lands like a defect the room recognises.

Task	What it needs	Sensible default	Where the checkpoint goes
Explain unfamiliar code	Breadth, long context	Fast general model	You verify against the code itself
Draft tests from a spec	Instruction adherence	Fast general model	Tests derive from the spec, not the diff
Design a change in a complex domain	Reasoning depth	Strongest available	Plan reviewed before implementation
Mechanical refactor across many files	Consistency, tooling	Coding agent with test access	Full suite green before review
Anything touching secrets or customer data	Data boundary control	Whatever your policy permits	Human before it leaves the machine
Debug a reproducible failure	Hypothesis generation	Fast model, several attempts	Reproduction stops reproducing

Eyebrow

SELECTION

Choosing a model without chasing a leaderboard

Note

Cost and latency belong in this table too. A slower model that halves review time is usually the cheaper one.

Notes

Push back on the idea that there is one right model. The right question is which checkpoint the task needs.

Metric	Why it is honest	How to read it
Review time per change	Speed that moves work into review is not speed	Should fall, or at least hold, as throughput rises
Rework rate	Counts change that had to be revisited	A rising rate cancels the throughput gain
Change-failure rate	Counts what reached users and failed	The number that decides whether this is working
Defect escape rate	Found after release rather than in review	Tells you whether review is real or ceremonial
Time to first reproduction	Debugging leverage, isolated	Where assistance reliably helps most

Eyebrow

HONESTY

Measure what you would defend to a sceptic

Note

Deliberately absent: lines generated, suggestions accepted, percentage of code written by AI. None of them survive contact with a sceptical stakeholder.

Notes

This slide is what a technical lead takes back to their manager. Make it easy to photograph.

Eyebrow

YOUR METHOD

The playbook you leave with

You will refine this in the capstone. Start here.

Items

A context pack lives in the repository and is updated, not re-invented per developer.
Invariants are written down where both humans and models will read them.
A plan is requested and reviewed before any non-trivial implementation.
Changes stay small enough to review honestly in one sitting.
Tests derive from the requirement, never from the diff.
A fix ships with a reproduction that no longer reproduces.
A decision log records what you accepted, what you rejected, and why.
Data boundaries are decided before the convenient paste, not after.

Notes

Ask which one their team would fail today. That is their capstone starting point.

Eyebrow

YOUR TURN

The exercise

Take the supplied repository and the seeded bug. Build a context pack, request a plan, reject it once with a specific reason, then ship a fix with a regression test and a decision log.

Bullets

10 minutes on the context pack
15 minutes on plan and implementation
10 minutes writing the decision log

Notes

The forced rejection is the teaching device. It breaks the habit of accepting the first plan.