My coding agent often builds the wrong UI. So I built an MCP to make sure it built the right scope and feature

[u/DonR954]

I kept running into the same problem with coding My coding agent kept building the wrong UI. So I built an MCP to check its work first.
agents. The code was usually fine. The design decision was wrong. And then have to spend time improving what the agent built.

For example, I might ask for a price breakdown in a booking checkout. The agent could:
- Miss fees or taxes that should be included
- Add interactions I never asked for
- Pick a generic pricing component that doesn’t fit the product
- Turn a small component into a much bigger system

So I started thinking: what if the agent checked the design scope before writing the code?
That led me to build Pattern, an MCP server that helps coding agents make better UI component decisions. It’s to help the agent answer: “Is this actually the thing I should build?”
Pattern MCP on GitHub

How it works
The agent gives Pattern a component need and some context:
{
"component_need": "price breakdown with nightly rate, cleaning fee, service fee, taxes, and total",
"domain": "Airbnb-style rental marketplace",
"framework": "React + Tailwind"
}

Pattern turns that into a requirements checklist, then checks real components from shadcn/ui and 21st.dev against it. It returns one of two decisions:
- use_existing - An existing component is a good enough fit.
- custom_build - Nothing fits well enough, so build it using a concrete reference from Mobbin or Figma Community.

Why I think this matters
Coding agents are getting very good at implementation. But implementation comes after a bunch of design decisions:
- What belongs in this component?
- What doesn’t?
- Is there already a good fit?
- Is the existing component too generic or too complex?
- Should we build something custom?

If those decisions are wrong, you can end up with perfectly working code for the wrong product requirement. Pattern adds a checkpoint before that happens.

I’m looking for people to install Pattern, use it on a project and give me honest feedback. Where is it working well? Where could it be improved for your use case?

[u/Darkelement]

I just have my agents.md file in each project tell codex to reference the spec before implementing new designs.

I asked codex to do that for me too. Works for me. Don’t see a need here.

[u/DonR954 → u/Darkelement]

Very fair pushback. The distinction is that AGENTS.md can tell an agent to check the spec, but it doesn’t give the agent a way to determine whether a candidate component actually satisfies it.

Pattern turns the need into a requirements checklist, checks real candidate components and their props against it, and returns a verdict with confidence rather than just telling the agent to “go look.”

It’s also aimed at a different stage: when you don’t have a mature internal spec or design system yet and you’re choosing across sources like shadcn, 21st.dev, Mobbin, etc.

If you already have a solid internal spec and Codex reliably follows it, you may not need Pattern. I’m really focused on the gap before you have that system in place.

[u/Darkelement → u/DonR954]

Right, but I think the point I’m making is you can just ask Codex to create this as a skill, and it will do it for you. You can even ask Codex to spin up a sub agent every time it deploys a feature to verify that feature matches the spec.

Most of these super power AI helper tools can just be built by conversing with your AI agent

[u/DonR954]

Totally fair, and you’re right that a sub-agent could write something like this in a conversation. That’s true of a lot of tooling though. The question I’d ask is less “can it be built ad hoc” and more “how reliable and reusable is the ad hoc version compared to something maintained.”

A sub-agent checking “does this match the spec” is still an LLM making a natural-language judgment call each time. It won’t necessarily score the same way twice, and there’s no memory of past verdicts. Pattern does an actual diff against component code and props, and caches the result in a ledger so you’re not re-deriving (and re-paying for) the same judgment every session.

If a fresh, unverified check each time works fine for your workflow, you probably don’t need this. It’s aimed at people who want that judgment to be consistent, cheap on repeat calls, and shared across a team rather than living inside one person’s prompt history.