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 a real design.
Generating a nice-looking landing page from a prompt has become easy. Importing an existing design, editing it without breaking its visual language, asking an AI agent to understand the canvas, creating another page that follows the same design system, and eventually getting that design into a real React workflow is a better test, I think.
That’s what I wanted to do with Brilliant.design.
For this hands-on review, I decided not to start with a blank canvas. I used a real developer portfolio I picked from Figma and brought it into Brilliant. From there, I worked through the editor manually, connected OpenAI Codex through MCP, asked Codex to inspect and modify the design, created a second canvas from the existing design system, tested Brilliant’s built-in AI with Codex, and tried its Playground mode.
I also looked at the parts of Brilliant that matter to developers beyond the visual editor, including its design system, Blueprint language, MCP workflow, and design-to-code options.
TL;DR
I tested Brilliant.design by using a real developer portfolio as the starting point instead of building a random demo from scratch. I imported the portfolio from Figma, made manual changes, connected Codex through MCP, asked Codex to understand and modify the canvas, created a new canvas using the existing design system, tested Brilliant’s built-in AI with Codex, and explored Playground mode.
Here’s the short version of what I found:
- Figma import: Brilliant can bring an existing Figma design into an editable canvas, including layout, vectors, text, fills, strokes, auto layout, and other design properties.
- Manual editing: The imported design remains editable, so you can continue working with it as an actual design instead of treating the import like a static screenshot.
- MCP: Connecting Codex to Brilliant gave me a way to work on the design from the terminal while Brilliant handled the visual canvas.
- AI agents: Codex could inspect the existing portfolio and work with the canvas through Brilliant's MCP connection.
- Design consistency: I asked Codex to reuse the portfolio's existing typography, colors, spacing, cards, buttons, border radius, and component patterns, and the new section followed those visual patterns.
- Cross-canvas work: I also tested creating a separate Projects canvas based on the homepage’s existing design system.
- Built-in AI: Brilliant can use Codex and many other agents as built-in AI providers, giving you another way to interact with the same canvas.
- Playground: Playground provides a way to see Brilliant's AI workflow through bundled demonstrations before connecting a provider.
- Blueprint: Brilliant has its own compact design language for representing editable canvas elements and their relationships.
- Design-to-code: Brilliant supports exports such as React, HTML, CSS, SVG, PDF, and other formats, while the MCP workflow opens another route where an AI coding agent can read the design and implement it in an actual codebase.
The biggest thing I liked is that the AI isn't limited to generating a picture of a design. The canvas contains actual editable design elements that an agent can inspect and modify.
That makes the workflow more interesting for developers because the design can become part of the same AI-assisted workflow as the code.
What Is an AI Design Tool?
Before getting into Brilliant, it helps to define what I mean by an AI design tool.
The term gets used for a lot of different products right now.
Some AI design tools are basically prompt-to-image generators. You describe a landing page, dashboard, mobile app, logo, or illustration, and the tool produces a visual result.
Others go further. They generate actual UI layouts that you can edit, move around, resize, restyle, and export.
Then there are tools that put an AI agent directly into the design workflow. In that setup, you can ask the AI to create or change parts of a design while still working with real design elements.
That last category is where things get more interesting for developers.
A useful AI design tool shouldn't just generate a nice-looking interface.
It should also answer these questions with a big "YES":
- Can I edit the result after it has been generated?
- Can the AI understand an existing design?
- Can it follow an existing design system?
- Can it reuse components?
- Can it work across multiple screens or canvases?
- Can I make small, targeted changes without asking it to rebuild everything?
- Can another AI agent access the design?
- Can the design eventually become useful code?
Those differences matter when you're working on something real.
For example, imagine you already have a dashboard with a defined type scale, spacing system, buttons, cards, colors, and components.
You don't want an AI tool to create a completely different dashboard every time you ask for a new screen.
You want it to understand what you've already built and continue from there.
That was one of the main things I wanted to test with Brilliant.
AI Design Tools vs. Traditional Design Tools: What Changes?
Traditional design tools are built around the designer.
You open the canvas, select an element, change its properties, move things around, create components, adjust spacing, and build the interface yourself.
The designer makes the decisions, and the tool gives them the controls.
AI design tools add another layer to that workflow.
You can describe an outcome and let an AI model handle some of the mechanical work.
For example, instead of manually creating four cards, aligning them, adding text, adjusting spacing, and repeating the same structure, you might tell an AI agent to create a four-card section that follows the existing design.
The gap between them becomes bigger when the AI can read an existing canvas.
At that point, the workflow doesn't have to stop at:
Prompt → generated design
It can become:
Existing design → AI understands it → AI makes a change → designer reviews it
During my test of Brilliant, I wasn't interested in seeing whether an AI could create something visually impressive from nothing. I wanted to see how well it behaved when I gave it an existing design and asked it to respect what was already there.
And with an MCP connection, an AI coding agent can interact with tools outside the code editor.
So the workflow becomes:
Design canvas ↔ AI agent ↔ codebase
That is a very different idea from generating a screenshot and then manually rebuilding it in React.
What Is Brilliant.design?
Brilliant.design is an AI-powered design tool built around an editable design canvas and AI agents.
The important distinction is that the canvas isn't just an image.
Brilliant works with native design elements such as frames, text, vectors, lines, icons, layouts, components, and other properties that you can continue editing after an AI action.
If you ask an agent to create a section, it can create actual elements on the canvas. If you ask it to modify an existing element, the change happens to that design element instead of producing a new flattened image.
Brilliant also has a built-in AI experience, but you aren't locked into one hosted AI model. Its current workflow supports connecting providers through your own credentials or local CLI-based tools.
The other great piece was MCP.
Brilliant exposes its canvas through a local MCP server while the desktop application is running. That means supported AI agents can connect to the design canvas and interact with it from outside Brilliant.
Brilliant also has Blueprint, its own compact design language for describing canvas elements. Blueprint represents things such as frames, text, vectors, positions, sizes, fills, strokes, radius, effects, auto layout, and relationships between elements.
The files themselves can also be represented as plain-text .bl files, which makes the design closer to something developers are already comfortable working with: text that can be inspected, compared, and managed alongside code.
So, at a high level, Brilliant brings together several pieces:
Figma import + visual editing + design systems + AI agents + MCP + Blueprint + design-to-code workflows.
Why I Tested Brilliant.design With a Real Figma Portfolio
I could have opened Brilliant, typed a prompt like "Create a modern developer portfolio," and called it a test.
I didn't want to do that.
A blank canvas doesn't tell you much about how an AI design tool behaves once you already have design decisions in place.
So I picked a developer portfolio from Figma.
That gave me a much better starting point because the design already had its own visual language.
There were existing sections, typography choices, colors, spacing, cards, buttons, skills, and other visual patterns that Brilliant and the AI agent had to work with.
My Test Setup
I wanted to keep the setup close to something a developer could reproduce.
Setting Up Brilliant
The setup on Windows was fairly straightforward.
I first installed the Brilliant desktop application and signed in. The setup was really quick.
Connecting Codex CLI to Brilliant Through MCP
I didn't have a paid Claude Code or Cursor subscription available for this test, so I used Codex as the external AI agent.
I didn't use an API key.
That wasn't a problem for the MCP test because Brilliant supports Codex as an external MCP client, and the same local MCP connection approach can be used with other supported AI agents.
I signed in with my ChatGPT account.
You just need to run Codex in your terminal to start it.
Once Codex was working, I enabled the Codex MCP connection from Brilliant's settings.
Brilliant exposes its local MCP server through the desktop application. The documented local endpoint uses:
http://127.0.0.1:3333/mcp
If port 3333 isn't available, Brilliant can use another local port, such as 3334 or 3335.
Brilliant can also register the MCP connection for Codex automatically when it detects the Codex configuration directory.
This Codex CLI connection gave me two different ways to interact with the same design:
Codex from the terminal → Brilliant through MCP
and
Codex inside Brilliant's built-in AI chat
Importing a Real Figma Portfolio Into Brilliant
The first real test was simple:
Can Brilliant take an existing Figma portfolio and turn it into something I can continue working with?
Brilliant currently supports importing Figma designs through its web editor, desktop app, and Figma plugin. Brilliant's documentation also describes options for importing a whole file, selected pages, or a selected subtree from the desktop workflow.
For my test, I used my existing portfolio and brought the design into Brilliant.
With this test I wanted to know whether the design structure survived the move.
Could I select individual elements?
Could I edit text?
Could I work with the layout?
Could I continue changing the design without rebuilding everything?
If an imported design becomes an image, it doesn't give me much value as a designer or developer. I need the objects to remain useful after the import.
Brilliant's Figma import brings over a range of design information, including layout properties, auto layout, vector geometry, fills, strokes, corner radii, image fills, and other resolved design values.
So I found out that I could continue working with the imported portfolio inside Brilliant 🎉
And I tried to make the portfolio mine by doing some manual edits.
Manually Editing the Imported Design
Before involving AI, I wanted to spend some time editing the portfolio myself.
This might sound like a small step, but I think it's important when reviewing an AI design tool.
If the AI disappeared completely, would the editor still be useful?
For me, that means being able to select an element, change its properties, adjust the layout, edit text, move things around, and generally work with the canvas without having to ask an AI agent to do every little thing.
I made a few manual changes to the imported portfolio and used that process to get familiar with Brilliant's editing experience.
Honestly, the editing experience was very smooth and straightforward. I could select individual elements and continue editing the imported design, which makes the transition much easier even if you're not already familiar with Figma or another design tool.
For example, when I wanted to change the primary color across the design, I changed it once in the design system, and the change was reflected throughout the design.
After making a few updates, the portfolio started to feel like my own.
For a clear view, I'm sharing the top part of the new design where I made the most updates.
The next thing I want to find out is whether the AI agent can actually work with the design I already have.
First MCP Test: Can Codex See My Brilliant Canvas?
Before anything, I wanted to make sure that Codex understands the design that's open in Brilliant
Here's the prompt I used:
Connect to my open Brilliant project and inspect the current canvas.
Do not make any changes.
Tell me what you can see and briefly describe:
1. The main sections
2. The visual structure
3. The typography
4. The primary colors
5. The reusable components you can identify
Do not modify anything.
I think this is a much better first test than immediately asking an AI agent to redesign something.
If the agent can't correctly understand the existing canvas, there's no reason to trust it with a large design change.
Codex was able to work with the open Brilliant project and return an analysis of the canvas.
It could identify the major sections and describe the visual structure.
The agent wasn't working from a screenshot that I had manually provided. Through Brilliant's MCP connection, it could inspect the open design canvas and return structured information about it.
This is the result Codex gave me:
• Inspected the active scratch Brilliant canvas; no changes were made.
1. Main sections
- Header + hero
- About Me
- Skills
- Works / portfolio carousel
- Blogs
- Contact form
- Footer
2. Visual structure
A 1920px desktop, single-page personal portfolio. It uses a dark, full-width vertical flow with generous section spacing, centered section titles, and a floating pill navigation near the hero. Content is contained in wide desktop gutters (~128px).
- Hero: identity card on the left, large intro copy in the center, compact experience stats on the right.
- About: split text/card and photo composition.
- Skills: two service cards above four circular skill badges.
- Works: central project montage with left/right carousel controls.
- Blogs: one featured horizontal article row and two CTA buttons.
- Contact: title, form fields, submit button, then footer links.
3. Typography
- Primary UI/body/code face: IBM Plex Mono.
- Headings and editorial titles: Ubuntu.
- Hero display "Technical Writer": Agency FB, ~117px.
- Major section headings: Ubuntu, ~64px.
- Smaller labels/body copy: mostly 14-16px IBM Plex Mono or Ubuntu.
- Type treatment is technical/editorial: monospaced body content, bright-blue code-style tags (<h1>, <p>, </>), and white display text.
4. Primary colors
- Main dark surfaces: #292F36 and near-black #1A1E23.
- Brand/interactive blue: #0080FF, with lighter cyan-blue variants around #1295F7, #12B5F7, and #12F7D6.
- Primary text: white #FFFFFF.
- Divider/muted gray: #43454D.
- Skill accents: HTML #E54F26, CSS #0C73B8, JS #E7A020, React #28A9E0.
5. Reusable components/patterns identified
- The canvas has one explicit declared component: Homepage - Desktop/1920.
- Repeated section-title module: scroll/mouse indicator, large title, and subtitle.
- Repeated rounded-pill buttons: filled blue and outlined dark/blue variants.
- Header/navigation items, including active/inactive nav states.
- Repeated code-tag decoration and bright-blue heading treatment.
- Service cards, skill badges, carousel arrows, blog metadata chips, form fields, and the footer link groups are all structured as reusable patterns.
Asking Codex to Build a New Section From the Existing Design
For the next test, I asked Codex to add a new Featured Projects section to my portfolio.
This sounds simple, but I deliberately made the prompt more specific.
I didn't want:
"Add a Featured Projects section."
That could produce almost anything.
I wanted the agent to look at the existing portfolio and use it as the visual reference.
This is the prompt I used:
Connect my open Brilliant project and add to the current canvas a new "Featured Projects" section below the skills section.
Reuse the existing:
- typography
- colors
- spacing
- card patterns
- button styles
- border radius
- component patterns
Do not redesign or modify the existing sections.
Codex created a new Featured Projects section below the Skills section.
This was a useful test because I could immediately compare the new section with the surrounding content.
The goal wasn't for the new section to look impressive.
The goal was for someone looking at the entire portfolio to feel that the section belongs to the same page.
In my test, I specifically asked Codex to reuse the existing typography, colors, spacing, cards, buttons, border radius, and component patterns.
The resulting section followed those existing patterns closely enough to make the workflow useful.
The cards didn't feel completely disconnected from the rest of the portfolio, and the section followed the visual direction of the page.
This was the first test where I started to see why Brilliant's combination of AI agents + MCP + an editable canvas can make sense for developers.
I was happy with the result, especially because the new section didn't feel completely disconnected from the existing page.
Creating a New Canvas With Cross-Canvas Context
After testing Codex on the existing homepage, I wanted to push the workflow a little further.
Adding a new section to an existing canvas is useful, but creating a whole new page is closer to what happens in a real project.
A developer portfolio rarely has just one screen. You might have a homepage, projects page, about page, blog, contact page, or individual case-study pages. Once you start adding those screens, keeping the same visual language across them becomes important.
So my next test was:
Could Codex create a completely new Projects canvas while using the homepage as its design reference?
I wanted to see whether Brilliant could help with that kind of cross-canvas work without making me manually rebuild the same components and styles.
For this test, I asked Codex to create a new Projects canvas based on the portfolio homepage I had already been working on.
This was the prompt I used:
Connect my open Brilliant project and create a new Projects canvas.
Use the existing design system and components from homepage.
Include:
- Page title
- Short introduction
- Project filters
- Project Grid
- Project cards
- Technology badges
- GitHub link
- Live demo link
The new canvas should feel visually consistent with the homepage.
There are two things I was looking for here.
The first was whether Codex could actually create another canvas in the same Brilliant project.
The second was whether it would use the homepage as a visual reference instead of inventing a completely unrelated design.
I didn't give it exact colors, font sizes, spacing values, or card dimensions this time.
I had already given it those instructions in the previous test.
The resulting canvas gave me a separate place to work on the projects page while keeping the homepage available.
That separation is useful on its own.
The Projects canvas included the pieces I requested: a page title, introduction, filters, project grid, project cards, technology badges, GitHub links, and live demo links.
The new page didn't feel like a completely separate template. It followed the visual direction established by the homepage quite well. The new canvas was ready pretty quickly.
But I still believe that a human designer already knows which details are intentional and which ones are incidental. An AI agent has to infer that from the available design context.
That means I'd still review the new page carefully, especially if the design system is large or has many similar components.
For a production application, I would also want to be very deliberate about which components are truly shared and which ones only happen to look similar.
Using Brilliant's Built-In AI With Codex
So far, I had been driving Brilliant from outside the application through the terminal.
That worked, but Brilliant also has another way to use AI.
You can connect an AI provider and use Brilliant's built-in AI chat directly from the design environment.
Since Codex was already available to me, I wanted to test that workflow too.
External agent: Codex CLI → MCP → Brilliant
Built-in AI: Brilliant → Codex
Brilliant supports Codex as a built-in AI provider.
The setup uses my ChatGPT authentication, so I didn't need to add an OpenAI API key for this test.
After connecting Codex, I could open Brilliant's AI chat and interact with the canvas directly.
The chat is available from Brilliant's interface, and the / shortcut can be used to open the AI interaction.
Here, the AI interaction was part of the Brilliant interface itself.
I didn't need to leave the canvas, switch to the terminal, and communicate with the agent there.
For this test, I went back to my homepage portfolio.
I already had HTML, CSS, JavaScript, and React in the Skills section.
I wanted to add four more technologies:
- TypeScript
- Next.js
- Angular
- Node.js
Here's the prompt I used:
In my homepage scratch project I have HTML, CSS, JS, and React in the skills section.
Add these 4 programming languages:
Typescript
Next.js
Angular
Node.js
Use the same style.
Put them inside colored circles, and inside each circle, the logo of the language.
The result was good overall. The four new items followed the existing visual direction of the Skills section, including the circular presentation and general styling.
That was what I wanted to see.
The AI didn't need me to manually describe every existing property in the prompt.
I could point it toward the existing section and tell it to follow the same style.
There was one limitation, though. The AI placed the four new languages on the same line as the existing ones, which pushed some of them outside the visible frame. I fixed the layout manually afterward, as you can see in the video.
And here's the final new section.
For me, an AI design workflow becomes much more useful when I can ask for a specific change without worrying that unrelated parts of the page will get redesigned at the same time.
I still review the result visually, of course.
That's not something I'd skip just because the agent has access to the canvas.
But the interaction itself was straightforward.
Built-In AI vs. External Codex + MCP
After testing both workflows, I see them as two different ways of working with the same underlying idea.
The distinction can be summarized simply:
| Workflow | Best fit |
|---|---|
| Brilliant + built-in Codex | Quick AI-assisted edits directly in the design environment |
| Codex CLI + MCP | Agent-driven design work from the development workflow |
| Manual Brilliant editing | Precise visual changes and human control |
I wouldn't say one replaces the others. They solve different parts of the workflow and complement each other.
For a designer who wants AI assistance without leaving the design application, the built-in experience is convenient.
For a developer who already spends a lot of time in an AI coding agent, MCP is the part that makes Brilliant much more interesting.
Brilliant Playground
Before wrapping up the AI testing, I also wanted to understand Brilliant's Playground.
This is easy to misunderstand if you open Brilliant before connecting an AI provider.
When I first encountered it, I saw the Playground experience with a bundled example conversation.
I tested the:
"Notes app — entry view"
The important thing to understand is that Playground isn't the same thing as having a live AI provider connected to Brilliant.
It gives you a way to see the AI workflow through prepared demonstrations.
That makes it useful when you're exploring the product for the first time.
The Notes app example gave me a quick look at how an AI-driven design workflow can operate inside Brilliant.
It was useful for understanding the interaction model before I started using Codex.
Playground is better thought of as a guided demonstration of the experience, so I recommend trying Playground before any other test.
One small limitation I noticed is that when I ran the "Notes app" example from Playground while inside my Homepage canvas, Brilliant placed the generated design beside my portfolio. Personally, I'd prefer Playground demonstrations like this to open in a separate canvas by default so they don't mix with an existing project.
Blueprint: Brilliant's Design Language
Blueprint is Brilliant's compact, line-oriented design language for representing editable canvas elements.
A Blueprint file can describe things such as frames, text, vectors, positions, dimensions, fills, strokes, corner radii, effects, auto layout, hierarchy, and references between elements.
The interesting part for developers is that the design has a text representation that can be inspected and worked with by AI agents and development tools.
Blueprint and Git-Friendly Design Workflows
A developer-oriented detail is that Brilliant design files can be represented as plain-text .bl files.
That's useful because text files work naturally with version control.
You can inspect changes, compare versions, and keep design changes alongside other project files.
I think this is one of the ideas that makes Brilliant feel different from a traditional visual-only design workflow.
A design doesn't have to be treated as something that only exists inside a graphical application.
It can also have a representation that developers and AI agents can work with.
From Design to Code: Brilliant's Developer Workflow
At this point, the workflow starts to move beyond design.
If I'm a developer, I eventually need to take the interface I've designed and turn it into something that runs in an application.
That's where Brilliant's export options come in.
Brilliant supports several export formats, including:
- HTML
- CSS
- React/JSX
- SVG
- MP4
- MOV
- Image formats
It also provides Blueprint and other project-level representations.
React/JSX
Brilliant can export a design as React/JSX. I would treat this as a starting point for implementation rather than production-ready application code. The exported structure still needs to be adapted to the project's architecture, components, state, data, routing, and responsive requirements.
HTML/CSS
HTML and CSS exports provide another starting point when you're building a static interface or want to use the generated structure as a reference.
Brilliant.design vs. Traditional Design Tools
So where does Brilliant actually fit compared with a traditional design tool?
A traditional design workflow is centered around the designer creating and editing the interface visually.
Brilliant keeps that visual workflow but adds AI agents, MCP, Blueprint, and developer-oriented exports around it.
Here's how I would think about the difference:
| Capability | Traditional design tools | Brilliant.design |
|---|---|---|
| Visual editing | ✅ | ✅ |
| Components | Common | ✅ |
| Auto layout | Common | ✅ |
| Design tokens | Common | ✅ |
| Figma import | Common | ✅ |
| Built-in AI | Depends on tool | ✅ |
| External AI agents | Varies | MCP |
| AI access to canvas | Varies | MCP |
| Text-based design representation | Varies | Blueprint |
| Git-friendly design representation | Varies | .bl |
| React export | Depends on tool | ✅ |
| HTML/CSS export | Depends on tool | ✅ |
I wouldn't say Brilliant makes traditional design tools obsolete.
There are still situations where a mature design platform with a huge ecosystem, established collaboration workflows, plugins, and existing team processes will make more sense.
What Brilliant does differently is put AI agents and developers much closer to the design canvas.
That is the part I think developers should pay attention to.
Who Should Use Brilliant.design?
After using Brilliant with a real portfolio, I think it makes the most sense for a few types of users.
Developers who care about UI design
If you're a developer who regularly needs to design interfaces before building them, Brilliant gives you a visual environment while keeping AI agents close to the workflow.
Designers who want AI-assisted editing
If you prefer working visually but want an AI agent to handle repetitive or structural changes, Brilliant provides that option without turning the canvas into a static generated image.
Product teams experimenting with AI-native workflows
Teams building products around AI agents may find the agent-accessible canvas useful because design can become part of the same tool ecosystem as development.
Developers working heavily with React
The React export and design-to-code workflow make Brilliant worth exploring if your end goal is a React application.
It won't replace the work of building a production React application, but it can shorten the path from visual design to an initial implementation.
People who already use AI coding agents
This is probably the group I would point to Brilliant first.
If you're already using Codex, Claude Code, Cursor, or another supported agent, the MCP workflow makes much more sense because you're adding a design canvas to an AI workflow you already understand.
Frequently Asked Questions
Is Brilliant.design an AI design tool?
→ Yes. Brilliant.design is an AI-powered design tool that combines a visual editing canvas with AI-assisted workflows and AI-agent integrations. It supports built-in AI providers as well as external agent access through MCP.
The important distinction is that Brilliant isn't limited to generating visual mockups. Its canvas contains editable design elements that can be modified manually or through supported AI workflows.
Can Brilliant import Figma designs?
→ Yes. Brilliant supports Figma import, allowing existing Figma designs to be brought into Brilliant as editable design content.
The import carries over many visual and layout properties, including elements such as text, vectors, fills, strokes, corner radius, and auto layout. Some Figma-specific connections, such as live bindings to Figma Variables and shared styles, don't remain as live Figma connections after import.
Can Codex work with Brilliant through MCP?
→ Yes. Brilliant supports connecting Codex to its local MCP server through the Brilliant desktop app.
In my testing, I used Codex CLI to inspect my portfolio canvas, create a Featured Projects section, and create a separate Projects canvas using the homepage as a design reference.
That made MCP one of the most useful parts of the workflow for me as a developer.
Does Brilliant export React code?
→ Yes. Brilliant supports React/JSX export as part of its design-to-code workflow.
The exported React code should be treated as a starting point that developers can refine for their actual application. A design tool doesn't automatically know your application's routing, state, APIs, business logic, architecture, or existing component conventions.
What is Brilliant Blueprint?
→ Blueprint is Brilliant's compact design language for representing the structure and properties of a design.
It can represent elements such as frames, text, vectors, layout, styling, hierarchy, and references. Brilliant designs can also be represented as plain-text .bl files, making Blueprint relevant to developers, AI agents, and version-controlled design workflows.
Final Thoughts
After using Brilliant.design with a real portfolio, I think the easiest way to describe it is:
It's an AI design environment that tries to make the canvas useful to both humans and AI agents.
I started with a Figma portfolio, not a blank prompt.
I imported it into Brilliant, edited it manually, connected Codex through MCP, asked Codex to understand the existing design, had it create a new Featured Projects section, created a separate Projects canvas from the homepage's design system, and tested Codex as Brilliant's built-in AI provider.
I also explored Playground, Blueprint, and the available design-to-code exports.
The workflow isn't magic, and I wouldn't expect it to be.
AI-generated design still needs human review. Exported React still needs engineering. A design system still needs good decisions behind it.
But Brilliant does something I find genuinely useful: it gives AI agents access to a real editable design environment.
If you're a developer who already works with AI coding agents and wants the design side of that workflow to be editable, inspectable, and connected to the same agent ecosystem, Brilliant is worth trying.
| Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah |
  
|
|---|
Top comments (0)