Build, inspect, and improve the first loop

Choose the next useful question

Once you have a draft summary, ask what blocks the next step. If the delivery area is missing, ask for an area before pretending to compare local restaurants. If the user has already supplied it, avoid asking again.

Use a small sequence: read → extract → validate → clarify → update. A correction updates the relevant field while preserving earlier requirements. “Actually vegetarian” should not erase the budget.

Open the Dinner Request Lab beside this lesson. It uses explicitly labeled sample responses, so you can inspect the workflow without an API key. It does not call a model or place an order.

Check your understanding

The user gave their budget and dietary needs but no delivery area. What should come next?

Check structure and meaning separately

The lab has an editable JSON box. Delete a comma and validate: the application should explain that the format cannot be read. Restore it, then change the budget to 250. The format may pass even though the meaning is wrong for a $25 request.

This is the difference between structural validation and semantic checking. Structural checks catch missing fields or wrong types. Comparing the output with the original request catches a well-formed but incorrect interpretation.

An honest recovery message explains what failed and gives the user a way to retry. Avoid showing a stale “success” summary after the current response fails validation.

Check your understanding

Make one change and observe the result

In the lab, load the worked example, validate it, and read the suggested clarification. Enter a fictional area using the follow-up field and update the summary. Then load the vegetarian correction case and confirm the $25 budget survives.

For the guided build, save the lab page to your computer and open its source in a text editor. HTML defines the page; CSS styles it; JavaScript supplies behavior. Search for nextQuestion. Change the wording of the delivery-area question, save, and refresh. The question should change without altering the budget.

Keep a baseline before using AI-assisted coding. Ask your coding assistant: “Explain nextQuestion line by line, then change only its delivery-area wording. Preserve the rest of the behavior and show me how to verify it.” Inspect the change yourself.

Extra model calls can add waiting time and cost. Begin with the smallest working loop and measure it before adding more steps. In this local simulation, the displayed validation duration is browser processing time, not model latency. A live extraction model and DoorDash connection are later course milestones.

Check your understanding

What should happen when the extraction response cannot be parsed?

Save your module check-in

Record your five test outcomes, one bug or mismatch you found, the wording you changed, and why you prioritized that follow-up question. Finish with: what can I explain independently, and what do I want to revisit?

Before Module 2

Key takeaways

• Start with a small, inspectable workflow.
• Clarify missing details without erasing earlier constraints.
• Validate both response structure and meaning.
• Practice a failure and its recovery before adding live services.