Back
beginner

Real-World AI Tools

How do you judge an app built from a description?

Turn an app idea into observable behavior and test persistence, errors, and accessibility beyond the first screen.

Lesson 27 of 31About 25 min with practice

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.

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.

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.

Continue to the next lesson.

Practice for this lesson

Write acceptance examples for a generated app

Judge a described app by behaviour you can run, and know where your data lives.

About 9 min40 points3 checks and one written task
Loading your lesson progress...