Back to writing

Writing / AI Engineering

Design to code needs a contract, not a better prompt.

AI can write convincing UI with the wrong design system. The reliable path is to retrieve the exact contract, compose only what is needed, and verify the result.

DateAug 13, 2026
Read time7 min read
TagsDesign Systems · AI Agents · Frontend Engineering
Design to code needs a contract, not a better prompt

Everyone working with coding agents has seen the same failure. The agent writes polished, competent UI, but it belongs to someone else's design system.

The spacing is plausible. The components are familiar. The code is clean. It is also full of public component imports, hard-coded values and conventions that do not exist inside the company.

That is not mainly a model capability problem. The model is following a strong public prior because the internal system is invisible.

The problem

A polished result can still be wrong.

The model is not incapable. It is uninformed.

What it actually shipped

Public component imports
Hard-coded hex values
A type scale that is not ours
Competent, convincing, and built from someone else's system.

The prior wins when the contract is missing.

A polished operations dashboard can still be wrong when it ships public components, hard-coded values, and another system's type scale.

Giving the model a larger prompt does not solve this reliably. More documentation creates more context to search, more instructions to forget and more room for details to drift between requests.

The same screen can come back one prompt later with different radii, spacing, alignment and emphasis. It may still compile. Nothing blocks the merge.

Context drift

The same screen, one prompt later.

Nothing holds the details in place.

Design detailPrompt 01Prompt 02
Radii8px14px
Spacing16px21px
AlignmentGridMixed
EmphasisToken scaleAd hoc

Nothing here blocks a merge.

The same dashboard can drift between prompts in its radii, spacing, alignment, and emphasis without blocking a merge.

The fix is a smaller contract

A prompt describes what to make. A contract defines the small set of rules the result must obey.

That distinction changes the job. Instead of asking a model to remember an entire design system, the system retrieves the exact source, tokens and guidance for the component in front of it. It expands the context only when complexity demands it, then checks the result independently.

The turn

The fix is not a better prompt. It is a smaller contract.

RetrieveComposeVerify
The fix is not a better prompt. It is a smaller contract that can be retrieved, composed, and verified.

The loop has four controls. A start hook begins the workflow. An index retrieves the relevant contract. A recipe adds detail for complex components. A Doctor validates the generated output after the model finishes.

The coding agent remains the orchestration surface. Reliability comes from the controls around it.

System architecture

Four controls. One governed loop.

The agent orchestrates. The surrounding system supplies control.

01 · Start hookAuto-run
02 · IndexRetrieve
Orchestration surfaceCursorPrompt / edit / tool call
03 · RecipeOn demand
04 · DoctorValidate
A governed design-to-code loop surrounds the coding agent with a start hook, retrieval index, optional recipe, and independent Doctor.

Retrieve the exact contract

The index should answer one narrow request at a time.

For a data grid, it can return the internal source package, the approved surface and border tokens, and focused guidance for columns, density, selection and keyboard behaviour. The agent does not need the whole system. It needs the contract for this component.

That contract is small enough to inspect and specific enough to verify.

Retrieval

Retrieve the exact contract.

One request follows precise pointers instead of loading the whole system.

RequestDataGrid
Source@internal/data-grid
Tokenssurface.canvas · border.subtle
Guidancecolumns · density · selection · keyboard

Small, exact, verifiable.

A DataGrid request resolves to its internal source, approved tokens, and focused behavioral guidance.

Expand only where complexity demands it

A button should not carry the same context as a data grid or chart.

Simple components can move directly from contract to code. Complex components can branch through a recipe that adds states, behaviour, accessibility and data-shape rules. Complexity becomes opt-in instead of ambient.

This keeps the common path fast while giving difficult components enough structure.

Composition

Complexity only when needed.

The common path stays direct. Extra context appears only at the branch.

Simple path · default context

  1. Component
  2. Contract
  3. Code

Complex path · expand only at the branch

  1. Data grid / chart
  2. Contract
  3. Recipe
  4. Code
States / behavior / accessibility / data shape
Simple components move directly from contract to code while complex components add a focused recipe only at the branch.

Make done mean green

Generation is a claim. Validation is proof.

An independent end hook can check imports, tokens, component APIs and design rules. The result is complete only when those checks pass. This catches failures that a model may not notice in its own output and turns design-system compliance into something a team can inspect.

The Doctor does not need to judge whether the screen is good. It only needs to verify the parts that can be made explicit.

Validation

Done means green.

An independent end hook checks the work after generation.

ImportsPass
TokensPass
Component APIPass
Design rulesPass
GREENVerified output. Not a claim.
The Doctor checks imports, tokens, component APIs, and design rules before declaring the generated output verified.

Turn Figma noise into implementation intent

The raw Figma tree is not a useful contract. It contains frames, groups, rectangles, gridlines and generated layer names that describe how the file was built, not what the interface means.

A small semantic screen spec can preserve the useful parts: component identity, position, copy, props and tokens. The transformation removes layer noise without replacing exact values with a vague summary.

The model receives implementation intent instead of a serialized drawing tool.

Design input

Turn Figma noise into implementation intent.

Keep exact implementation facts. Remove layer-tree noise.

Raw Figma treeFrame / dashboard  Group 384    Rectangle 522    Text 1107  Frame 401    Gridline 01 … 48    Instance 73
Screen Spec MDCollapse noiseOffline · Deterministic · Exact
Semantic screen spec
ComponentButton
Position[62, 29, 12, 4]
CopyConfirm assignment
Tokentext / tertiary
Screen Spec MD turns a noisy Figma layer tree into a small semantic specification containing component, position, copy, and token information.

Define once, execute repeatedly

A stronger model can help define the framework: component contracts, complex recipes and Doctor checks. Once those parts are stable, smaller models can execute a narrow contract repeatedly.

This is not a promise that every task belongs on a smaller model. It is an operating strategy. Move durable reasoning into inspectable contracts, then spend model capability where judgement is still required.

Model strategy

Define once. Execute repeatedly.

Move durable reasoning into a small contract, then replay it.

Large modelDefine the frameworkContracts / recipes / Doctor
Verified contract~30 focused linesSource / tokens / checks
Small model · execute
Small model · execute
Small model · execute
Doctor feedback
A larger model defines the framework once, then smaller models repeatedly execute a narrow verified contract with Doctor feedback.

Start with one component

This does not need to become a platform programme.

Start with one component. Write its contract, connect it to the index and prove that the Doctor catches a violation. Then use that component in one complete screen and add the first recipe. Only after the workflow works end to end should it expand to a team.

Coverage should grow through use. A contract earns its place by helping ship a real interface.

Rollout

Adopt it one component at a time.

Each stage produces a working contract before the next one begins.

Stage 01One componentWrite the contract, wire the index, and prove the Doctor catches a violation.
Stage 02One screenAdd the screen spec and first recipe. Generate the screen end to end.
Stage 03One teamHooks run by default. Contracts become the review surface.

Coverage grows with use, not with documentation.

The rollout grows from one component to one screen and then one team, producing a working result at every stage.

What the system cannot decide

A contract governs construction. It does not replace design judgement.

It cannot decide whether a screen should exist. It cannot retrieve a contract for a genuinely novel component. A green check also does not remove the need for review. It narrows review by clearing the mechanical questions first.

Designers and engineers can spend their attention on the decisions that remain open instead of repeatedly checking imports, tokens and known component rules.

Limits

What the system does not do.

The contract governs construction. It does not govern judgment.

Product judgmentWhether the screen should exist is still a design decision.
Novel componentsAnything outside the system has no contract to retrieve.
ReviewA green check narrows what review must inspect. It does not replace it.
The system does not replace product judgment, invent contracts for novel components, or remove human review.

The operating model

The full path is simple: picture, intent, contract, code, proof.

Figma provides the picture. A semantic screen spec extracts intent. The CLI retrieves the contract. The model writes the code. The Doctor provides proof.

Every handoff can be inspected. That is the real advantage. Reliable design-to-code does not depend on one perfect prompt or one perfect generation. It depends on a system that makes the model's inputs and outputs visible, narrow and testable.

The operating model

Picture → intent → contract → code → proof.

Reliability comes from making every handoff inspectable.

01PictureFigma
02IntentScreen spec
03ContractCLI
04CodeModel
05ProofDoctor

Reliable AI is inspectable AI.

The operating model moves from picture to intent, contract, code, and proof, making every handoff inspectable.

Reliable AI is inspectable AI.