Prototype to Code

Start with a static page to confirm the look, then wire real data, then cover the edge cases—each step is cheap and reversible.

Don't jump straight into code. When building pages with AI, the most common waste is asking it to generate a "complete app" all at once: page, data, and logic in one go. The order should be reversed—static page first to confirm the look, then wire real data, then cover the edge cases. Only when every step is cheap can you afford to change it at every step.

What you'll run into:

• You ask AI for the whole page, data, and logic at once, and every change pulls a chain reaction
• The look isn't confirmed yet, but APIs and states are already written
• The page "looks right," then falls apart the moment real data arrives

Static page first: confirm the look

First step, one job: have AI output the static structure of this screen. Title, list, card, button—all content is placeholder text. This version wires no data and writes no logic; its only reason to exist is for someone to confirm: does the look work? Software prototyping works the same way in traditional development: use a cheap, throwaway prototype to pin down the requirements before the real implementation.prototyping-wiki

• Have AI output only the static structure. Tell it "this screen first, as static HTML, content in placeholders"—don't let it write the data and states in passing. It over-delivers by default; you explicitly say no.
• Focus on structure, not styling. Are the fields enough, is the hierarchy right, is room left for states? Styling is the last step; staring at it now is pure waste.
• A static page is the cheapest spec confirmation there is. Editing one placeholder field takes seconds. Wait until data is wired to change the structure, and every change costs ten times as much.
• Once confirmed, the spec for this screen is set. Save the confirmed static page as your reference; the data and code steps both work against it. See spec before code.

Then wire data: confirm the shape

Second step: swap real samples in for the placeholders. What this step verifies isn't the "look," it's the "shape"—once real data flows in, does the structure still hold?

• Use real fields; don't invent another sample. Only real data knows how long and what format real nicknames, titles, and comments are. Sample data is always "just right"; real data isn't.
• Check three things: length, nulls, and formats. Does an oversized value wrap, what does a null show, are time, money, and image formats correct? Everything the static page had no room for shows up here.
• This step turns the spec from "look" into "shape." The earlier step set what it looks like; this one sets what it means for "nothing breaks no matter what data comes in."

Finally cover edges: confirm the fallbacks

Third step: cover the edge cases. Loading, load failure, empty data, oversized content—look at each of the four states once. Only after this pass is the screen really ready to hand to AI for the full code.

• Edge cases only surface after data is wired. Handling them early means guessing: you don't know yet how real data will burst the layout. In order, edges must come after data.
• An empty state is designed, not incidental. What shows with zero rows, and what's the next action? Think it through. See cover all four states.
• Only after edges are confirmed does writing code actually begin. Now you hold: a confirmed static page, a shape that holds real data, and fallbacks that hold the edges. Only then does the AI prompt have material to work with. See three-part prompt.

Remember the payoff of this order: every step costs almost nothing to roll back. Static page wrong? Edit a few placeholder lines. Data comes in and the shape breaks? Swap the structure. An edge leaks through? Add two states. The other way around—build the whole app first—and any change means cutting into a tangle of interdependent code.