Learn the craft with an LLM in the loop

If you build software today, a language model is already writing some of your interface. The risk isn't that the code is wrong — it's that it's plausible: it runs, it looks fine, and you never learn why it works or where it quietly fails. Motif is built for the opposite outcome. Use it to drive the model instead of being driven by it.

Here's a workflow that turns "the AI made a thing" into "I understand and own this thing."

1. Name the pattern before you prompt

Vague prompts get vague UI. The fastest upgrade to anything a model builds you is naming the specific technique you want. That's what the curriculum is for — it gives you the vocabulary.

Don't ask for "a nice loading state." Read loading and skeletons first, then ask for "a content skeleton that mirrors the card's layout so there's no layout shift when it swaps in." The second prompt can't produce a janky spinner; the first invites one.

2. Make the model show its work

Once you have output, don't just paste it. Drop it into the playground — the lesson's own examples open there in one click — and change one thing at a time. Bump the spring stiffness. Remove the prefers-reduced-motion guard. Delete the aria-pressed. Watch what breaks.

This is the part no amount of generated code gives you: a feel for which lines are load-bearing. The demo beside every lesson is there for the same reason — drive the controls until the cause-and-effect is obvious, then read the code.

3. Demand the constraints that models drop

Models optimize for code that looks done, which means they routinely skip the things that don't show up in a screenshot. When you ask for UI, ask for these every time:

• Real semantics — a <button> is a button; state is exposed (aria-pressed, aria-invalid, a live region), not faked with a <div>.
• Keyboard operability — every interaction works without a mouse, with a visible focus ring.
• Reduced motion — animation is disabled under prefers-reduced-motion: reduce.
• Compositor-friendly animation — transform and opacity, not layout properties, so it stays smooth.
• No color-only meaning — state is carried by text or shape too, so it survives color-blindness and grayscale.

A compact way to bake this into any request:

const UI_GUARDRAILS = `
When you write interface code, you must:
- use real, semantic elements and expose state via ARIA (not div soup);
- make every interaction keyboard-operable with a visible focus-visible ring;
- disable animation under prefers-reduced-motion: reduce;
- animate only transform/opacity, never layout properties;
- never convey meaning by color alone — pair it with text or an icon;
- meet WCAG AA contrast for text and UI.
If a requirement conflicts with the request, say so instead of silently dropping it.
`;

Paste that ahead of your task and the model stops handing you inaccessible defaults. The accessibility track explains why each line matters, so you can argue with the model when it pushes back.

4. Verify against the real mechanics

The last step is the one that compounds. When the model explains its own code, check the explanation against the lesson, not against your gut. Does its account of the rendering pipeline match how the browser actually paints? Did it pick :has() where a container query was the real tool? Models are confident narrators; the curriculum is the ground truth you measure them against.

Over a few weeks this flips the relationship. You stop accepting generated UI and start commissioning it — specifying the technique, the constraints, and the failure modes up front, then verifying the result. The model gets faster; you get better. That's the whole idea.

Where to start

• New here? Read how to use Motif first.
• Want the prompts? They're all in the prompt library.
• Want to go deep on the safe way to put a model inside your UI? See the generative-ui track — declarative UI, tool UIs, and the bring-your-own-key pattern.