How to give your coding agent taste: the design layer nobody builds

You describe the product to your coding agent and it builds. That part works now — genuinely, surprisingly well. What doesn't work is the next bit: getting it to look like your product rather than a product.

So you do what everyone does. You paste a screenshot of an app you admire. You say "make it feel like Linear, but warmer." You drop your logo into the chat, tell it the blue is the wrong blue, explain that you hate drop shadows, and after three or four rounds you get something you're happy with. Real progress. You ship it.

Then next week you open a new chat to build the settings page, and you do all of it again. Slightly differently, because you can't remember exactly what you said last time. And the settings page comes out looking like a cousin of the first page rather than the same product. A month later you start a second product, and it's a stranger.

Here's the question worth sitting with: where did last week's decisions go? You made them. You paid for them, in your own time and in tokens. And they evaporated the moment you closed the tab.

What "taste" actually is — and why your agent hasn't got any

We talk about taste as though it were a mysterious quality some people have. For the purposes of building software it's something much more boring and much more useful: taste is a set of decisions that have already been made.

Not "I like clean design." Decisions. This typeface, not that one. Corners at six pixels, not sixteen. Buttons that state what happens rather than saying "Submit". Generous whitespace even when it means less fits on screen. Never a stock photo of a diverse team laughing at a laptop. Every one of those is a small ruling you've handed down, and together they're the reason a product feels like it came from somewhere rather than from nowhere.

Your coding agent has none of them. This is worth being precise about, because people describe it as a failure of the model and it isn't. When you don't supply a decision, the agent still has to produce something, and the safest something is the most common answer it has seen. The average of the internet. That's why so much AI-built work converges on the same look — the same violet-to-indigo gradient, the same rounded card with a subtle border, the same three fonts. It's not that the agent has bad taste. It's that it's filling a gap you left, with the statistically least surprising thing.

Which means the fix isn't a better model or a cleverer prompt. It's supplying the decisions.

The screenshot-and-vibes loop

Let's be honest about how most people supply them today, because it isn't shameful — it's just where the tooling has got to.

You screenshot something you like and paste it in. You name-drop inspiration: "like Stripe's docs", "like Notion but less grey". You drag in the logo, maybe a hex code you had to dig out of an old file. You describe the feeling you're after in adjectives — clean, confident, not corporate, a bit editorial. Then you correct the result a few times until it lands.

This works. That's the awkward part. It works well enough that nobody stops to fix it.

But look at where all that effort ends up: in a conversation. Your design direction is now sitting in the middle of a chat log, mixed in with bug fixes and questions about database schemas. And a conversation has an ending. When it ends, the taste goes with it.

So the loop repeats. Every new feature, every new page, every new project starts from zero and gets re-explained slightly differently — because you're reconstructing it from memory, and memory rewrites things. Then a co-founder prompts something without you, using their version of the same instructions, and now there are two dialects of your brand in the same codebase. Nobody did anything wrong. There was simply nowhere to write it down.

The tell: if you've ever typed the same sentence about your brand into an AI tool twice, you've found the problem. That sentence should have been stored the first time.

The design-first route, and where it leaks

Plenty of builders have already noticed this and reached for the disciplined answer: design it properly first. Lay out the screens in Figma, or generate a design in a tool like Claude Design, agree it, then hand it to the coding agent and ask for that.

This is a real improvement and I'd recommend it over vibes for anything you're charging money for. It forces the decisions to be made deliberately instead of accidentally, and it gives you something to point at when the build doesn't match.

But it leaks in two specific places, and both are worth knowing about before you rely on it.

The handoff is lossy and one-directional. A design file is a picture of a decision, not the decision itself. It shows you that this button is that shade of green with that corner radius. It doesn't say why, or when to break the rule, or what to do on a screen that nobody drew. So the agent infers. It's a good inferrer, but it's inferring, and inference drifts. And once the code starts moving — because real products change faster than their design files — the design and the build quietly stop agreeing. Anyone who has worked with designers and developers in the same room knows this drift; the agent doesn't remove it, it just makes it happen faster.

It only covers what you drew. Your agent will build dozens of things nobody designed: an empty state, an error message, a confirmation dialog, the third card variant somebody needed on a Tuesday. For every one of those it's back to guessing, because the design file has nothing to say about them. And critically, a design file almost never records the negative space of your taste — the things you'd never ship. That turns out to matter more than the things you would.

So the design-first route moves the problem rather than solving it. The decisions get made properly, and then still end up somewhere the agent can't reliably read.

What both routes are missing: somewhere for the decisions to live

Step back and the shape of it is obvious.

You have design tools, which are very good at making design decisions. You have coding agents, which are very good at executing them. And between the two there is a gap that nobody owns — no shared place where the decisions themselves are kept, in a form a human can update and a machine can read.

Every team fills that gap manually. A founder holds it in their head. A designer holds it in a file. A developer holds it in the code. An agent holds it for the length of one conversation. Four partial copies, none of them authoritative, all of them drifting apart.

Think about how oddly we tolerate this. Your code lives in version control — one place, shared, current, and anyone new can clone it and be up to speed. Your customer data lives in a database rather than in an email thread. But the rules that determine what your entire product looks and sounds like live in a chat window and somebody's memory.

The fix is structural, not motivational. You need a layer that sits between the design and the code, holds the decisions, and is readable by both the people and the agents. Not a document nobody opens. Something live, that the build reads from.

What actually belongs in that layer

More than a colour palette, and this is where most attempts stop too early.

The visual decisions. Fonts and how they're used at each size. Your colours — not just the brand hex, but which one is a warning, which is a success, and which combinations you've checked are actually readable. A logo, in the variants people will need, so nobody stretches one. Spacing and corner radius, because those two do more to make a product feel coherent than colour does. If you're pinning these down for the first time, our free colour palette generator and contrast checker will get you to defensible values in about ten minutes, and the logo colour changer will produce the variants without opening a design tool.

The reference examples. The screenshots you keep pasting anyway — but stored once, labelled with what you actually like about each one. "This, for the density of the table." "This, for how the empty state is written." An unlabelled moodboard is decoration; a labelled one is an instruction.

The words. How your product speaks. Are errors apologetic or matter-of-fact? Do you say "Delete" or "Remove"? Sentence case or title case on buttons? Tone drifts even faster than visuals, because everyone assumes it's obvious.

Who you're talking to. A product for compliance officers and a product for teenagers can share a colour palette and still be completely different pieces of design. If the agent knows the reader, a hundred small choices resolve correctly on their own.

And the anti-list — what you'd never ship. This is the underrated one. Most brand guidelines are entirely positive, which leaves an agent free to do anything not explicitly banned. Write down the negatives: no gradients on text, no stock photography, never a modal for something a toast could handle, no exclamation marks. Constraints are the highest-value thing you can give a generative system, because they eliminate whole categories of wrong answer in one line.

Notice that a founder can produce all of this in an afternoon. None of it requires a designer. It requires deciding, once, and then having somewhere to put it.

Serving it to the agent instead of describing it

Having the decisions written down solves half the problem. The other half is getting them to the agent without a human copying and pasting — because anything that depends on a person remembering to paste will eventually not happen.

This is what MCP does. It stands for Model Context Protocol, and it's an open standard published by Anthropic for connecting AI assistants to outside sources of information. The plain-language version: it's a common plug socket. Instead of you feeding facts into the chat, the assistant is given an address it can fetch from itself, whenever it needs to.

Practically, it changes the shape of the conversation. Today you say "use our brand colours" and then paste them. With the design layer connected over MCP, your agent — Claude Code, Cursor, or whatever you're using — asks for them and gets them. You just say "build the settings page." The taste arrives on its own.

Three properties matter here, and they're worth checking for in anything you adopt:

• Read-only. The agent can look things up. It cannot change your brand.
• Scoped. Each project gets its own access, which you can revoke without touching anything else.
• Live. Update the layer once and every connected project sees the new value on its next request. You don't go round updating six repositories, and you don't discover in month four that two of them are still on the old blue.

That last one is the quiet reason this compounds. A document goes stale privately. A connected layer can't, because everything is reading from it.

What changes when taste is a file instead of a conversation

The first thing you notice is that new work starts in the right place. A fresh project doesn't begin at the internet's average and get dragged toward your brand over four rounds of correction — it begins at your standard. The first draft is roughly right, which changes what the review is even about.

The second is that other people stop being a risk. A new teammate, a contractor, an agency, or an agent someone else is running all read from the same source. They don't need to absorb your taste through osmosis or ask you to review every screen. This is exactly the argument for owning your repository from day one when you hire an agency — the point isn't the artefact, it's that the knowledge lives with you rather than in someone's head.

The third is consistency across products rather than just within one. If you're running more than one thing — a main product, a marketing site, an internal tool — they can share a direction without anyone maintaining three copies of it. And where they should differ, they differ on purpose, because the difference is recorded rather than accidental.

The fourth is the one nobody expects: you stop having the same argument. When the direction is written down, "I don't like it" turns into a specific, checkable question — does this follow what we decided, or not? If it follows and you still don't like it, the decision was wrong and you change it in one place. Either way it's resolved once instead of re-litigated every sprint.

You can finally A/B test taste

Here's where it gets genuinely interesting, and it's only possible once your design direction is data instead of prose.

If your taste lives in prompts, you can't test it. You can argue about it. The person who is most confident, or most senior, wins — which is a terrible way to make decisions that thousands of customers will experience.

If it lives in a structured layer, you can hold two versions. Same brief, same agent, two directions: the dense, information-first version and the spacious, calm one. Build both — which is now cheap, because the agent does the building and the direction is a variable rather than a rewrite. Put them in front of real users. Measure sign-ups, or activation, or whatever you actually care about.

Now "which design is better" has an answer instead of an advocate. We say internally that decisions should be evidence-based, not vibes-based, and design has historically been the one area where we all quietly accepted vibes because measuring seemed impossible. It isn't impossible any more. It was just expensive to build two versions of anything, and that cost has largely gone.

Two honest caveats. Only test things that plausibly move a number — testing two greys is theatre. And you need enough traffic for the result to mean something; below a few thousand users you're reading noise. If you're not sure which metric this should move, our three-layer approach to KPIs is a reasonable starting point.

When you don't need any of this

One product, one person, one weekend? Don't build this. Paste screenshots, prompt away, ship the thing. Process you don't need is just a slower way of not shipping, and a landing page you'll rewrite in a month does not deserve a design layer.

The moment it starts earning its keep is reliably one of three:

• The second product. You're now maintaining a family resemblance rather than a single look.
• The second person. The instant someone else prompts on your behalf, your taste needs to exist outside your head.
• The second month. This is when you notice you're re-typing the same preferences and can't remember what you settled on last time.

Hit any of those and the afternoon it takes to write down your decisions is the cheapest afternoon in the project.

The checklist: does your taste live somewhere an agent can read?

Run these against your current setup. Every "no" is a place your product will drift.

• Written down: Are your fonts, colours, spacing and logo variants recorded anywhere other than a chat log or someone's memory?
• Negative rules: Have you written down what you'd never ship, not just what you like?
• Voice: Is there a note on how the product speaks — error messages, button labels, tone?
• Reader: Does the agent know who the product is for, in a sentence?
• Single source: If your brand blue changed today, is there exactly one place you'd change it?
• Reachable: Can your coding agent fetch all of that itself, or does a human have to paste it?
• Shared: Could a new teammate or contractor build an on-brand screen on day one without asking you?
• Current: Does the layer reflect the product as it is now, or as it was at launch?
• Testable: Could you run two design directions against each other and measure the difference?

One "no" is fine. A column of them explains why your product looks like three products.

How we do this

We built this layer for ourselves before we thought of it as a product. We run several client projects at once, all built with coding agents, and we were re-explaining the same design decisions across every one of them — badly, inconsistently, and at some cost. So we put the decisions in one place and served them to the agents over MCP instead.

That became moodspec — a workspace for your design decisions (fonts, colours, logos, references, who you're writing for, what you'd never ship) that your coding agent can read directly, so you stop describing your taste in every prompt. It's in early access at the moment; you can put your name down on the site if you'd like a look.

The tool is optional. The pattern isn't, and you can start on it today with nothing but a shared document: write down your decisions, including the negative ones, and put them somewhere every project reads from.

If you'd rather talk it through, book a free discovery call. We'll look at what you've built, tell you honestly whether this is your actual bottleneck or whether something else is costing you more, and you'll leave with a written direction either way — whether you end up working with us or not. And if you built your product in a tool like Lovable and you're heading for real customers, our 8-point checklist for vibecoded apps covers the things that need fixing before design is your biggest problem.

Coding agents have made building cheap. That means the scarce thing is no longer the ability to produce a screen — it's knowing which screen you wanted. That knowledge is yours, you already have it, and right now most of it is being thrown away at the end of every conversation. Write it down once. Let the machine read it.