# Como eu acelerei o desenvolvimento frontend utilizando ferramentas de IA e o MCP do Figma

> Source: <https://dev.to/itagyba/como-eu-acelerei-o-desenvolvimento-frontend-utilizando-ferramentas-de-ia-e-o-mcp-do-figma-16c2>
> Published: 2026-05-22 18:17:46+00:00

Ferramentas de IA aceleram muito o desenvolvimento frontend, mas só funcionam bem quando recebem contexto, limites e validação.

O ganho real não veio de pedir “crie uma tela”. Veio de organizar o fluxo:

- instruções claras para o agente
- integração com design via Figma MCP
- mudanças pequenas
- revisão humana
- testes automatizados
- validação visual com Playwright

## O problema: IA sem contexto gera ruído

Um prompt assim normalmente gera dívida técnica:

```
Crie essa tela em React.
```

O resultado tende a vir com:

- componentes grandes
- CSS fora do padrão
- nomes genéricos
- regra de negócio misturada com UI
- poucos testes
- layout quebrando em estados reais

O que funcionou melhor foi tratar a IA como parte do fluxo de engenharia.

## Codex com instruções do projeto

No Codex, usei um `AGENTS.md`

para definir como o agente deve trabalhar no repositório.

Em vez de repetir regras em todo prompt, deixei o projeto explicar:

- stack
- estrutura de pastas
- padrão de testes
- comandos principais
- regras de TypeScript
- cuidados com integração
- checklist antes de finalizar

No corpo do artigo, deixo só a ideia. O exemplo completo está no final: [AGENTS.md exemplo](#agentsmd-exemplo).

Um prompt melhor para Codex fica assim:

```
Refatore este componente seguindo o AGENTS.md.
Mantenha o comportamento visual.
Adicione testes relevantes.
Rode lint e testes.
```

Isso muda bastante o resultado. O agente passa a respeitar o projeto em vez de inventar um padrão novo.

O mesmo conceito pode ser aplicado a outras ferramentas, como Claude, com alguns ajustes no arquivo de instruções. No Claude, por exemplo, eu usaria um `CLAUDE.md`

mais focado em análise, revisão e tomada de decisão, enquanto no Codex o `AGENTS.md`

fica mais direcionado à execução dentro do repositório.

## Figma MCP no fluxo frontend

O MCP do Figma aproxima design e implementação.

Ele permite que o agente leia contexto do Figma, como:

- estrutura da tela
- nomes de layers
- textos
- medidas
- componentes
- variáveis
- estilos

Isso ajuda muito em tarefas como:

```
Use o frame selecionado no Figma como referência e implemente a tela usando os componentes existentes do projeto.
```

O ponto importante: o MCP não substitui engenharia frontend. Ele reduz o atrito entre design e código.

Ainda é necessário:

- adaptar ao design system do projeto
- reaproveitar componentes existentes
- validar responsividade
- revisar acessibilidade
- testar estados reais

## Como configurar o MCP do Figma

A forma exata muda conforme o cliente, mas o fluxo geral é:

- Instalar e abrir o Figma Desktop.
- Abrir o arquivo de design.
- Entrar em Dev Mode.
- Ativar o Dev Mode MCP Server.
- Configurar o cliente MCP para apontar para o servidor local.

O servidor local oficial do Figma usa HTTP, normalmente em:

```
http://127.0.0.1:3845/mcp
```

Exemplo genérico de configuração MCP:

```
{
  "mcpServers": {
    "figma-desktop": {
      "transport": "http",
      "url": "http://127.0.0.1:3845/mcp"
    }
  }
}
```

Depois disso, o agente pode receber prompts como:

```
Leia o frame selecionado no Figma e compare com a implementação atual.
```

ou:

```
Use o design selecionado como referência e implemente a tela mantendo os padrões do projeto.
```

## Fluxo prático com Codex

O fluxo que mais funcionou foi:

```
1. Ler instruções do projeto
2. Inspecionar arquivos relevantes
3. Fazer mudança pequena
4. Adicionar ou ajustar testes
5. Rodar lint, testes e build
6. Revisar diff
7. Só então finalizar
```

IA acelera, mas testes e revisão seguram a qualidade.

## Testes são o contrato

Sem testes, a IA acelera a entrega e também acelera regressões.

Usei diferentes camadas de teste.

## Teste unitário

Para função pura:

``` js
it('formats currency', () => {
  expect(formatCurrency('10.5')).toBe('R$ 10,50')
})
```

## Teste de componente

Para comportamento visível:

``` js
it('increments quantity', async () => {
  render(<QuantityStepper />)
  await user.click(screen.getByRole('button', { name: /aumentar/i }))
  expect(screen.getByRole('textbox')).toHaveValue('2')
})
```

## Teste de hook

Para estado reutilizável:

``` js
it('loads data', async () => {
  const { result } = renderHook(() => useItems())
  await waitFor(() => expect(result.current.isLoading).toBe(false))
})
```

## Teste de API

Para contrato com backend:

``` js
it('parses response', async () => {
  mockFetch({ success: true, data: { id: '1' } })
  await expect(fetchItem('1')).resolves.toEqual({ id: '1' })
})
```

## E2E com Playwright

Para fluxo real:

``` js
test('opens product detail', async ({ page }) => {
  await page.goto('/app')
  await page.getByRole('textbox', { name: /referência/i }).fill('ABC')
  await page.getByRole('button', { name: /realizar leitura/i }).click()
  await expect(page.getByRole('region', { name: /dados/i })).toBeVisible()
})
```

## Teste de layout

Para proteger alinhamento e scroll:

``` js
const box = await page.locator('.content').evaluate((el) => ({
  clientHeight: el.clientHeight,
  scrollHeight: el.scrollHeight,
}))

expect(box.scrollHeight).toBeLessThanOrEqual(box.clientHeight + 1)
```

## Teste de screenshot

Para telas visualmente sensíveis:

``` js
test('matches open form layout', async ({ page }) => {
  await page.setViewportSize({ width: 1456, height: 793 })
  await page.goto('/app')
  await page.getByRole('button', { name: /verificar/i }).click()
  await expect(page).toHaveScreenshot('form-open.png')
})
```

Esse teste pega regressões difíceis de cobrir só com assertions:

- botão quebrando linha
- texto saindo do container
- painel desalinhado
- scroll inesperado
- espaçamento quebrado

## O que mudou na prática

Com esse fluxo, o Codex virou uma ferramenta de engenharia, não só geração de código.

Ganhos principais:

- menos tempo em boilerplate
- refactors mais rápidos
- testes criados junto com a alteração
- design mais próximo da implementação
- regressões visuais detectadas cedo
- revisão mais objetiva
- padrões documentados no repositório

## Conclusão

Codex e MCP do Figma ajudam muito no desenvolvimento frontend.

Mas a aceleração sustentável vem da combinação:

- contexto claro
- instruções versionadas
- mudanças pequenas
- testes automatizados
- validação visual
- revisão humana

IA boa não substitui engenharia. Ela aumenta a velocidade de quem sabe definir limites e validar resultado.

## AGENTS.md exemplo

```
# AGENTS.md

## Purpose

This project uses React, Vite and TypeScript with a focus on predictable, typed, testable and maintainable code.

## Language Rule

- All source code must be written in English.
- Use English for identifiers, file names, comments, constants and test names.
- User-facing UI copy may follow product requirements.

## Stack

- React
- Vite
- TypeScript
- ESLint
- Vitest + Testing Library
- Playwright

## Main Commands

- `npm run dev`
- `npm run build`
- `npm run lint`
- `npm run test`
- `npm run test:e2e`

Before closing a meaningful change, run at least `npm run lint` and the relevant test suite.

## Project Structure

- `src/app`: app composition and providers
- `src/pages`: route-level pages
- `src/features`: domain-specific modules
- `src/shared`: reusable UI, styles, config and utilities
- `src/test`: Vitest setup and helpers
- `e2e`: Playwright specs and page objects

## Core Conventions

- Prefer small, local and predictable changes.
- Prefer composition over premature abstraction.
- Keep business logic out of purely visual components.
- Avoid generic `utils.ts` dumping grounds.
- Use explicit names for files, functions, props and types.
- Do not introduce `any` unless there is a strong reason.

## React and TypeScript

- Use functional components.
- Keep components focused on one responsibility.
- Derive values from props and state instead of duplicating state.
- Use `useEffect` only for real side effects.
- Do not add `useMemo` or `useCallback` by default.

## Testing

- Test user-visible behavior, not implementation details.
- Prefer Testing Library queries by role, text or label.
- Add tests when fixing bugs or introducing meaningful flows.
- Keep unit, integration and E2E scopes separate.

## Checklist

- The change respects project boundaries.
- Types are clear.
- No redundant state was introduced.
- Relevant linting and tests were executed.
```

## Referências

- Figma Dev Mode MCP Server:
[https://developers.figma.com/docs/figma-mcp-server/local-server-installation/](https://developers.figma.com/docs/figma-mcp-server/local-server-installation/) - Guia do Figma MCP Server:
[https://help.figma.com/hc/en-us/articles/32132100833559-Guide-to-the-Figma-MCP-server](https://help.figma.com/hc/en-us/articles/32132100833559-Guide-to-the-Figma-MCP-server)