Reviewing What the AI Built

The AI builder's summary said: "Done! Allergy filtering is implemented and tested." Asha added peanuts to her allergy list, asked for dinners, and got satay noodles. The filter code existed. Nothing ever called it.

The rule

"Done" is a claim; check it against your acceptance checks.

AI builders write fluent, confident summaries whether or not the work is right. Generated code tends to go wrong in recognisable ways:

• Fakes left in — sample data, placeholder functions, "TODO" notes, or a hard-coded answer from the skeleton that never got replaced.
• Missing wiring — the right code exists but is never used, as with Asha's filter.
• Happy path only — works for the example in the brief, breaks on an empty pantry, an odd spelling or a failed call.
• Unsafe shortcuts — a secret key in front-end code, a check done only in the browser, one user's data readable by another.
• Claims without proof — a summary that says tests exist, or pass, when they do not.

The shortcut

Use it, break it, peek under it. Three passes, in that order, for every slice.

Then report what you found precisely: what you did, what you expected, what happened. "With a peanut allergy and noodles in the pantry, a satay dish appeared. The filter function exists but the suggestion route never calls it." A precise report gets a precise fix.

You do not need to understand every line to peek usefully. Searching for a key's name, a "TODO" or a fake dish name takes seconds, and later lessons in this course show you how to read more.

Keep the effort in proportion to the risk. A new button label needs a glance. Anything that touches allergies, money, sign-in or one user's data being seen by another gets all three passes, every time.

Drills

Answer fast — trust the rule.

Remember

• "Done" is a claim; check it against your acceptance checks.
• Use it, break it, peek under it, for every slice.
• Trap: trusting fluent summaries. Watch for fakes, missing wiring, happy-path-only code and exposed secrets.