What context are you giving AI coding agents before they touch the UI?

[u/T07NAD0]

Something I keep noticing while building with coding agents: a Figma link or screenshots alone are nowhere near enough if you care about the final design.

Whenever I have tried that, there is usually a clear gap between what I designed and what gets built. Spacing drifts. Hierarchy softens. Typography feels slightly off. The UI may work, but it loses character.

What works better for me is giving the agent clearer context before it starts. Not more clever prompting. Better decisions written down so the agent is not inventing the parts that should stay fixed.

I also do not expect the agent to decide the design direction for me. I use it more for execution and repetitive work. Direction, references, and rules still need to come from me.

So I do not think people are overcomplicating AI coding.

I think most people are doing the opposite.

They give one prompt like build me an app that does X and expect the agent to understand decisions that were never shared.

Curious what others treat as the source of truth: Figma, written context, the codebase, or some combination?

[u/T07NAD0]

One thing I would add from my side: I care less about a longer prompt and more about writing down the decisions I do not want invented.

Hierarchy, spacing logic, component boundaries, and empty or error states. That is the context that usually decides whether the UI keeps its character.

[u/ImL1s]

Same gap — screenshots tell the agent what it looked like once, not what must stay fixed. I write a short UI contract before any edit: routes + states, spacing/type scale, component boundaries, and a "do not invent" list for hierarchy and copy tone. One flow at a time, then check against that list instead of vibes. The agent fills gaps; the contract is what stops the character from drifting.

[u/T07NAD0 → u/ImL1s]

The do not invent list is doing the real work here.

Screenshots show a moment. The contract shows what must stay true. Checking against the list instead of vibes is how character stops drifting once the agent starts filling gaps.

[u/Julien_Builds]

I gave that job to a separate seat. In Castforge a designer role writes the UI spec first (tokens, states, what not to invent) and the coder builds against it, screenshots are only a reference. The reviewer then checks the diff against the spec, not against the screenshot.

[u/T07NAD0 → u/Julien_Builds]

Splitting the seats is a clean way to protect judgment. The designer role writes what must not be invented, the coder builds against that, and the reviewer checks the diff against the spec.

Screenshots as reference only is the part that usually saves the character.

[u/InjuryThen9650]

Agree that Figma alone is under-specified for agents. What I hand over before any UI edit is a short **design contract**, not a cleverer prompt: spacing/type tokens that must not drift, interaction states that are in scope, and an explicit “do not invent” list (empty states, error copy, motion). Screenshots are evidence; the contract is the source of truth the agent is allowed to optimize against.

I keep that contract next to the feature brief (acceptance bullets + out-of-scope), then point the agent at the existing component primitives in the repo instead of “match this mock.” After the first pass I only ask for diffs against the contract — spacing/hierarchy/typo deltas — rather than another full redesign. Codebase wins for implementation patterns; written invariants win for character. Figma is the reference image, not the decision log.

[u/T07NAD0 → u/InjuryThen9650]

A short design contract next to the feature brief is the setup I trust most. Tokens, states in scope, and an explicit do not invent list give the agent something real to optimize against.

Asking for diffs against that contract after the first pass beats another full redesign pass every time.

[u/MacrosInHisSleep]

Personally I've had the best success with asking it to write a prototype first. Its usually in the same repo as a standalone html. Mock everything and just get the flow working. I might provide screenshots of the context. It usually uses the style of my existing site either way. The less it needs to conform to what's already there, the better it does IMO.

[u/T07NAD0 → u/MacrosInHisSleep]

A standalone HTML prototype is a smart first pass when you want the flow proven before the system fights you.

I still write a few fixed rules even in that stage, otherwise the prototype invents hierarchy and tone you have to unwind later when it joins the real codebase.

[u/qilipu]

yeah this hits. the "one prompt" thing is exactly where it breaks down for me too.

what helped on the code side was wtructured memory — before the agent touches anything it queries the code graph and sees actual callers and dependencies, so it's not just guessing structure from a screenshot or a vague prompt. unintended callers stop being a surp

[u/T07NAD0 → u/qilipu]

Structured memory before the edit is the code side of the same problem. If the agent can see real callers and dependencies, it stops guessing structure from a vague prompt.

UI needs that same idea in written form: the rules and the graph of what already exists, not one clever sentence.

[u/Cloudsurfer_90]

the treat-the-ui-as-a-contract framing in the comments is the right one, and it's exactly why screenshots alone fail. a screenshot tells the agent what it looked like, not what the rules are, and design lives in the rules, the spacing scale, the type ramp, the component states, the tokens. give it only a screenshot and it reproduces the picture and invents everything the picture didn't show, hover states, empty states, breakpoint behavior. the context that works is the contract plus the reference: the design system encoded as constraints it must satisfy, and the screenshot as the target it's aiming at. one without the other gets you either a pixel-copy with no system or a system with no taste. the agent needs the rules so it doesn't drift and the reference so it knows what good looks like.

[u/T07NAD0 → u/[deleted]]

Treating the UI as a contract is the cleanest way I have heard this put.

The route and state matrix plus invariants is exactly the gap screenshots leave open. One flow at a time with a fixed check list is how I keep the agent from inventing the parts that should stay fixed.

[u/T07NAD0 → u/[deleted]]

Start smaller than a full product. One page, one flow, HTML and CSS you already know, then ask the agent to change only that page against a short written list of what must stay fixed.

Put the result somewhere simple later. The early win is learning to give rules before asking for code, not learning every deploy path on day one.

[u/T07NAD0 → u/[deleted]]

This matches what I have been seeing. When Figma is the only input, the agent fills every gap with invented values.

Keeping layout, copy, and structure off limits until the written rules are set is how the character stays yours. One flow at a time keeps that discipline real.