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.
12 slidesAbout 40 minutes of teaching plus a 35-minute exerciseInstructor notes included
Illustrative teaching material for AI-Native Development. Condensed for the web; the live session includes the walkthrough, the handout and the exercise review.
AI-NATIVE DEVELOPMENT · SESSION 02
Your next development skill
is direction.
What to supply, what to ask for, and what to refuse to accept.
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.
THE CYCLE
Six stages, two checkpoints, one decision log
THE INPUT
Output quality tracks context quality, not model size
WORKED EXAMPLE
A context pack that fits on one screen
# 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.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.
THE ASK
Ask for a plan. Reject it cheaply.
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
The assumptions list is the most valuable output in the cycle. It is the model telling you exactly where your context pack was incomplete.
THE REVIEW
Six lenses, same order, every time
THE DOMINANT RISK
Plausible failure: fluent, structured, confidently wrong
- 01The API that does not exist
A method with exactly the right name and signature for the job, on a library that never shipped it.
- 02The test that agrees with the bug
Derived from the implementation rather than the requirement, so it passes and proves nothing.
- 03The silent contract break
A refactor that preserves every call site and quietly changes what null means at one of them.
- 04The convincing explanation
A fluent account of why the fix works, produced without executing anything.
- 05The scope creep with good manners
Four improvements you did not ask for, folded into the diff you did.
SELECTION
Choosing a model without chasing a leaderboard
| 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 |
Cost and latency belong in this table too. A slower model that halves review time is usually the cheaper one.
HONESTY
Measure what you would defend to a sceptic
| 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 |
Deliberately absent: lines generated, suggestions accepted, percentage of code written by AI. None of them survive contact with a sceptical stakeholder.
YOUR METHOD
The playbook you leave with
You will refine this in the capstone. Start here.
- ✓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.
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.
- 10 minutes on the context pack
- 15 minutes on plan and implementation
- 10 minutes writing the decision log
Use the arrow keys to move through the deck. Press N for instructor notes, A to read every slide on one page.
THIS IS ONE SESSION OF 6
The full course goes
considerably deeper.
6 modules, three applied assignments, a capstone and a final exam. Starts 2 November 2026.