Riley Brown: Turn a Prototype into Observable Checks
How do I tell whether an AI-built prototype does the job I intended?
Choose, practice, reflectA practical learning exercise
The Lesson
An app can look finished while its most important behavior remains unclear. A timer may display a handsome countdown but start two timers when you press the button twice. A task list may accept an item but lose it when you reopen the page. A screenshot cannot tell you what happens next.
In the transcript published with Riley Brown’s interval-timer demonstration, Brown asks an AI coding tool for work and rest durations with repeated intervals. He then requests a larger timer display and a countdown before it starts. He refreshes the prototype and checks its start and rest behavior. That sequence gives us a concrete example to learn from: ask for a behavior, try it, then inspect a change.
Turn your own idea into a short sequence of visible states. For a timer, those might be ready, starting, working, resting and complete. For a reading list, they might be empty, item added and item removed. Each transition needs an action and an expected result. “Make it work” leaves both uncertain.
Write the expected result before trying the prototype. You can then compare the app with an independent description of its job. If you decide what success means only after seeing the output, it is easy to accept whichever behavior the tool happened to create.
Keep code review and behavior checks separate. Cursor’s Agent Review documentation describes a review of local code changes. That is another useful inspection, but a review result does not establish that your particular screen, timer or saved item behaved as you intended. Try the user action as well.
For a first learning project, choose a local prototype with fictional inputs. A successful demonstration is a reason to continue checking; it does not by itself establish security, accessibility, data protection or readiness for a public launch.
Reflection
- What is the smallest useful sequence your app should complete?
- What can you observe at each stage without reading its code?
- Which action could be pressed twice, interrupted or repeated?
- What should happen after completion?
- Which promise, such as saving data, have you assumed without checking?
Practice
Original SelfGrowthVideos exercise: write a behavior card for a tiny timer. This is our exercise, not Brown’s checklist or an endorsed method. You can draw the screens on paper; building an app or buying a tool is optional.
- Set a small trial. Use a ten-second work interval, a five-second rest and two work intervals. These short durations are test inputs, not a productivity recommendation. Decide whether rest occurs only between work intervals or after the final one too.
- Write the route through the states. Ready → starting → work 1 → rest → work 2 → complete. For this trial, specify a three-second countdown before work 1 and no rest after work 2. Write what the screen should show at each stage.
- Add three checks. Pressing Start once should enter the countdown. Work 1 should lead to one rest interval. Work 2 should lead to completion with the timer stopped. Record the expected display and the observed display beside each other.
- Try one awkward action. Press Start twice during the countdown. Decide beforehand that the second press should be ignored or disabled. If there are two overlapping timers, record that failure rather than treating the polished screen as a pass.
- Request one specific correction. Describe the input, the observed behavior and the expected behavior. Ask for a draft change only. Review the change, repeat the failed check, then repeat the ordinary sequence to see whether the correction broke it.
- Keep the boundary visible. Label the result a learning prototype. Record what you have not checked, including behavior on another device or after reloading. If you only drew screens, mark the sequence as designed, not tested.
Review
Ask another person to follow your behavior card without explaining it aloud. Can they identify each state and tell whether the check passed? Revise an ambiguous expectation before adding features. Keep one failed case in your notes so the next revision has a reason and a repeatable check.