DEV Community

Cover image for I Tested Brilliant.design: Building a Real Portfolio from Figma to AI-Powered Design and Code

I Tested Brilliant.design: Building a Real Portfolio from Figma to AI-Powered Design and Code

Hadil Ben Abdallah on September 07, 2026

I’ve used quite a few AI design tools, but I was always thinking about what might happen when I stop generating a fresh screen and start working on...
Collapse
 
aidasaid profile image
Aida Said •

Impressive 😍 An AI agent that understands the structure and visual patterns of an external design is really brilliant.
And being able to choose either to use built-in AI or external MCP is very powerful.
Your tests are very clean. I'll give it a try.

Collapse
 
hadil profile image
Hadil Ben Abdallah •

Thanks! 🙌🏻 Glad you found the tests clean.
Brilliant really deserves you give it a shot. I used many AI design tools before, and Brilliant has features that I didn't find in any other tool.

Collapse
 
wrobeltomasz profile image
Tomasz •

How did BrilliantDesign handle the transition from Figma designs to functional code, particularly in terms of preserving design fidelity and responsiveness? Were there any notable limitations or trade-offs in using AI for this workflow 🙂

Collapse
 
hadil profile image
Hadil Ben Abdallah •

Thank you! I think Brilliant does a good job of keeping the design itself editable and giving you several ways to move toward code, including React/JSX and HTML/CSS exports. But I’d definitely treat the generated code as a starting point; I would not ship directly.
The biggest trade-off with AI in this workflow is that the design can look right while the implementation still needs a developer to handle things like responsive behavior, component architecture, state, and the details of a real application.
I focused more on testing whether the AI could understand and work with an existing design than on doing a full production-level responsiveness audit.

Collapse
 
mahdijazini profile image
Mahdi Jazini •

Really interesting approach, Hadil.
I especially liked that you tested Brilliant with an existing Figma portfolio instead of starting from a blank prompt.
The Design → MCP → AI Agent → Code workflow feels much closer to how developers actually work on real projects.

The part about preserving an existing design system across canvases was particularly interesting. I think this is where AI design tools can become genuinely useful for developers, rather than just another prompt-to-UI generator.

Great write-up and a really practical test. 👏

Collapse
 
hadil profile image
Hadil Ben Abdallah •

Thank you so much! 🙌🏻 I agree, the design system part is where it gets interesting for developers. Generating a UI from scratch is one thing, but being able to build on top of something that already exists without losing its visual language is closer to a real workflow.

Collapse
 
svgicons profile image
Svg/icons •

Did imported vector assets keep meaningful structure through the Figma → Brilliant → MCP workflow, or did the agent mostly see them as geometry?

Collapse
 
hadil profile image
Hadil Ben Abdallah •

In my test, the imported vectors remained editable as actual design elements; they didn't become flattened into a rendered image, and every vector asset retained higher-level semantic meaning through the full Figma → Brilliant → MCP workflow.

Collapse
 
svgicons profile image
Svg/icons •

That’s interesting. Keeping vectors editable is one thing; preserving enough semantic structure for an agent to understand and modify them meaningfully is the part I find especially important.

Collapse
 
aidiveyt profile image
AI Dive •

Same shape as Claude Design's MCP: the canvas is real elements the agent edits, not a rendered picture. One trap on that side: the server refuses a plain Claude Code login token with a 403 and needs its own design login first.

Collapse
 
hadil profile image
Hadil Ben Abdallah •

Exactly! That was one of the things I found interesting too. The agent is working with the design elements on the canvas.
And yeah, that 403 trap is definitely something worth knowing before setting everything up.

Collapse
 
mudassirworks profile image
Mudassir Khan •

the 'importing existing design, not starting blank' framing is exactly what separates real tools from demo toys. a blank canvas always works, production designs don't

we hit this same wall bringing a Figma component library into a code generator: the edge cases pile up fast when your design has custom auto layout overrides and mixed fill types that look fine in Figma but serialize into garbage constraints downstream

the MCP + Codex combo is genuinely interesting tbh because it inverts the workflow. instead of 'design then describe to AI', you're letting the model inspect the live canvas state directly — that's a fundamentally different trust surface

curious what happened with Blueprint's design system extraction when your portfolio had deeply nested components: did it flatten the hierarchy or preserve the symbol structure?

Collapse
 
hadil profile image
Hadil Ben Abdallah •

Exactly; that was the reason I wanted to test it with an existing portfolio. A blank prompt can hide a lot of the problems that show up once there are already design decisions, components, and constraints in place.
For the Blueprint question, though, I didn't go deep enough into deeply nested components to confidently say how it handles every level of hierarchy. My testing focused more on whether the agent could understand and work with the existing canvas and its design patterns.

Collapse
 
hanadi profile image
Ben Abdallah Hanadi •

I loved the possibility to work on the design from the terminal.
Thanks for sharing!

Collapse
 
hadil profile image
Hadil Ben Abdallah •

Yeah, working on the design from the terminal is helpful especially for developers.

Collapse
 
thedevmonster profile image
Dev Monster •

Great tool. Thanks!

Collapse
 
hadil profile image
Hadil Ben Abdallah •

Welcome! Glad you found something helpful here.