Rusmir Arnautovic

#Figma just opened the canvas to agents. I've been testing the design-to-code workflow for the past two weeks. Here's the finding nobody is talking about yet. Take a component with named color tokens. Ask an agent to generate code from it. The rendered output looks correct. Visual inspection passes. The CSS has zero token references. var(--primary) became #020617. Every color resolved to raw hex. The code looks right. It breaks on the first rebrand. Opening the canvas to agents is a real step forward. The Figma → code direction with token fidelity is still unsolved.

Product design is not Ul design. It never was. Something's coming this summer that's going to change how you think about the job. #dangerousbydesign

Every few months, the same conversation comes back. "Figma isn't what it used to be." "Figma doesn't listen to designers." "AI will replace us." "Figma is becoming Adobe." And honestly, I'm always a bit confused by it. Figma is a tool. That's it. A good tool won't make you a good designer. But it can help you express what you already know - faster, more clearly. Your craft is still the same thing it's always been: how you think through problems, how you structure a product, how you read users, how you turn a vague idea into something someone can actually use. Figma helps you translate that thinking into a screen. AI just speeds up parts of the process - validating ideas earlier, exploring more directions, cutting out the tedious bits. So the question worth asking isn't "Is Figma ruining design?" It's: Are we developing our craft as fast as our tools are developing? Because when a tool makes something easier or faster, that's not the end of design. It's just the end of some workflows that probably had an expiration date anyway. My hunch is that a lot of the frustration isn't really about Figma or AI. It's about realizing that tools move faster than comfort zones do. Something to sit with.

@sochar__ @useTRMNL Being 31 is a great time. By 30, I had settled down, started a family, and set myself a goal of building something meaningful by the time I turned 50. So I’ve got one more year starting in February to accomplish what I had in mind. All the best, bro.

31 and counting today, with some help from my @useTRMNL friend! 🤣

There are two separate problems hiding inside every failed design-to-code output. The first one is visual. The AI generated something structurally correct but visually wrong. The spacing is off. The radius is wrong. The shadow doesn't match. You can see it the moment you put the two side by side - but the tool never does that comparison, so it ships anyway. The second one is semantic. Even when the visual looks close, the code is using raw values instead of your actual tokens. [16px] instead of [space-4]. [#6C63FF] instead of [color_accent_primary] [border-radius: 8px] instead of [radius-md]. It works today. It breaks the moment your design system updates. Most tools solve neither. They read Figma's data layer, generate plausible-looking code, and hand it back to you for manual fixes. What we're building at Pixframe runs a visual verification loop: renders the output, diffs it against the original frame pixel by pixel, and corrects it until it matches. And it's grounded in your actual design system, not Figma's data model. Your tokens. Your component names. Your variants. Two problems. One loop. pixframe.io #designsystems #figma #designtocode #frontend #react

Behind-the-build for slots → Best practices → Use cases → Tips & tricks

We've been obsessing over a gap that every frontend team hits but rarely talks about. You get a Figma file. You run it through an AI tool. The code comes back and it looks... close. Spacing is slightly off. The button radius is wrong. The shadow doesn't match. Nothing is broken exactly, but nothing is right either. So you spend the next hour manually fixing things that should have been right from the start. The problem isn't the AI. The problem is what the AI sees. Most tools read Figma's data layer - node trees, property values, raw JSON. They don't see the rendered output. And they definitely don't know your actual component library - your tokens, your variants, your naming conventions. We're building Pixframe to fix that. Pixel-accurate design-to-code that knows your design system, not just Figma's data model. Still early. Still building. But if this is a problem you feel daily, we'd love to talk. 👇 pixframe.io, so explore more. #designsystems #figma #frontend #designtocode #react

@sochar__ @Workable I wish the Bosnian community had the same mentality about attending in such great numbers. I think I'm living in the wrong country :D

Far away from Silicon Valley, south-east of Europe, there is a Greek designer's community called Friends of Figma Athens. Curious about Design, AI, Creation. Couple of hours ago, alongside @Workable

Not looking for someone who wants to build something. Looking for someone who looks at layer 2 and already has opinions about how it should work. TypeScript, React, LLM pipeline experience. DMs open.

Hardik Pandya (Sr AI Principal, Atlassian) published the best manual version of this architecture. Spec files + token layer + CI audit. Real and useful. Still hand-authored. Still no visual verification loop. The automated version of his method is the product.

Looking for a technical co-founder. Let me be specific about what that means for this problem. Three layers: 1. Render the Figma frame to a pixel image. Ground truth is the image, not the node tree. 2. Scan the codebase and extract a DS schema - prop types, variants, token references, import paths. 3. After generation, diff the rendered output against the original image. Feed the delta back. Iterate.

I've been talking about the design-to-code accuracy problem for a while now. This is the first time I'm showing what we're building to fix it. The video is 60 seconds. Here's what's actually happening in it: Pixframe exports the Figma frame as a PNG - that's the visual ground truth, not the node tree. It scans the codebase once to extract the real component API: prop types, token mappings, import paths. The model gets both before it generates a single line. First pass comes out close. But close isn't pixel-accurate. The verifier renders the output in a headless browser, screenshots it, and runs a pixel diff against the original. 84%. It finds the wrong border radius, the off spacing tokens, the button that doesn't match the spec. The exact delta goes back to the model with a correction prompt. The wrong lines fix themselves in place. 97% on the second iteration. Two things no existing tool does together: automated schema grounding before generation, and a visual verification loop after. The first one means the model knows your actual design system. The second one means you don't have to manually check whether it got it right. Still early - this is a concept demo, not a shipped product. What I'm looking for right now is design partners who work on Next.js + Tailwind + shadcn stacks and want to pressure-test the thesis against their real workflows, and a technical co-founder with deep TypeScript/React expertise who sees the same gap and wants to build it. If either of those is you, DMs are open. #figma #designsystems #designtocode #react #nextjs #tailwindcss #shadcn #aitools #frontendengineering #productdesign

Has anyone built something close to automated component mapping? Or built the manual mapping at scale and can describe where it broke down? Asking because I'm building toward the automated version and want to understand how teams patch it today. DMs open.

Hardik Pandya (Sr AI Principal at Atlassian) published the closest manual version of this. Spec files. Token layer. CI audit script. Still hand-authored. Still doesn't solve the naming mismatch across hundreds of components. That gap is still open.

Someone posted this in a practitioner forum last week. No replies yet. "We have dozens of component libraries. Figma names are completely different from code names. Code Connect isn't feasible - each mapping needs individual testing. How do you connect Figma to code when the names don't match?"