You describe a reading tracker and receive a beautiful page with three books and a progress chart. After refreshing, your changes disappear. The builder produced a convincing interface, but did it build the application you meant?
Before you begin: Understand that generated code needs verification. No coding is required for the planning exercise.
Describe behavior, not only appearance
AI app builders can generate and edit application code from natural-language requests. Lovable and Bolt are examples; their supported integrations, hosting arrangements, and account limits vary. A generated screen is a starting point to inspect, not automatic evidence of a complete or secure product.
For a first project, specify a small reading tracker: add a title, mark it finished, edit the title, and remove an entry with a clear confirmation. Decide where data lives. A device-local prototype and an account-based service have different requirements, even if their screens look the same.
Use invented book titles in the first version. You do not need private information, payments, or broad external connectors to test the core flow.
Write acceptance examples
An acceptance criterion describes behavior you can observe. “Looks professional” is subjective. “After refreshing the page, my saved reading list is still present” tests a concrete requirement.
Write examples for an empty list, a long title, duplicate titles, a failed save, and use on a narrow phone screen. If the product uses accounts, add a two-account test: one person's entries must not appear for the other. A login page alone does not prove the data is separated.
Does the generated screen protect the actual booking rule?
A signup form can look finished while allowing two people to reserve the last place. The important requirement lives in the behavior when events overlap, not in the appearance of the button. Write examples that describe what should happen for a valid signup, a full class and a repeated submission.
Use those examples to inspect the generated app. Ask where the capacity rule is enforced and what the user sees when a request fails. Hiding a button in the interface does not protect an endpoint that still accepts the request. The challenge gives the builder a behavior contract that can be checked independently of the generated layout.
Two users both see “1 place left.”
They submit at nearly the same time.
The system must confirm at most one reservation and give the other user a clear result.
Build a small vertical slice
Ask the builder to implement one complete path: add an entry, save it through the intended storage layer, and show it after reload. Then inspect that path before asking for charts, badges, or animations. This gives you evidence that the underlying behavior works.
When something fails, describe the input, expected behavior, observed behavior, and steps to reproduce it. “Everything is broken” gives the tool little to isolate. “I added Cedar at 14:05, refreshed, and the list became empty” is much more useful.
Locate the storage boundary
Browser storage is tied to a browser and device and may be cleared. A server database can support multiple devices, but it needs an authenticated identity and access rules for each record. Neither setup should be presented as the other.
For an account-based tracker, the server should determine the owner from the authenticated session. A client-submitted owner ID is not enough. Ask the builder to explain and show how reads and writes are scoped, then verify with separate test accounts before using real data.
Check the generated interface as a task
Can someone add a book with a keyboard? Does the form have a visible label? Is an error shown if saving fails, or does the UI pretend the entry is saved? Can a long title wrap without hiding the action controls on a phone?
These questions improve usability more directly than adding decorative gradients. Use motion to communicate a state change when it helps, and respect reduced-motion preferences. Keep essential information in readable text.
Keep an exit path
Before depending on a builder, inspect source export or synchronization, data export, hosting ownership, backups, and the process for recovering a broken version. Exact options change by product and plan, so check official documentation for the account you use.
You do not need to become an expert in every generated file at once. You do need enough understanding to know what is stored, who can access it, and how a failed change can be reversed.
Evaluate a demo
The tracker displays a “Saved” message immediately after clicking, before the server responds. The network request then fails. What behavior should you request?
Make the state honest
Show a saving state while the request is pending and report success only after storage confirms it. If the request fails, keep the entered title available, show a clear error, and allow a controlled retry. An optimistic display can be useful, but it must reconcile failure instead of presenting unconfirmed persistence as fact.
Practice with feedback
Write acceptance examples for a generated app
You describe a workshop sign-up app to a builder tool. It generates something that looks right in ten seconds.
Judge a described app by behaviour you can run, and know where your data lives.
Check your understanding
Your task
Write five acceptance examples and the exit path before you build a second screen.
These notes stay on this page. Download them before leaving.
What to include
- At least two examples cover failure or edge behaviour
- Each example is concrete enough to run by hand
- The slice covers submit through to visible result
- The exit path names a real export format and the work required
Compare with a worked answer
Here is one way to answer. Check how it uses the information in the task.
Acceptance examples: 1. Given Advanced Sewing has 4 places, when Ana submits a valid sign-up, then a row appears in the list and she receives a confirmation naming the day, time and room. 2. Given Ana already signed up, when she submits again with the same email, then no second place is taken and she sees 'you are already on this list'. 3. Given the class has 0 places, when Ben submits, then he is waitlisted with a position number and no confirmation of a place is sent. 4. Given the email field is empty, when Ben submits, then the form refuses with a message beside the field and nothing is stored. 5. Given the sign-up succeeded, when the organiser opens the list on a phone, then they can see and edit the row without a desktop.
The vertical slice I will build first: example 1 only, end to end, including the real email. Everything else waits.
Storage: records live in the vendor's hosted table. Export is CSV from the admin screen, manually, one table at a time. There is no API on our plan. If I had to leave next month: export three CSVs, rebuild the form on a spreadsheet with a script, re-point the noticeboard QR code. About a day, provided I keep the field names stable and do not rely on any vendor-computed column. That is cheap enough to accept, and I wrote it down so it stays true.
When you are signed in, opening the challenge carries your edited working notes into its draft in this browser. The challenge has its own completion record. Practising here does not award points or mark it complete.
Next, we will distinguish an assistant that drafts an answer from an agent that chooses and executes tool actions.
References
Lovable's introduction and Bolt's official site describe their development platforms. The tracker requirements above are an original exercise, not claims that a particular builder has passed these checks.