Build with AI: From Zero to Your First App · Module 6: Working reliably with AI coding tools
One Change, Narrow Scope
Reliability starts with size: one change per request in named files. This lesson makes smallness a habit that survives deadline pressure.
10 min reading
Objectives
- Keep each AI task to one change in a narrow file scope
- Refuse bundled requests by splitting them before sending
- State the file scope explicitly in every request
- Verify single-change diffs by reading before accepting
Why this matters
Every chaotic AI session has the same shape: five changes in one message, a diff touching four files, one regression nobody can attribute. Smallness is the fix that costs nothing: one request, one change, named files, a minute-check. Professionals batch for speed; beginners batch for chaos. Earn batching later by proving single changes first.
Concepts
The unit is one change in named files. "In styles.css only: dish names larger than descriptions at 360px." File scope stated, change singular, criterion attached. When the diff returns touching one file as ordered, trust is earned. When it touches three, the scope leaked and the extra must be reverted or reviewed line by line, never waved through.
Splitting is the skill. "Restyle the menu, fix the form and add photos" becomes three messages sent in dependency order: structure-affecting first, styling second, additions third. Splitting before sending beats untangling after receiving, every time. Lesson M02L7's step logic applies to messages: narrow, ordered, checkable.
Saying no to yourself. Deadline pressure whispers "send it all, sort it later". Later never comes; the tangle compounds. The habit is a sentence you say out loud: "one change, named files, then check." Speed comes from fewer repairs, the same lesson as M02L8, now applied to the editor.
Worked example
Bundled: "Update the menu styling, fix validation messages and add a photo gallery." Result: styles change, validation rewrites with cleared values (a M05L18 regression), gallery with broken paths; two evenings to untangle. Split: message one fixes menu rows (verified at both widths), message two fixes validation wording (verified by multi-fault submit), message three adds the gallery (verified image by image). Same work, different week: one debuggable, one decorative.
Expected result: your next three edits sent as three single-change messages with file scope and checks recorded.
The common wrong move
Scope creep by politeness: accepting the tool's extra "improvements" outside the fence because rejecting feels rude. Extras are unverified changes. Thank, revert, re-request the single change.
Lab and next step
Lab A16 splits a bundled request into three aimed messages. Next, lesson 22 adds the safety net: snapshots before changes and clean rollbacks.
Quick check
An optional 4-question self-check. Answers never leave your device, are not stored, and never count toward any assessment.
Lesson feedback
No published feedback yet.
Log in and complete the lesson to leave feedback.
Exercise
Take one bundled request you want to send. Split it into three single-change messages with file scope and criterion each. Send them in order, recording each check.
Pass criteria
Three messages, each one change in named files with a minute-check; sent in dependency order; checks recorded per message.