Why a spec, first — Prompt to Production

1. Principle

The model is a fluency engine, not a clarity engine.

Hand it a vague prompt and it will produce something every time. The trouble is that "something" is different every time. Two runs of the same vague prompt produce different code, different shapes of data, different assumptions about what you wanted.

A spec is what makes the output stop drifting. Without it, you are not building a product, you are sampling from a distribution and hoping the sample you like is reproducible.

This first unit is free because the rest of the course is bought with this idea. If you stop here understanding only this, the course already paid for itself.

2. Do (you try)

Below is a vague one-line prompt and three responses a model produced from it. Read all three. Do not skip ahead.

Stability Check (stubbed — runs on canned samples until server proxy ships)

Prompt

Build me a simple feedback widget for my website.

Sample output 1/3

// Run 1
<form action="/api/feedback" method="POST">
<textarea name="message" required />
<button>Send</button>
</form>
// Server stores to a JSON file. No email field. No admin view.

Each run should give a similar answer if your prompt is stable.

List every meaningful difference across the three runs. Each difference = a hole in the prompt.

3. Verify (how you know)

Count your differences. Each one is a decision the prompt left to the model. The model picked. It picked differently each time.

Now ask yourself: of the things you listed, which would you actually want to decide yourself, and which were you willing to let the model pick?

Almost certainly the answer to the first question is "most of them." That gap — the things you would want to decide vs. the things you left blank — is the spec you have not written yet.

4. Reference

Locked. Try it yourself first.