Build with AI: From Zero to Your First App · Module 4: Your first webpage with AI
Ask for Fixes by Pointing at Screenshots
Visual bugs are location problems: the tool needs to see where, not just what. This lesson turns 'it looks wrong' into a screenshot plus one sentence that aims the fix.
9 min reading
Objectives
- Attach a screenshot that shows the exact fault location
- Write the one-sentence pointer the tool needs with the image
- Separate what moved from what must stay in visual requests
- Verify a visual fix at both widths before accepting
Why this matters
"The menu is broken" sends the tool guessing across the whole page; the fix lands near the fault if you are lucky. A cropped screenshot with "the third dish price sits under the name at 360px width" sends it to one line. Visual debugging is pointing: image shows the spot, sentence names the expectation, fence protects the rest.
Concepts
The useful screenshot is cropped to the fault plus a little context: the broken element and its neighbors, not the whole desktop with open tabs (lesson M01L4's crop rule). Include the width: "at 360px" or "on desktop". One fault per screenshot; two faults mean two messages, same one-change rule as ever.
The pointer sentence has three parts: where ("the third dish row"), what is wrong ("price drops under the name"), what good looks like ("price stays right-aligned on the same line at 360px"). Attach the keep-list: "keep all text, colors and the form; change only the menu row layout." The tool now has location, expectation and fence.
After the fix, run the two-width test before accepting: 360px and desktop, eyes plus one tap. Visual fixes love to repair one width by breaking the other. Accept only when both pass; otherwise follow up pointing at the newly broken width with a second screenshot.
Worked example
Vague: "The menu looks bad on my phone." Likely outcome: full menu redesign, new colors, moved sections. Pointed: screenshot of the third row at 360px plus "the price drops under the dish name; keep text and colors, keep rows stacked, keep the price on the same line right-aligned at 360px." The edit touches one layout rule; verification is one narrowing. Same fault, different message, different project afterwards.
Expected result: one real visual fault reported as screenshot plus pointer plus fence, verified at both widths.
The common wrong move
Circling the fault in a full-page screenshot with no sentence ("see attached, fix it"). The circle says where; without the expectation sentence the tool still guesses what good looks like.
Lab and next step
Lab A12 practices pointed requests: three faults, three screenshots described in words, three keep/change/check revisions. Next, module M05 turns the page into an app: inputs, calculations, validation and browser storage.
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
Report one real visual fault on your page as a cropped screenshot plus pointer sentence plus fence. Record the two-width verification after the fix.
Pass criteria
Screenshot cropped to fault plus context with width stated; pointer sentence (where, wrong, good); fence naming protected parts; both-width verification recorded.