Exercise 1: Why a JSON Spec Instead of Raw HTML/JSX — Possible Solution
====================================================================

Asking a model to generate raw HTML or JSX directly means trusting the
model to produce syntactically valid, safe, on-brand markup every
single time, with no real structural guarantee in between the model's
own output and what actually gets rendered on the page. Any small
mistake in the generated markup - a malformed tag, an unexpected
attribute, a component that doesn't exist - becomes a real runtime
problem the moment it's rendered.

JSON Render's approach adds a real structural boundary in between: the
model only ever produces a JSON spec, not markup itself, and that spec
is checked (via Zod validation) against a known schema before a
separate renderer turns it into actual components. This means the
model is constrained to describing *which* known components to use and
*what* props to pass them, rather than being free to generate
arbitrary code - a genuinely narrower, safer surface. It also means
the same spec can be rendered by more than one renderer, which is
exactly the "same components, browser or AI agent" reuse this course
builds toward in Chapter 4.

ANSWER: Generating a JSON spec instead of raw HTML/JSX adds a real
validation boundary (via Zod) between the model's own output and what
actually renders, constraining the model to a known, safe set of
components rather than arbitrary markup - and it means the same spec
can be rendered in more than one place, which raw generated markup
tied to one specific output format couldn't do.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the real structural benefit (validation and
constrained output) the spec-based approach provides over raw markup
generation, and connects it to the course's own later "render
anywhere" theme rather than only restating that JSON Render "uses
JSON."