Proffer

The first real challenge wasn't a line of code, it was a need. People arrive in two completely different states: some want to start fresh, and some already have a repository they can't abandon (or rather a desperate need for how they can use their DS with AI). Those became Path A and Path B, and they forked quickly into new problems.

Path A is the clean start. Proffer connects to GitHub (authentication), creates the repository, and scaffolds a first design system. That meant I had to make the foundational stack choices myself, as product decisions: React, because it covers something like 90% of the front end world. Next.js on top of it, because it covers roughly half the market. And for the component layer, shadcn/ui, because, well, it is bloody shadcn/ui and it gives people a genuinely great starting point: a registry, full accessibility (a11y) built in, and real theming, so they can make it their own. Those choices are why the output looks and behaves like a real product from minute one, not a toy, and they also give it long term viability.

Path B is the harder and more valuable one: work inside a repo that already exists. The moment you do that, the codebase is in charge, not Figma files, Figma MCP, Lovable, and so on. So before Proffer writes anything, it inspects the repo and sorts it into one of a few buckets. If it finds shadcn, easy, that's home turf. If it finds another known system (Material UI, Chakra, Ant, Mantine, and so on), it can still work by compiling a library-anchored skill that captures that system's identity, the repo's own theme, and real in-repo usage examples. If it finds a repo with no design system at all, applying a fresh one means touching foundational config and styling files, which is exactly where a wrong move makes a mess, so I parked that case deliberately for later. And if the repo simply isn't compatible, an unusual stack or a hostile monorepo layout, Proffer is honest and says so, rather than pretending and shipping something broken. Here is a list of the design systems I analysed, and you can see the winners and losers. It's funny and scary to see how many well known, 5 to 10 year old companies land in the incompatible bucket, and how much work they will need to do to use AI on their design systems. Anyway ...

The engine that makes any of this possible is the "skill," and this was the big thing. A compiler reads the actual repository and produces a machine-usable brief for each component: its real prop signature, a usage example pulled from the repo's own source, and a rules banner naming the underlying primitive library. The breakthrough was almost funny. An Accordion prompt failed the build gate three times in a row when the model had only prop signatures, because it kept reverting to its strongest prior. It passed clean the moment I added a one line banner that said, in effect, "these components are Base UI, NOT Radix." On system output isn't luck, it's grounding.

I tested this against 111 real design system repositories, and the most useful thing I learned was what NOT to trust: you cannot predict success from the stack alone. Some repos are perfectly compatible on paper and still structurally hostile to work in. So the honest judge isn't a pre-flight score, it's the repo's own build running after the change. If it builds, it ships. If it doesn't, Proffer says so out loud.

And the direction I was most excited about built on the same mechanism. The design system skill is just one skill file. But nothing stops you from adding more. So alongside the main skill that teaches the AI your components, a team could pull in a separate copywriting skill that makes it write correct, on-brand text, and others after that. One skill file to get the components right (call it the internal skill), and others (a SKILLS.md in the traditional sense) to get other things right (a custom campaign, tone of voice, you get it), each owned by the people who actually own that knowledge.

The most important thing Proffer does is refuse. Before it writes a single line, it checks whether the change touches a protected surface, login, routing and the app shell, the server API, config and dependencies, and if it does, it stops and escalates to a human instead of half doing something dangerous. As a design leader, this is the insight I'm proudest of: "good automation isn't the automation that does the most, it's the automation that knows its own edges."

The AI checks its own work before a human ever sees it: lint, typecheck, and a real build. If the gate goes red, it doesn't shrug and hand you the mess, it reads the exact error, feeds it back to itself with the offending file, and retries, up to three times. Self healing before review is what makes the approval step honest, because the developer is approving something that already stands up.

The last feature I built says it best: when you add a component, Proffer asks one small, human question: where does this go, top, bottom, or should I decide? The person owns intent and placement, the what and the where; the machine owns the how. Getting that division of labor right is the difference between a collaborator and a slot machine.

Some edits take 60 to 100 seconds of real model work, and at one point a dying stream left the interface looking crashed when it wasn't. The fix was equal parts engineering and UX craft: a silent fallback to polling, a live "working, 20s" indicator, and a hard rule that the system can never trap the user in a dead state. The gap between "looks broken" and "clearly working" is often just one honest status line.

One edit was taking about 60 seconds and I didn't know why, so I instrumented a single run. The data was blunt: 92% of the time was the model writing files, across two full passes, it was rewriting an entire file in the first pass just to throw it away. So I changed the first pass to return only the path it needed, not a rewritten file. 60.4 seconds became 26.0, about 2.3x faster, and roughly half the cost. Performance is UX, and you measure before you cut. I could push it harder and make it 4x faster, but there was a danger it would start breaking things, so yes, know the limits.