Jump to a section
I do not ask an assistant whether the change is good. I ask it to show the request, the files, and the check. Then I read the diff the way I would read a junior engineer’s pull request.
Take this with you
Keep a change only when you can name the requirement, point to the files, and run a check that would have failed before the fix.
01
Start from the requirement, not the files
A useful review begins with one sentence the user can verify: “A shopper can filter the existing catalog by name, see an empty state, and clear the query.” If that sentence is missing, I do not discuss style. I send the assistant back to write the requirement and the check.
02
Make it prove the code exists
Models invent helpers, endpoints, and gem APIs that look confident. I ask for a list of every new method and where it is defined in this repository or in official documentation. Anything that cannot be pointed to is treated as untrusted.
A prompt to try in your project
List every method, constant, and endpoint this diff introduces. For each one, cite the file in this repository or the official docs. Flag anything you cannot prove exists. Do not add more code.
Want to see this teaching style before buying?
The free sample turns a vague design request into a change you can check.
Read the free course lesson →03
Run the failure case
A happy-path screenshot is not evidence. I want the empty search, the sold-out product, and the second browser tab. If those cases were not exercised, the change is not finished.
04
Ask what else this can break
Quantity on a cart looks local and rarely is. I ask which existing behaviors share the price, the stock check, or the session. The answer tells me whether the change is small enough to keep.
- The requirement is one sentence I can test.
- Every new symbol is defined in this repo or official docs.
- A failing check existed before the fix.
- The empty and invalid cases were run.
05
Use the same habit on your project
This is the review loop taught in Build Your First Real App. If you want the prompts without the full course, the free ten-prompt guide is the short version I actually use.
Build Your First Real App
Practice this review on a real project.
The course walks the same checks through a marketplace: catalog, cart, and practice checkout, with a visual target and a save point after each feature.
- Requirements and a reviewable plan · pp. 10–18
- Debugging workshop · pp. 70–95
- Tests and checkpoints with each feature
120-page PDF + visual kit · $29.99 · one-time purchase
Self-paced reading and building. The kit is a browser prototype; you build the Rails app. Checkout uses practice orders.
Questions you might have
Can the assistant review its own work?
It can summarize a diff. It cannot replace you running the check and reading the files. Treat its review as a first pass.
What if I cannot yet read the language?
You can still demand a requirement, a file list, and a browser check. The course exists to attach names to those parts as you go.
