AI can ship your UI faster — unless your Figma is chaos

Implementing mobile layouts is boring work. You're essentially a human compiler — copying padding values, font sizes, and color codes from Figma to your IDE. No creativity, no challenge, just routine.

I tried using Cursor with design screenshots. It would generate something similar, but never accurate enough:

- Inconsistent spacing values
- Wrong font sizes and weights
- Slightly off colors (`#2A2A2A` instead of `#1F1F1F`)
- Design icons replaced with similar ones from MaterialIcons

Then I discovered Figma MCP and everything changed.

Yes, it costs €12/month, but it's worth every cent.

Figma MCP is a bridge between Figma and your coding agent. It provides tools that allow the agent to extract actual design data — variables, styles, and metadata from selected frames. It also provides screenshots so the agent can understand the visual semantics. Combined, the agent gets both the precise design tokens and the visual context.

The results are significantly better.

But here's the critical part — and this is where most setups fail:

The designer must follow atomic design principles

Your designer needs to:

1. Create design tokens (atoms) — colors, fonts, spacings as variables
2. Build components (molecules) from these tokens
3. Compose screens from these components

Think of it as a proper design system hierarchy.

My workflow

As a Flutter developer, I use the AI agent with Figma MCP for the entire process:

1. Tokens → AppTheme
The agent generates color tokens (like primary500, error300`), typography (`heading1, body2`), and spacing (`spacing8, `spacing16`) with matching names from Figma.

2. Components → Reusable widgets
The agent creates Flutter widgets using these tokens.

3. Screens → Complete layouts
I feed the agent context: “tokens are in AppTheme class, components are in `lib/src/core/uikit`” or use a custom skill, and it generates screens using the existing code structure.

The key is naming consistency. When Figma tokens and Flutter code use identical names, the agent can reference them correctly.

Is it pixel-perfect?

No. I still need to review the generated code and make adjustments.

There's a way to make it more reliable using Flutter golden tests — the agent generates a component, compares it to the Figma screenshot, and if pixels don't match, it fixes the code and compares again. But this feels like overengineering for now. The feedback cycle can take too long for simple components.

Manual review is faster.

Garbage in, garbage out

I'm fortunate that my girlfriend creates proper design systems with clean component structure and consistent tokens. This saves me hours of manual implementation.

But I've worked with many designers who focus only on visual appeal without considering implementation. Their Figma files have random spacing values, inconsistent colors, and “components” that aren't actually reusable.

These designs look good but don't generate good code.

TL;DR

This approach eliminates the tedious part of mobile development. But it requires structured design files, not just pretty mockups.

Good design systems are the difference between AI generating production-ready code and AI generating something you'll need to fix manually anyway.

The question I ask at every interview

Once, at one of my first interviews for a mobile dev position, I was asked: what does "good code" mean to you? Since then, I often ask candidates the same question at the end of interviews. Not to evaluate — more out of curiosity.

The answer is almost always the same: readable, extensible, testable. SOLID, DRY, clean architecture. Juniors, mids, seniors — almost everyone says the same thing.

I used to think the same way. I'd agonize over layer structure, debate patterns, refactor before the feature even worked. It felt like the "right" way to code.
Now, with more experience, architecture just happens. You set up a foundation, work within it, adjust as you go. You don't overthink — you just know what fits. And once that's no longer something you struggle with, the real question surfaces: how fast can I deliver this feature? Not "is this abstraction elegant enough" but "is this in prod and solving the user's problem."

AI is reinforcing this mindset. An LLM can understand your codebase and write new code within its patterns. The architecture doesn't suffer — but the delivery speed multiplies.

That said — in real production work, AI doesn't magically make everything 10x faster. The bottleneck was never really the code itself. It's communication: unclear requirements, waiting for designs, going back and forth with the client. AI eliminates the slowest part of coding, but it exposes what was always the real problem — everything around the code. Which only reinforces my point: obsessing over code perfection was always misplaced energy. But that's a topic for another post.

So if someone asked me that same interview question today, I'd answer: good code is code that solved the problem, reached the user, and did it on time. Cleanliness is a means, not an end.

A while back I started diving into system design.

I got curious about how large-scale modern systems work, how and why their architecture is shaped the way it is. Decided to step outside the mobile dev bubble (wrote about that in my previous post).

I love learning and consume a ton of educational content now: books, conference talks, articles, all mixed together. But what really clicks for me is smart people who explain complex things simply.

So here are 3 lectures I want to recommend: Oleg Bunin's talks from HighLoad++ 2017 (1, 2, 3) as a solid foundation for system design. He walks through different approaches to scaling high-load systems one by one, then gradually moves into practice. Sure, some things are dated by now, but the fundamentals hold up.

I know that at least some of my friends who are really cool engineers are reading this. If you know similar resources that explain system design in a clear way, please share, I'd really appreciate it 🙏

Fun fact: back then (in 2017) VK had only about 20 developers 🫡