Specification to Working Code
Models produce working interfaces quickly, and default to generic components with missing states. Supply the system, then review the parts they always get wrong.
Definition
Turning a specification into code with a model is now a practical way to produce prototypes and production components. The design work does not disappear; it moves into what you supply up front and what you check afterwards.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
On this plate
Reach for this when
- Building a prototype to test an interaction rather than a static comp.
- Implementing a well-specified component against an existing system.
- Exploring several layout options at working fidelity.
Common mistakes
- Generic components replacing the design system.
- Missing states discovered in QA.
- Accessible-looking markup with no real semantics.
- Prototype code shipped without review.
Getting a usable result
- 1
Supply the system, not a description of it
Token names, component names and a real example of existing code. Without them the output invents its own conventions and has to be rewritten.
- 2
Specify the states explicitly
Empty, loading, error, partial, read-only, disabled. These are the states that get skipped, every time, in every tool.
- 3
State the accessibility contract
Roles, labels, keyboard behaviour and focus movement, named in the request. Generated markup is often visually correct and semantically empty.
- 4
Give real content
The longest realistic label, the empty case, the awkward name. Layouts built on placeholder text break on arrival.
- 5
Review against the things it gets wrong
Focus order, announced state changes, contrast of generated colours, responsive behaviour at 320 pixels and at 200 percent zoom.
What to expect from the first output
| Usually right | Usually missing | Usually wrong |
|---|---|---|
| Overall structure and happy path | Empty, loading and error states | Focus management after a state change |
| Common component composition | Keyboard behaviour beyond tab | Announced status changes |
| Plausible styling | Long content and overflow handling | Colour contrast of invented values |
Local chart
AI·010 · Region XII · Grid G6
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Related concept
Connected closely enough to change how you apply this.
- Feature Idea to UX SpecificationAI·004 · AI workflow
- UI to Accessibility AuditAI·005 · AI workflow
- Component Anatomy, States and VariantsSYS·009 · Design system
- Design and Code ParitySYS·010 · Design system
- Design HandoffFLOW·002 · Workflow
- Design QAFLOW·003 · Workflow
- Prototyping FidelityFLOW·005 · Workflow