DEV Community

Danilo Itagyba
Danilo Itagyba

Posted on

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

#ai #frontend #mcp #productivity

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.
Enter fullscreen mode Exit fullscreen mode

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.

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.
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

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 é:

  1. Instalar e abrir o Figma Desktop.
  2. Abrir o arquivo de design.
  3. Entrar em Dev Mode.
  4. Ativar o Dev Mode MCP Server.
  5. 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
Enter fullscreen mode Exit fullscreen mode

Exemplo genérico de configuração MCP:

{
  "mcpServers": {
    "figma-desktop": {
      "transport": "http",
      "url": "http://127.0.0.1:3845/mcp"
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Depois disso, o agente pode receber prompts como:

Leia o frame selecionado no Figma e compare com a implementação atual.
Enter fullscreen mode Exit fullscreen mode

ou:

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

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
Enter fullscreen mode Exit fullscreen mode

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:

it('formats currency', () => {
  expect(formatCurrency('10.5')).toBe('R$ 10,50')
})
Enter fullscreen mode Exit fullscreen mode

Teste de componente

Para comportamento visível:

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

Teste de hook

Para estado reutilizável:

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

Teste de API

Para contrato com backend:

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

E2E com Playwright

Para fluxo real:

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()
})
Enter fullscreen mode Exit fullscreen mode

Teste de layout

Para proteger alinhamento e scroll:

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

expect(box.scrollHeight).toBeLessThanOrEqual(box.clientHeight + 1)
Enter fullscreen mode Exit fullscreen mode

Teste de screenshot

Para telas visualmente sensíveis:

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')
})
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

Referências

Top comments (0)