Use lessons 01–01 or equivalent skills before this exercise. You can revisit them from the lesson list.
A computer and Python 3.10+. The supplied standard-library lab needs no API key, network or purchase.
Download the runnable offline builder lab →Start with the idea
Give a coding assistant a narrow change and inspect what it actually changed.
Specify allowed files and forbidden actions. Read the diff before accepting it. Run the relevant checks yourself or report that they were not run.
Diff: A comparison showing what changed between versions of files.
See the example and check your understanding
A made-up teaching example
The request permits only a starter-code validation fix. The proposed diff also changes a release setting and claims tests passed without output. Reject the unrelated change and request a scoped patch.
Ask yourself
Does “tests passed” establish execution without a command or result?
Show the explanation
No. Record observed commands and outputs. An unrun patch is an unexecuted proposal.
Start with these checks
- Inspect every changed file.
- Test valid and invalid inputs.
- Distinguish observed execution from a claim.
Use the different practice case below and check every requirement in its full instructions.
Full learning objectives
- Supply relevant files and acceptance criteria.
- Limit execution and dependency changes.
- Check actual changes and preserve rollback.
Captions appear here during playback.
Give coding assistants bounded context and inspect the diff
Give a coding assistant a narrow change and inspect what it actually changed.
Video playback is unavailable. Read the descriptive transcript below, go directly to practice, or open the video file.
Source-based teaching example · Fictional data · Reviewed 2026-10-03. Microsoft Mark · locally synthesized. On a small screen, use fullscreen for diagram details or read the transcript.
Read the descriptive transcript
0:00 · What you will learn
Give a coding assistant a narrow change and inspect what it actually changed.
What appears on screen
Give a coding assistant a narrow change and inspect what it actually changed.
0:07 · The idea
Specify allowed files and forbidden actions. Read the diff before accepting it. Run the relevant checks yourself or report that they were not run.
What appears on screen
Specify allowed files and forbidden actions. Read the diff before accepting it. Run the relevant checks yourself or report that they were not run.
0:19 · One useful term
Diff. A comparison showing what changed between versions of files.
What appears on screen
A comparison showing what changed between versions of files.
0:27 · A worked example
The request permits only a starter-code validation fix. The proposed diff also changes a release setting and claims tests passed without output. Reject the unrelated change and request a scoped patch.
What appears on screen
The request permits only a starter-code validation fix. The proposed diff also changes a release setting and claims tests passed without output. Reject the unrelated change and request a scoped patch.
0:43 · Your turn to think
Does “tests passed” establish execution without a command or result? Pause and decide before continuing.
What appears on screen
Does “tests passed” establish execution without a command or result? Pause the video if you need more time.
1:01 · Why this answer works
No. Record observed commands and outputs. An unrun patch is an unexecuted proposal.
What appears on screen
No. Record observed commands and outputs. An unrun patch is an unexecuted proposal.
1:10 · Check 1
Inspect every changed file.
What appears on screen
Inspect every changed file.
1:15 · Check 2
Test valid and invalid inputs.
What appears on screen
Test valid and invalid inputs.
1:21 · Check 3
Distinguish observed execution from a claim.
What appears on screen
Distinguish observed execution from a claim.
1:26 · Now try a different case
Open the lesson and try its different practice case. Use every check in the full task. Watching alone does not mark the lesson complete.
What appears on screen
Open the lesson Try the new case Check and revise The full task and its requirements are in the linked lesson.
Watching explains the example. Complete the lesson practice to check what you can do. Explore all visual lessons →
The method
Give a coding assistant the task, relevant files, constraints and tests. Ask it to identify needed context rather than dumping an entire repository. Separate repository instructions from untrusted issue text or file content. Record whether the harness can edit files, run commands, access the network or resume work.
Use an isolated copy or branch. Review the diff, dependencies and actual artifact before running or accepting changes. A model saying “tests pass” is not evidence unless execution output exists. If the environment is read-only or execution is unavailable, label the output as a proposed patch. Keep a way to undo changes. No exercise requires installing a paid tool or connecting production credentials.
Choose your model, harness and offline route
Text-only assistant
Use supplied text. Ask for a plan or draft; do not claim browsing, code execution or file access that was unavailable.
Tool-enabled application or harness
Record which tools actually run, allowed files and actions, approval boundaries and observable results. Tools are optional unless the task needs them.
Local or cloud deployment
Inspect inference, retrieval, connectors, logs and storage separately. Use only authorized environments for real data; training fixtures are fictional.
Higher-capability or frontier model
Evaluate the exact task and configuration. Capability does not supply missing evidence or grant permission. No provider ranking or guarantee is implied.
Offline alternative
Use the supplied inputs and inspect the worked example manually. Builder exercises use local deterministic Python. No paid account or live model call is required.
Record the exact product/model label when available, tools actually used, inputs, permitted actions, observed output and checks. Live accounts or APIs may have external costs; they are optional and are not used by this page.
Read the general workflow guide →Worked example
Supplied input
Fictional patch request: require non-empty record ID; permit only starter.py edits; no dependencies or network. Candidate diff also changes a release setting and reports tests passed without output.
A checked result
Reject the unrelated release change. Request a scoped patch and execute supplied checks locally. Record the actual command and output; if not run, say “unexecuted proposal.”
Why this works
The harness’s abilities and the observed execution determine what was done, not the assistant’s completion phrase.
Try a different case
Independent lab stage: implement parse_request in starter.py. It accepts exactly a dict with a non-empty string id and rejects extra fields. Review your diff and run the lab checker after the change.
Download this task and checklist →Interactive practice / Fictional fixture
Edit a request until its contract passes
Edit the malformed request and run the browser fixture checks. This executes a bounded JavaScript checker, not Python or an AI model.
Everything runs in this browser. No AI model is called and no work is uploaded. Bounded checks cover specific facts and rules. Your writing is not graded: you review it yourself. Practice never marks a lesson complete automatically.
This browser checks the request fixture, not your Python implementation. Run the downloaded lab separately.
Try the task, run the checks, then revise. Checks are teaching feedback, not an instructor grade.
Observed browser simulation
This trace comes from the bounded local checker. It is not a Python run, model result or production tool execution.
Keep or restore your work
Drafts are not saved automatically. Save only fictional practice data. A browser draft may be lost if storage is cleared; download a copy to keep it.
Your steps
- Read the input contract and supplied test cases.
- Implement only parse_request, manually or with a bounded AI request.
- Run python check.py and preserve output; other unfinished stages may still fail.
Check your work
- Valid IDs pass; empty, non-string and extra-field inputs fail.
- Only intended starter code changes.
- Report which checks actually passed, failed or were not run.
After your attempt: review notes and a common mistake
A parser accepting {id: "P", admin: true} fails the extra-field rule even if the normal lookup works. The reference is available only as feedback after an attempt.
Different wording or a different justified decision can pass. Check your work against every requirement; these notes are not an automated grade.
The lab’s reference.py is a worked solution. Run python check.py --reference only to inspect feedback after your attempt; passing the reference does not complete your work.
Explain your approach
What would distinguish a proposed repair from a verified repair?
Keep your artifact, one correction or decision, its evidence and one remaining limitation. Nothing on this page sends or uploads your work.
Check your understanding
Choose an answer to see feedback. This is a knowledge check, not instructor assessment.
Review your independent practice
Complete the supplied task before recording progress. Use the acceptance criteria and reveal the review notes after your attempt. Keep your artifact yourself; nothing is uploaded.
Not yet self-reviewed. Completion stays in this browser and does not issue a badge.
Optional deeper study
Explore the related general-course lesson → This opens the existing canonical lesson; it is optional depth, not another copy of this focused task.
Primary references
Revision 2026-10-03. Fictional examples, not observed provider results. Knowledge checks and completion records are self-study aids.